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