/ Coach

Refactor之痛

Clean up

实践敏捷开发这么多年来,我十分清楚重构重要性,不断清理代码,如同吃完饭要洗碗清理厨房,要经常打扫房间。然而实际上我并没有经常打扫房间,虽然我“知道”要经常打扫,结果只是偶尔想起来做一下。直到有一次出差了一段时间回到家发现,桌上灰层实在是太多,键盘,鼠标,鼠标垫上都是厚厚灰层。我无法忍受了,都不愿意碰鼠标和键盘了,对于我这个“技术宅”这事可大条了,我得去清理了。拿起抹布开始清理桌子,发现地上也很脏,扫地拖地吧。再出现这样的情况我可受不了,得预防一下吧,那就定期做一下清洁工作吧。我还是比较懒的,那就一个星期做一次吧。我突然意识到我现在的教练工作不也是同样的道理么。

教练不是上来就解决问题,反而要通过一系列迫使他真正意识到自己的问题(“你们的代码太垃圾”,“难以修改,耦合高,可读性差”,“没有单元测试”这时貌似还是教练的问题,不是他们的),让他痛(碍他事了,这是他的问题了,这很重要,这是持续去做的动力),然后再来和他一起想办法解决。比如一个传统团队各种KPI,发版压力迫使他们不断前进,项目出现各种问题,质量,延期等等。这时教练给他们提重构代码,单元测试,持续集成等工程实践,他们能理解这些的好处,可实际上不会真去做,或者只是应付一下。这时比如可以先帮助他们开始迭代(实践Scrum),几个迭代后,团队不断的根据自己Capacity调整scope,团队成员的压力略有降低,这时开发人员发现修改代码代价越来越高,无法互相修改对方的代码,要加一个功能,看到代码头大无比,完全不想碰这代码,又得硬着头皮上,工作效率越来越低,写代码越来越痛苦。测试要测试的东西越来越多,抱怨开发人员总是没有自测,太多显而易见的问题,回归代价越来越大,需要不断加班完成测试,质量问题越来越严重。这时教练可以尝试和开发人员一起结对工作:
“这里逻辑很复杂,理解和修改都比较困难,不敢改动,怕影响原有逻辑。”
“我们来看看这里都做了有哪些事。”
“似乎这个函数太多职责,不妨剥离一下。”
“这一段是个单独的逻辑,提取一个方法出来。”
“这里比较复杂,整理起来改动较多,风险较大,我们来写些测试来确保原有逻辑。”
“测试写好了,运行一下测试,没问题,checkin一下。”
“好了,这下可以放心整理了。”
“恩,这段代码清晰多了。”
“运行一下测试,通过,checkin。”
“我们现在要加的功能是什么?可以先写个测试来描述么?”
……
因为有教练的时间投入——这是个隐性成本,难以发觉——两个人很快实现了功能,还得到了不错的代码和测试。团队体验到了痛,又尝到了不一样做法的甜头,开始感兴趣了。虽然你没有跟他们说我们做了重构,持续集成,TDD,结对等这些名词,但他们已经开始做了,之后还会继续做,因为痛过,不想再痛,要预防就会在痛之前提前做一下清理,虽然还不够频繁,但毕竟他们开始朝着正确的方向前进了。
这时可以给大家讲讲段子了:大家都见过用砖砌墙吧,砌墙之前要做什么?要拉一根基准线,然后按照这根基准线砌墙,对吧?但是有个行业却是先砌墙后拉线,很奇怪吧?这个行业叫软件开发。(谢谢姜志辉同学的段子,哈哈)通过段子引出单元测试,TDD,重构等工程实践,帮助大家理解这些实践,以及背后的思想。

Jackson Zhang

Jackson Zhang

Odd-e敏捷教练,主要涉及组织,团队,产品,技术,工程实践等,曾为多家知名企业提供教练与培训服务。译有《用户故事与敏捷方法》,《.NET单元测试的艺术》和《实例化需求说明》。擅长工程实践(如测试驱动开发,单元测试,重构,持续集成等),产品探索(Impact Mapping,Pretotyping,Lean Startup等)与团队协作。zbcjackson AT gmail.com

Read More