? 最近由于部門的轉(zhuǎn)換，到了一個新的項目組， 由于這個項目之前經(jīng)過很多人的手，代碼閱讀和擴(kuò)展已經(jīng)變得不是很好，已經(jīng)能明顯的聞到壞代碼的味道，每次新功能的上線往往伴隨著更多的代碼冗余和新的bug。

? 于是項目經(jīng)理決定改善代碼質(zhì)量，做法是強(qiáng)調(diào)規(guī)范，注重流程。這是個方案估計是目前大都是項目團(tuán)隊解決代碼質(zhì)量采用最多的方法，優(yōu)勢在于有了一個"標(biāo)準(zhǔn)"，而標(biāo)準(zhǔn)就是為了實現(xiàn)通用性，但是標(biāo)準(zhǔn)只是解決了淺層的問題，要更好實現(xiàn)一個應(yīng)用的可持續(xù)穩(wěn)定擴(kuò)展性，是個需要深層發(fā)掘的。

? 現(xiàn)在的企業(yè)應(yīng)用一般都是遵循迭代模式開發(fā)，好處是：

? 1） 高效：重要的功能先開發(fā)，附屬增值模塊后續(xù)上線

? 2）底風(fēng)險：一些模塊啟用關(guān)閉，可以在短時間內(nèi)上下線，這也是web軟件的優(yōu)勢

? 3）高通用：邊反饋邊開發(fā)，及時了解用戶需要，一定成度上滿足了各種用戶的需求，同時也使失敗幾率降低

? 4）可控性：團(tuán)隊不會因為“多模塊”等長期處于分散情況下

??? 鑒于迭代的這么多優(yōu)勢，很多線上軟件都是采用邊了解需求，邊上線的做法。

??? 但是正式由于這種方式，使得軟件設(shè)計代碼質(zhì)量的高要求，原因在于后期功能的開發(fā)往往依附于早期基石之上，在一個壞的地基上永遠(yuǎn)建不了高樓。

???? 這是一個迭代過程：

??? 初始：需求的了解；需求UC

??? 細(xì)化：系統(tǒng)設(shè)計（測試驅(qū)動用例）；領(lǐng)域模型，詳細(xì)類圖

??? 構(gòu)造：代碼實現(xiàn)，測試用例（規(guī)范）

??? 發(fā)布：回歸，文檔備案，總結(jié)，下次迭代準(zhǔn)備

?? 可以看到規(guī)范只在構(gòu)造中起了作用，而細(xì)化一定程度上是構(gòu)造的模具，而往往被忽略的就是設(shè)計。

?? 細(xì)化設(shè)計雖然不能帶來什么效益，沒有它依然能實現(xiàn)應(yīng)用，但我們不是開發(fā)半年一年的應(yīng)用，而是三五年的應(yīng)用。每次的設(shè)計都需要為下次的增量而作準(zhǔn)備。

可持續(xù)發(fā)展的迭代開發(fā)