淺談敏捷開發(fā)思想中的簡單最好原則
極限編程堅持只為今天的需求設(shè)計以及編碼，而不用考慮明天。這頗有一些“做一天和尚撞一天鐘”的意味。
這個原則帶來一個問題，那就是我們還需要設(shè)計嗎？
我們強調(diào)設(shè)計，其目的就在于設(shè)計出合理、優(yōu)雅的結(jié)構(gòu)，以提供具有良好復(fù)用性與可擴展性的系統(tǒng)，這是一種未雨綢繆，為未來考慮。而現(xiàn)在，我們?nèi)粢裱璌ISS原則，就是不再考慮明天的需求。顯然，這兩者的觀點是相悖的。于是，矛盾出現(xiàn)：一方面我們需要保持設(shè)計簡單，不做無謂的功能預(yù)測；另一方面，我們又需要擁抱變化，在盡可能少的改變結(jié)構(gòu)與代碼的情況之下，滿足未來的需求。
如何解決這個矛盾。讓我們先看看提出簡單原則的初衷。在《敏捷開發(fā)思想之擁抱變化》一篇中，我提到需求的變化是不可避免的。即使是最優(yōu)秀的需求分析師和架構(gòu)設(shè)計師都不可能在項目之初窮盡所有客戶要求的功能，作出最完美的分析與設(shè)計，即做到“增之一分則太多，減之一分則太少”。我們需要把握分析和設(shè)計的“度”。但事實卻是，我們總喜歡越俎代庖，利用自己的經(jīng)驗幫助客戶提出需求，而事后證明這些需求往往是多余的。我們總是在重復(fù)做著“吃力不討好”的事情，與其如此，還不如在事先偷懶取巧。因為需求的變化總是不可控的，根據(jù)“利益趨避原則”，自然應(yīng)選擇對自己更有利的一個趨向。
但這種簡單并不是“簡陋”，即使我們不需要考慮明天的需求，一些好的重用原則與可擴展原則仍然需要遵循。例如，我們應(yīng)盡量保證對象是高內(nèi)聚、低耦合的；我們應(yīng)遵循“面向接口編程”原則。一言以蔽之，我們需要做到：
1、減少依賴；
2、合理抽象；
3、功能最簡。
簡單設(shè)計還需要重構(gòu)來保證設(shè)計的質(zhì)量。我們之所以敢于奢談“簡單”，正是因為重構(gòu)的保障。即使設(shè)計過于粗陋，合理利用重構(gòu)也能夠亡羊補牢。在重構(gòu)過程中，我們?nèi)匀恍枰裱唵卧瓌t，僅為當(dāng)前的需求對系統(tǒng)結(jié)構(gòu)進行重構(gòu)。例如，我們在最初的需求分析中，只有一個功能要求發(fā)送電子郵件。那么，我們可以編寫一個方法來封裝發(fā)送電子郵件的實現(xiàn)，這個方法甚至可以放在業(yè)務(wù)對象的私有方法中。隨著需求的逐步演進，新增的幾個功能同樣需要發(fā)送電子郵件，此時就有必要利用重構(gòu)技術(shù)，將原來發(fā)送電子郵件的方法獨立到單獨的類中。但是，基于簡單原則，我們沒有必要完善所有功能，例如增加發(fā)送Meet Request的功能。因為目前的需求并不需要。
“簡單”并不只限于設(shè)計。在敏捷開發(fā)過程中，我們還需要保證項目計劃的簡單，以及文檔的簡單，乃至于過程的簡單。項目計劃的簡單可以由小步行進的迭代周期來保證，通過對項目階段的分解，簡化項目計劃。至于文檔的簡單，我們完全可以拋棄復(fù)雜標(biāo)準(zhǔn)的文檔模板，轉(zhuǎn)而書寫僅僅是自己需要關(guān)注的內(nèi)容。至少，項目內(nèi)部的文檔完全可以言之有物，而不需要注重形式。我們還可以通過對項目過程進行裁剪，來保障過程的簡單性。事實上，在極限編程中，很多原則和實踐都是為了實現(xiàn)簡單而提出的。例如計劃游戲、小版本、簡單設(shè)計，包括持續(xù)集成和代碼所有權(quán)，都是為了提高開發(fā)過程的效率，這實際上也是簡單的一種體現(xiàn)。
敏捷開發(fā)思想中“簡單最好”是一種心態(tài)，更是一條原則。
【編輯推薦】
