一種流行的方法是通過技術層面對專案進行分包。但是這種方法有一些缺點。相反，我們可以按功能分包並建立獨立自治的程式包。結果是一個易於理解且不易出錯的程式碼庫。  ## 整體分析 按照技術分包造成的缺點： 1. 對屬於某個功能的所有類的概述不佳。 2. 通用程式碼、重用程式碼和複雜程式碼趨向於難以理解，並且由於難以把握變更的影響，因此變更很容易破壞其他功能用例。 按功能分包從而建立包含功能所需的所有類的程式包。好處是： 1. 更好的可發現性和概覽 2. 獨立且自治 3. 更簡單的程式碼 4. 可測試性 5. 便於團隊協作開發 ## 按照技術分層分包 專案結構的一種非常流行的方法是逐層分包。這將為每個技術組所屬類提供一個軟體包。  ⚠️：*按層分包從技術角度對所有類進行分組* 讓我們將呼叫層次結構新增到圖片中，以“清楚地”瞭解哪個類取決於其他哪個類。  ⚠️：*呼叫層次結構遍及整個專案，涉及許多包* 那麼，按層分包的缺點是什麼？ 1. **功能概述不佳。**通常，當我們在專案中處理程式碼時，我們首先會想到要更改的特定領域或功能。因此，我們會從領域的角度出發。不幸的是，按技術分層分包迫使我們從一種軟體包過渡到另一種軟體包，才能掌握功能的概況。 2. **通用，重用和複雜程式碼的趨勢。**通常，這種方法導致中心類包含每個功能用例的所有方法。隨著時間的流逝，這些方法越來越抽象化（帶有額外的引數和泛型）來滿足更多用例。上圖中僅一個示例是ProductDAO，其中放置了ProductController和ExportController的方法。結果是： - 當新增更多方法時，類將變得更大。因此，僅憑程式碼量，就很難理解它。 - 更改通用重用程式碼很危險。儘管您只想處理一個用例，但您可以輕鬆地打破所有用例。 - 由於以下兩個原因，難以理解抽象方法和通用方法：首先，要通用，通常需要其他技術構造（例如，switch，引數，泛型），這使得檢視與當前用例相關的業務邏輯更加困難。其次，認知需求更高，因為您必須瞭解所有其他用例，以確保您不會破壞它們。 **桑迪·梅斯（Sandi Metz）指出：** > “我覺得我必須瞭解所有內容才能提供幫助。”桑迪·梅斯（Sandi Metz）。請參閱我的帖子，瞭解我們的[編碼智慧牆。](https://phauer.com/2020/wall-coding-wisdoms-quotes/) ⚠️：**我們達到了DRY，但違反了KISS。** --- ## 按功能（特性）分包 讓我們將這些類重新排列成獨立的功能包。