[[318261]]

后記：新項目來了，大家很興奮,有機會從頭開始構建一個東西，是很難得的。于是仔細小心的設計架構，定下規(guī)矩和原則，約定大家都要遵守，剛開始時運轉正常，平安無事。

漸漸的出現(xiàn)了一些新情況，需求變動，時間很緊張， 程序員發(fā)現(xiàn)有一個非常直接的辦法，可以快速的實現(xiàn)客戶的要求， 幾天就可以搞定， 但是違背了架構的原則或最初的項目的編碼約定， 如果想遵循的話，可能需要花費好幾倍的工作量，可能需要幾周才能完成，更要命的是，為了實現(xiàn)這個新需求，可能需要對整個架構進行調整， 真的調整了，測試跟不上，風險太大， 怎么辦?

大多數(shù)情況下，程序員都經不起誘惑，也扛不住進度的壓力， 會用最直接的辦法進行快速修改，“管他呢，先實現(xiàn)再說，反正我還記得細節(jié)” ，實際上，改完以后我們又忙著干別的事情去了，過上幾個月，自己都看不懂了。久而久之，這些臟代碼沒有人知道是怎么回事了。

后面接手的程序員就會罵前面的程序員 “這么爛的代碼，TMD誰寫的!!!???” 然后在上面加上更爛的代碼。

【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉載請通過作者微信公眾號coderising獲取授權】

戳這里，看該作者更多好文