鏈接：http://985.so/kfSG
一切都源於“明天就要上線”，“下週就要上線”這樣不切實際的要求
後記：新項目來了，大家很興奮,有機會從頭開始構建一個東西，是很難得的。於是仔細小心的設計架構，定下規矩和原則，約定大家都要遵守，剛開始時運轉正常，平安無事。
漸漸的出現了一些新情況，需求變動，時間很緊張， 程序員發現有一個非常直接的辦法，可以快速的實現客戶的要求， 幾天就可以搞定， 但是違背了架構的原則或最初的項目的編碼約定， 如果想遵循的話，可能需要花費好幾倍的工作量，可能需要幾周才能完成，更要命的是，為了實現這個新需求，可能需要對整個架構進行調整， 真的調整了，測試跟不上，風險太大， 怎麼辦？
大多數情況下，程序員都經不起誘惑，也扛不住進度的壓力， 會用最直接的辦法進行快速修改，“管他呢，先實現再說，反正我還記得細節” ，實際上，改完以後我們又忙著幹別的事情去了，過上幾個月，自己都看不懂了。久而久之，這些髒代碼沒有人知道是怎麼回事了。
後面接手的程序員就會罵前面的程序員 “這麼爛的代碼，TMD誰寫的！！！？？？” 然後在上面加上更爛的代碼。
最後我自己是一名從事了多年開發的JAVA老程序員，今年年初我花了一個月整理了一份最適合2019年學習的java學習乾貨，想分享給每一位喜歡java的小夥伴，需要獲取的可以關注我並在後臺私信我：01，即可免費領取。
分享到:
閱讀更多 一個老農程序員 的文章
