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

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

1、Engineering is more clever than Business

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

在研發(fā)生涯中，從未碰到過業(yè)務在需求上是收斂，它們總是發(fā)散的，這是業(yè)務的本來面目，不是產(chǎn)品經(jīng)理的錯

2、Reusable Business Functionality

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

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

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

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

3、Everything is Generic

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

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

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

4、Shallow Wrappers

我們習慣使用外部庫時都封裝一層，這種封裝是淺層的，不幸的是，我們?nèi)菀自谔峁┕δ芎途帉懞玫陌b器之間模棱兩可，混淆著大量的業(yè)務邏輯，使得它既不是一個好的包裝器，也不是一個好的業(yè)務解決方案。實際上要封裝一個優(yōu)質(zhì)的庫，需要投入大量的時間編寫，同時保證高代碼質(zhì)量和完善的代碼測試，具備清晰、可測試的、可測量的API。需要注意的是，封裝應該是例外，不應該是常態(tài)，不要為了封裝而封裝

5、Applying Quality like a Tool

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

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

6、Overzealous Adopter Syndrome

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

發(fā)現(xiàn)了策略模式，現(xiàn)在每個條件語句都是一個策略

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

上面都體現(xiàn)出了過度適配問題

7、–ity

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

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

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

文章翻譯修改自:

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

文章來源：www.liangsonghua.me

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