演讲实录丨真正提升软件团队能力的方法,唯有XP极限编程d5c19046a8|Mon Feb 10 2020 18:58:19 GMT+0800 (中国标准时间)

自述 | 抑郁、轻生、自闭的中年程序员到开挂的IT诗人,逆袭到底有多难?
2019年12月16日
演讲实录 | CMM只提出问题,从来没解决过问题
2019年12月16日

本文内容选自我在「中国DevOps社区2019年会」上分享的《敏捷中国十八年目睹之怪现状》实录。

前文提要:CMM被政府补贴成了骗钱工具,完全没有建设行业能力。

18年来,行业里有很多的方法来来去去,真正可以抓软件开发的基本功、真正可以提升软件团队的能力的方法,我觉得就只有极限编程。CMM提出的这些核心能力,只有极限编程真正提供了。

你看有哪一个方法告诉你做需求管理的时候,你要把需求的格式写成什么样子,你要用什么样的纸卡片来记录一个需求?没有,对吧。一件事应该怎么做,你在书上看到一个说法,和你真正在工作上能做这件事,是相差很大的。

再比如项目管理,极限编程会告诉你迭代怎么去管,根据什么来看项目的进度。当然项目管理这一部分,我认为Scrum也是很好的,非常有效地告诉大家项目管理的方法。

再说配置管理。到底什么是配置管理?其实配置管理落到根本上就是持续集成。有持续集成,你就有有效的配置管理;没有有效的持续集成,就是没有配置管理,就是这么简单的事情。没有持续集成,你可以说在纸面上有很多配置管理的流程,但真到了需要软件的时候你怎么办?你只能依赖一个配置管理员来手工打包。越是你着急需要打包软件的时候,这个人就越出错、越是打不出包来。好不容易打出来的包一测有问题,然后大家一起加班。所以我说配置管理很简单,你有持续集成、每天可以有一个候选版本通过持续集成打出来,你就有配置管理;出不来,你就没有配置管理。

那为了让持续集成有效,最后的最后一切都会落到重构和单元测试上面。是不是拥有高覆盖率的、可靠的、运行快速的单元测试,这是一个决定性的分水岭。而高覆盖率的、可靠的、运行快速的单元测试集,得到这个东西最有效的办法,就是测试驱动开发,就是你必须先写测试、再写实现,你才可能得到这么一个有效的测试集。有很多人跟我讲,我们先赶紧写完了实现,回头再去补单元测试。“写完实现再去补单元测试”,这个鬼故事,我每年都听十几次,你们谁见它真正发生的?我们经常听到这个对话:

领导:单元测试很重要,我们要写单元测试。

开发:好好好,等我改完这个版本我就补单元测试。

改完了这个版本就有空了吗?有空了还有下一个版本呢。你在写代码的时候根本没有考虑怎么单元测试,为什么你认为写完实现代码以后就可以补上测试了?你补不上。你会对着一大堆草率堆上去的代码长叹一口气,因为你一开始写代码的时候就没考虑代码的可测试性。

这件事情我觉得非常有趣:软件工程的教科书里面都写着,单元测试是软件开发的重要环节。所有人都认同单元测试的价值,但是谁也不做。然后到了实践里面,大家说我写完这个版本我就补单元测试,然后这个版本完了之后没有补,然后下一个版本来了之后又说,我写完这个版本就补单元测试,下一个版本做完也没有补。这种现象使我对于人类作为一个整体的学习能力非常担忧,因为大家没有从历史中学习的能力:补单元测试这个事情是从来没有发生过的,所以未来它也不会发生,这才是合理的。你根本就不应该相信“我做完这个版本补单元测试”这种话。

所以一切的一切最后都会归结到有没有有效的单元测试集。得到有效的单元测试集最直接的办法,叫做测试驱动开发。我翻译《重构》第二版的时候跟另一个译者林从羽开玩笑说,你告诉任何一个敏捷实施当中遇到的问题,我都可以告诉你这个问题是因为没有做好TDD。

(未完待续)

评论关闭了。