后记：新项目来了，大家很兴奋,有机会从头开始构建一个东西，是很难得的。于是仔细小心的设计架构，定下规矩和原则，约定大家都要遵守，刚开始时运转正常，平安无事。
渐渐的出现了一些新情况，需求变动，时间很紧张， 程序员发现有一个非常直接的办法，可以快速的实现客户的要求， 几天就可以搞定， 但是违背了架构的原则或最初的项目的编码约定， 如果想遵循的话，可能需要花费好几倍的工作量，可能需要几周才能完成，更要命的是，为了实现这个新需求，可能需要对整个架构进行调整， 真的调整了，测试跟不上，风险太大， 怎么办?
大多数情况下，程序员都经不起诱惑，也扛不住进度的压力， 会用最直接的办法进行快速修改，“管他呢，先实现再说，反正我还记得细节” ，实际上，改完以后我们又忙着干别的事情去了，过上几个月，自己都看不懂了。久而久之，这些脏代码没有人知道是怎么回事了。
后面接手的程序员就会骂前面的程序员 “这么烂的代码，TMD谁写的!!!???” 然后在上面加上更烂的代码。
【本文为51CTO专栏作者“刘欣”的原创稿件，转载请通过作者微信公众号coderising获取授权】
戳这里，看该作者更多好文
