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

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

1、Engineering is more clever than Business

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

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

2、Reusable Business Functionality

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

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

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

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

3、Everything is Generic

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

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

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

4、Shallow Wrappers

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

5、Applying Quality like a Tool

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

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

6、Overzealous Adopter Syndrome

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

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

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

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

7、–ity

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

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

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

文章翻譯修改自:

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

文章來源：www.liangsonghua.me

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