我曾經在一次演講中，問過聽眾這樣一個問題：“一個方法的理想行數最多不超過多少行？”如果問一千個人，或許會有一千條答案吧。

　　這是一個見仁見智的問題。在《軟件開發沉思錄》一書中，ThoughtWorks的技術負責人Jeff Bay認為：“一個常見的原則是將方法的行數控制在5行之內……”很多人對此感到不可思議。竊以為，關鍵不在于方法的最大行數，而是要合理理解方法的微粒度能為我們帶來什么好處？

　　Jeff Bay提倡“利用IDE提供的‘提取方法’功能，不斷地提取方法中的行為，直到它只有一級縮進為止。如果方法過長，不可能達到如此清晰的可讀性。”Robert C. Martin則強調：“方法的第一規則是要短小。第二條規則還要更短小。”

　　短小的方法更容易理解，更容易重用。這一點毋庸置疑。不過，短小的方法會導致方法數量的急劇增加，這會否對閱讀造成干擾？另一個顧慮則是我們在閱讀方法時，短小的方法必然會導致我們需要在方法之間跳來跳去。

　　這兩個問題，歸根結底還是方法命名的問題。只要方法名稱能夠清晰地表達其意圖，讀其名即可知其實，就沒有必要刨根問底追溯方法的內部實現了。錢鍾書先生拒絕追慕者時，委婉地說道：“假如你吃了個雞蛋覺得不錯，何必認識那下蛋的母雞呢？”閱讀代碼遵循同樣的道理，如果你已經從方法名稱中知曉它的意圖與職責，何必還要解剖方法體的內部呢？而這正是封裝的意義。唯一的例外是你希望學習和挖掘實現的內部機制。

　　至于方法之間的跳轉問題，目前，許多IDE工具已經提供了方便跳轉的功能。因此，不足為慮。

　　好的代碼應該像一篇優秀的散文，明白通暢，清新自然。寫文章要求專注于一件事，不要讓別的無關內容干擾它。如果事情較為棘手，可以將一部分功能字斟句酌，分而治之。編寫可讀性強的代碼尤其需要重視構成代碼的基本元素：方法。雖然在面向對象設計中，我們應以對象的角度思考問題，但對于方法而言，我們仍然可以借鑒面向過程的設計，需要理清該方法履行職責的過程。就好似在心中繪制出方法的流程圖，對流程進行分解，并以各個方法代表每個步驟，就能寫出像散文一般的代碼。

　　一種常見的做法是在實現一個主要方法時，先不去實現具體的代碼，而是寫一些小方法的名稱，即首先完成主方法的模板框架，再分別實現構成主方法的小方法。看似很難，實際上只要運用得當，就會使編碼變得更加輕松。它使得我們能夠從具體的方法實現中解放出來，先確定實現該功能的流程，再考慮每一步的具體實現。

　　例如，我要實現這樣一個方法，它需要通過傳入的ServletRequest對象，獲取某些信息，執行步驟如下所示：
　　1）首先獲得ReportObject對象；
　　2）根據request對象收集必須的參數；
　　3）通過ReportObject對象以及收集獲得參數來組建一個ReportTable對象；
　　4）然后，將ReportTable設置給ExcelReportExporter對象；
　　5）最后，將ExcelReportExporter對象存儲到Session中。

　　我在編寫該方法時，并沒有實現每個步驟的具體細節，而是以各個小方法體現這些步驟，最后再利用Eclipse提供的功能，快速生成這些方法，并實現之。

　　主方法的代碼沒有超過五行，且每一行代碼都通過方法的名稱表達了清晰的功能職責。在閱讀這樣的代碼時，若不需要了解每一步驟的具體細節，則閱讀主方法的實現即可理解其意圖，甚至不需要再為它添加額外的注釋。

　　這并非重構，但與Extract Method重構所要達成的目的一脈相承。

　　這樣分解方法還有一個好處，就是它能夠幫助我們更清晰地分辨職責。當你發現分解出來的方法所履行的職責，與它所屬的類格格不入，或者需要公開給其他類調用時，正是需要重新分配職責的好時機。