摘要：許多文章都在強調不要過度設計自己的系統，但是沒有道出個所以然來，所以本文列出一些經典的過度設計，希望能給你帶來啟發，在工程上做一些平衡，避免過度設計把我們推到另外一個復雜度上工程師通常認為自己是最聰明的，這第一個錯誤容易讓自己過于工程化。

許多文章都在強調不要過度設計自己的系統，但是沒有道出個所以然來，所以本文列出一些經典的過度設計，希望能給你帶來啟發，在工程上做一些平衡，避免過度設計把我們推到另外一個復雜度上

1、Engineering is more clever than Business

工程師通常認為自己是最聰明的，這第一個錯誤容易讓自己過于工程化。我們計劃了100件事，業務方會提出我們之前沒有考慮到的第101件。如果我們解決了100個問題，那么接下來還可能會有1000個問題。我們以為一切都是掌握之中，然而實際完全不知道未來會發生什么

在研發生涯中，從未碰到過業務在需求上是收斂，它們總是發散的，這是業務的本來面目，不是產品經理的錯

2、Reusable Business Functionality

當業務方提出了越來越多的需求時，我們第一反應是盡量分組和泛化業務，這是大部分MVC架構最后成為由大量模型或者控制器堆積的原因，正如前面所說的，業務永遠不會是收斂的，它們總是發散的

在系統中，共享邏輯和抽象應該是趨于穩定的，然而隨著功能迭代越來越多，它們要么會保持平穩，要么會變得脆弱。當相反的情況發生時，就會成為太大而失敗的系統

比如說，有個業務是實現用戶屬性管理，我們持著任何東西都是相似的這種觀點，首先完成通用的CRUD邏輯，但是這個需求實際上要求滿足13個不同的注冊流程，也就是說通用的邏輯代碼沒有任何意義。同理，一個訂單視圖和訂單編輯視圖流程是完全不一樣的，可偏偏有些人會合并視圖

我們在橫向分割業務前，應該先嘗試縱向分割，同時也要考慮從一種方式切換到另外一種方式的可操作性和便捷性，否則重寫系統將是災難性的工作，也就是說分離行為比強行合并好

3、Everything is Generic

需要連接數據庫，那就寫個通用的泛化適配器
需要查詢數據庫，那就寫個泛化查詢
需要對參數進行校驗，那就寫個通用的參數校驗器
需要對結果進行包裝，那就寫個通用的數據映射器
等等

當在實現需求時，浪費大量的時間嘗試總結出完美的抽象層，甚至原本業務問題的答案非常顯而易見。即使奇跡般地總結出了一個完美的抽象時，它往往會很快變得不適用，目前最好的代碼設計側重點應該是編碼易于被刪除的，而不是盲目追求易于擴展

實際上，重復代碼比錯誤的抽象更好，只有當你看到系統里有邏輯重復的代碼，才能更好地進行抽象，同時重復代碼暴露了許多用例，有助于使得邊界上下文清晰

4、Shallow Wrappers

我們習慣使用外部庫時都封裝一層，這種封裝是淺層的，不幸的是，我們容易在提供功能和編寫好的包裝器之間模棱兩可，混淆著大量的業務邏輯，使得它既不是一個好的包裝器，也不是一個好的業務解決方案。實際上要封裝一個優質的庫，需要投入大量的時間編寫，同時保證高代碼質量和完善的代碼測試，具備清晰、可測試的、可測量的API。需要注意的是，封裝應該是例外，不應該是常態，不要為了封裝而封裝

5、Applying Quality like a Tool

高質量的代碼通常滿足SOLID原則，使用相應的設計模式和代碼技術，比如factory、builder、strategy、generics、enums。如果你不加思索地運用質量概念，比如說將所有的變量修飾修改為private final，這并不能將編碼質量提高，或者改變過去鏈式繼承的方式，每個類都有接口和實現，然后注入到下一層，看似滿足SOLID概念。實際上SOLID的設計初衷是為了反對濫用繼承與其他OOP概念，然而大部分工程師沒有搞清楚這些概念從哪里來，如何出現，只是照單全收，沒有從思維上消化，只是工具化地盲目應用

學習一門其他語言，嘗試以另外的思維模式去做事情，這樣會成為一個更好的開發者。新瓶裝舊酒對我們沒有任何幫助，我們不必為了應用一個新概念而弄亂一個清晰的設計

6、Overzealous Adopter Syndrome

發現了泛型技術，將一個簡單的 “HelloWorldPrinter” 修改成了“HelloWorldPrinter”，那怕事實上只會有特定的數據類型，或者有足夠的普通類型簽名

發現了策略模式，現在每個條件語句都是一個策略

到處使用枚舉/擴展方法/Traits等各種炫酷的技術

上面都體現出了過度適配問題

7、–ity

例子1、實現一個CMS系統，要求具備可擴展性，業務人員可輕松添加字段
結果：業務人員從來不使用這個功能，當他們需要時，會要求工程師在旁邊協助，也許我們所需要的只是一個簡單的開發人員指南，可以在幾個小時內添加一個新字段，而不是點擊式界面

例子2：設計一個可輕松配置的包羅萬象的數據庫層，我們可以通過文件配置輕松切換數據源
結果: 過了很長時間因為某種原因需要切換數據源，但是修改配置文件無法滿足我們的要求，現在業務有了很多的功能差距，導致不兼容

實際上，建議將數據庫視為解決方案的一部分，拋棄可配置性，否則很難保證兼容性。當設計時，多問自己使用場景是什么，然后深挖下去，你可能會發現大部分特性都是沒有必要的，包括可配置性、安全性、可擴展性、可維護性、可繼承性。總之，不要在沒有被要求時加上各種特性，應該明確地定義與評估場景、用戶故事、需求、用途

文章翻譯修改自:

https://medium.com/@rdsubhas/...

文章來源：www.liangsonghua.me

作者介紹：京東資深工程師-梁松華，在穩定性保障、敏捷開發、JAVA高級、微服務架構方面有深入的理解