预计阅读本页时间：-
2. 欲速则不达
"你不需要真正地理解那块代码,它只要能够工作就可以了.哦,它需要一个小小的调整.只要在结果中再加上几行代码,它就可以工作了.干吧!就把那几行代码加进去,它应该可以工作."我们经常会遇到这种情况,出现了一个bug,并且时间迫切.快速修复确实可以解决它---只要新加一行代码或者忽略那个列表上的最后一个条目,它就可以工作了.但接下来的做法才能说明,谁是优秀的程序员,谁是拙劣的代码工人.
拙劣的代码工人会这样不假思索地改完代码,然后快速转向下一个问题.
广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元
优秀的程序员会挖掘更深一层,尽力去理解为什么这里必须要加1,更重要的是,他会想明白会产生什么其他影响.
也许这个例子听起来有点做作,甚至你会觉得很无聊.但是,真实世界中有大量这样的事情发生.Andy以前的一个客户正遇到过这样的问题.没有一个开发者或者架构师知道他们业务领域的底层数据模型.而且,通过几年的累计,代码里有成千上万的+1和-1修正.在这样脏乱的代码中添加新的功能或者修复bug,就难逃脱发的噩运(事实上,很多开发者因此而秃顶).
千里之堤,毁于蚁穴,大灾难是逐步演化来的.一次又一次的快速修复,每一次都不探究问题的根源,久而久之就形成了一个危险的沼泽地,最终会吞噬整个项目中的生命.
在工作压力下,不去深入了解真正的问题以及可能的后果,就快速修改代码,这样只是解决表面问题,最终会引发大问题.
快速修复的诱惑,很容易令人把持不住,坠入其中.短期看,它似乎使有效的.但从长远来看,无异于穿越一片沙流,你也许侥幸走过了一半的路程(甚至更远),一切似乎都很正常.但是转眼间悲剧就发生了....
只要我们继续进行快速修复,代码的清晰度就不断降低.一旦问题累计到一定程度,清晰的代码就不复存在,只剩一片浑浊.很可能在你的公司就有人这样告诉你:"无论如何,千万不能碰那个模块的代码.写代码那哥们已经不在这儿了,没有人看得懂他们的代码."这些代码根本没有清晰度可言.它已经成为一团迷雾,无人能懂.
如果你在团队中这样的事情发生,那么你是不可能敏捷的.但是敏捷方法中的一些技术可以阻止这样的事情发生.这里只是一些概述,后面的章节会有更深入的介绍.
孤立非常危险,不要让开发人员完全孤立地编写代码(见第155页,习惯40).如果团队成员花些时间阅读其他同事写的代码,他们就能确保代码是可读和可理解的,并且不会随意加入这些"+1或-1"的代码.阅读代码的频率越高越好.实行代码复审,不仅有助于代码更好理解,而且是发生bug最有效的方法之一(见第165页,习惯44).
另一种防止代码难懂的重要技术就是单元测试.单元测试帮助你很自然地把代码分层,分成很多可管理的小块,这样就会得到设计更好,更清晰的代码.更深入项目的时候,你可以直接阅读单元测试---它们是一种可执行的文档(见第78页,习惯19).有了单元测试,你会看到更小、更易于理解的代码模块,运行和使用代码,能够帮助你彻底理解这些代码.
： 不要坠入快速的简单修复之中.要投入时间和精力保持代码的整洁、敞亮。
切身感受
在项目中，代码应该是很亮堂的，不应该有黑暗死角。你也许不知道每块代码的每个细节，或者每个算法的每个步骤，但是你对整体的相关知识有很好的了解。没有任何一块代码被警戒线或者"切勿入内"的标志隔离开.
平衡的艺术
□ 你必须要理解一块代码是如何工作的,但是不一定需要成为一位专家.只要你能使用它进行有效的工作就足够了,不需要把它当作毕业生事业.
□ 如果有一位团队成员宣布,有一块代码其他人都很难看懂,这就意味着任何人(包括原作者)都很难维护它.请让它变得简单些.
□ 不要急于修复一段没能真正理解的代码.这种+1/-1的病症始于无形,但是很快就会让代码一团糟.要解决真正的问题,不要治标不治本.
□ 所有的大型系统都非常复杂,因此没有一个人能完全明白所有的代码.除了深入了解你正在开发的那部分代码之外,你还需要从更高的层面来了解大部分代码的功能,这样就可以理解系统各个功能块之间都是如何交互的.
如果系统的代码已经恶化,可以阅读第23页习惯4中给出的建议.
