问题
我们经常遇到这种情况：出现了一个bug 并且时间紧急，快速修复就可以解决它——只需要新加一行代码，或者忽略那个列表上的最后一个条目，他就可以工作了。但是 是不是应该考虑一下这样操作的合理性。
拙劣的代码工人会这样不假思索的改完代码，然后切换到下一个问题
但是优秀的程序员会更深挖一层，去理解这里为什么要加 1 ，还会检查一下会不会产生其他的影响。
后果
千里之堤毁于蚁穴，大灾难是演化而来的。一次又一次的快速修复，每一次都不探究问题的根源，代码的清晰度就会不断降低，可能你侥幸走过了一半的路程，但是问题持续积累，最终你的代码会变成沼泽地，无法阅读。
So
- 在修改代码之前一定要很好的理解他。同样的道理，你也需要了解团队开发方法和开发过程。你必须理解团队采用的开发方法。你必须理解如何恰如其分的使用这种方法。只有理解了这些问题。你才能有效改变。
- 不要孤立的编码， 不要让开发人员孤立的编写代码。如果团队成员花时间阅读其他同事写的代码。他们就可以保证。他们的代码是可读和可理解的。实行代码复审,可以帮助你刚了解代码，并且这是发现bug最有效的方法。
- 使用单元测试,防止代码难懂的最重要的技术就是单元测试。单元测试可以帮助你很自然的吧代码分层。
最后，不要坠入快速的简单修复中，要投入时间和经历保持代码的整洁、敞亮
