魔鬼告诉你：“你不需要真正地理解那块儿代码，只要它能够工作就可以了。只要在结果中再加上几行代码，它就可以工作了。干吧！就把那几行代码加进去，它应该可以工作。”

我们经常会遇到这种情况，出现了一个bug，并且时间紧迫。快速修复确实可以解决它——只要新加一行代码或者忽略那个列表上的最后一个条目，它就可以工作了。但接下来的做法才能说明，谁是优秀的程序员，谁是拙略的代码工人。

拙略的代码工人会这样不假思索地改完代码，然后快速转向下一个问题。

优秀的程序员会挖掘更深一层，尽力去理解为什么这里必须要加1，更重要的是，他会想明白会产生什么其他影响。

这个例子听起来有点做作，甚至你会觉得很无聊。但是，真实世界中有大量这样的事情发生。Andy以前的一个客户正遇到过这样的问题。没有一个开发者或者架构师知道他们业务领域的底层数据模型。而且，通过几年的积累，代码里有着成千上万的+1和-1的修正。在这样的脏乱的代码中添加新的功能或者修复bug，就难逃脱发的噩运（事实上，很多开发者因此而秃顶）。

千里之堤，溃于蚁穴，大灾难是逐步演化来的。一次又一次的快速修复，每一次都不探究问题的根源，久而久之就形成了一个危险的沼泽池，最终会吞噬整个项目的生命。

防微杜渐。 Beware of land mines.

在工作压力之下，不去深入了解真正的问题以及可能的后果，就快速修改代码，这样只是解决表面问题，最终会引发大的问题。快速修复的诱惑，很容易令人把持不住，堕入其中。短期看，它似乎是有效的。但从长远来看，它无异于穿越一片流沙，你也许侥幸走过了一半的路程（甚至更远），一切似乎都很正常。但是转眼间悲剧就发生了……

只要我们继续进行快速修复，代码的清晰度就不断降低。一旦问题积累到一定程度，清晰的代码就不复存在，只剩一片浑浊。很可能在你的公司里有人这样告诉你：“无论如何，千万不能碰那个模块的代码。写代码那哥们儿已经不在这儿了，没有人看得懂他的代码。”这些代码根本没有清晰度可言，它已经成为一团迷雾，无人能懂。

如果在你的团队中有这样的事情发生，那么你是不可能敏捷的。但是敏捷方法中的一些技术可以阻止这样的事情发生。

孤立非常危险，不要让开发人员完全孤立的编写代码。如果团队成员花些时间阅读其他同事写的代码，他们就能确保代码是可读和可理解的，并且不会随意加入这些“+1或-1”的代码。阅读代码的频率越高越好。实行代码复审，不仅有助于代码更好的理解，而且是发现bug的最有效的方法之一。

另一种防止代码难读的重要技术就是单元测试。单元测试帮助你很自然的把代码分层，分成很多可管理的小块儿，这样就会得到设计更好、更清晰的代码。更深入项目的时候，你可以直接阅读单元测试——它们是一种可执行的文档。有了单元测试，你会看到更小、更易于理解的代码模块，运行和使用代码，能够帮助你彻底理解这些代码。

不要堕入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。

在项目中，代码应该是很亮堂的，不应该有黑暗死角。你也许不知道每块代码的每个细节，或者每个算法的步骤，但是你对整体的相关知识有很好的了解。没有任何一块儿代码被警戒线隔离开。

平衡的艺术

    你必须要理解一块代码是如何工作的，但是不一定需要成为一位专家。只要你能够使用它进行有效的工作就足够了，不需要把它当作毕生事业。
    如果有一位团队成员宣布，有一块代码其他人很难看懂，这就意味着任何人（包括原作者）都很难维护它。请让它变得简单些。
    不要急于修复一段没能真正理解的代码。这种+1/-1的病症始于无形，但是很快会让代码一团糟。要解决真正的问题，不要治标不治本。
    所有的大型系统都非常复杂，因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外，你还需要从更高的层面来了解大部分代码的功能，这样就可以理解系统各个功能块之间是如何交互的。