沒有什么東西的總量是在一直增加的：星體間的距離、宇宙中的平均信息量，還有該死的商業(yè)需求。很多文章都說Over-Engineering是個不好的東西，但是它們卻沒說如何避免Over-Engineering。

1. 工程比商業(yè)更重要

工程師們都覺得自己是世界上最聰明的人，因為我們能夠開發(fā)出新的東西。這樣的錯覺總是會讓我們Over-Engineering。但是事實上，如果我們做了100個計劃，商業(yè)總是能提出我們沒有想到的第101個計劃。如果我們解決了1000個問題，商業(yè)會再給我們提出1萬個新問題。我們覺得自己能掌控一切——但是實際上，對于未來會發(fā)生什么，我們完全沒有任何頭緒。 

在我15年的編程生涯里，我從未見過商業(yè)要求“交匯”的情況，它們只會分岔，這是商業(yè)的天性，并不是商業(yè)人士的錯。 

2. 可重復(fù)使用的商業(yè)功能

當商業(yè)給我們提出越來越多的功能要求時，我們有的時候會這樣反應(yīng)： 

我們會盡可能的進行歸類，并且生成其中的邏輯。正是出于這個原因，MVC才會最終變成Fat Model或是Fat Controller。但是我們剛剛提到了，商業(yè)要求只會分岔，不會交匯。因此，我們的反應(yīng)應(yīng)該是這樣的：

在自然系統(tǒng)中，通用的邏輯和抽象概念會隨著時間逐漸趨于穩(wěn)定。在功能變得更廣泛的情況下，他們要么停留在扁平的狀態(tài)，要么慢慢沉沒。否則的話，系統(tǒng)的體積就會變得過大，導(dǎo)致各種錯誤的出現(xiàn)，在這種情況下，你就要對系統(tǒng)進行徹底的重寫了。 

例如，我們曾經(jīng)給一個客戶創(chuàng)建了用戶資料系統(tǒng)。剛開始的時候，我們使用了CRUD控制器，以及通用的功能設(shè)計，因為我們覺得所有人的注冊過程都是相似的。但是結(jié)果我們發(fā)現(xiàn)，用戶有13種注冊流程，這讓我們使用的方法難以為繼。 

3. 所有東西都是通用的

• 想要連接數(shù)據(jù)庫？寫一個通用Adapter吧

• 對那個數(shù)據(jù)庫進行Query？寫一個通用的Query

• 要傳遞一些參數(shù)？通用參數(shù)

• 要架構(gòu)參數(shù)？通用Builder

• 對反應(yīng)進行Map? 通用Data Mapper

• 處理用戶請求? 通用Request

• 執(zhí)行整個系統(tǒng)? 通用Executor

有的時候工程師會對此過于著迷。我們會忘記解決商業(yè)問題，而是將是將浪費在尋找完美的抽象概念上

我們在設(shè)計的時候，總是要試圖滿足真實世界中不斷變化的各種要求。因此，即使我們真的遇上了奇跡，摘到了完美的抽象畫概念，它也會有不再適用的那一天，因為真實世界的要求變了。 

4. 過于粗淺的Wrapper

在使用每一個外部庫之前，我們都會把它包裹起來。不幸的是，我們所使用的大多數(shù)wrapper都非常粗淺。我們在投遞功能性和編寫好的wrapper之間掙扎。我們的wrapper大多數(shù)情況下都與當前的庫緊密結(jié)合。如果我們在未來改變了所使用的庫，它所對應(yīng)的wrapper也必須要改變。有的時候我們還會把業(yè)務(wù)邏輯也放在這個wrapper內(nèi)，這樣導(dǎo)致我們即無法得到好的wrapper，也無法得到好的業(yè)務(wù)解決方案，而是介乎兩者之間的某種粘性層。 

現(xiàn)在已經(jīng)是2016年了，外部庫和客戶端都已經(jīng)得到了快速的發(fā)展。OSS庫就很好，它有著很高的質(zhì)量，一些優(yōu)秀的人寫了很好的數(shù)據(jù)庫。它們大多數(shù)都有著清晰、可測試的API，讓我們可以使用一種標準的Initialize?—?Instrument?—?Implement模式。 

5. 將特性當做工具使用

盲目的使用特性概念（例如將所有變量變成“private final”、為所有類編寫界面等）并不能讓代碼變得更好。 

去看看Enterprise FizzBuzz吧。它有著體量極大的代碼。在微層面上，每一個類都遵循了SOLID原色，使用了各種各樣的優(yōu)秀設(shè)計模式和變成技巧。它在CQM工具中獲得了極高的代碼質(zhì)量評分。 

5.1. 三明治層

我們來簡要說明一下，創(chuàng)建一個結(jié)合緊密的反應(yīng)，并且將其拆分為10或20個三明治曾，每一個單獨的層面都需要整體架構(gòu)來運行。

在過去，我們需要一個連鎖反應(yīng)來實現(xiàn)。A導(dǎo)致B導(dǎo)致C導(dǎo)致D……  

而現(xiàn)在，我們還是在用這種方式，只不錯我們給一個類都添加了界面/執(zhí)行，然后將其注入下一個層面，因為我們現(xiàn)在有了SOLID。

但是SOLID這樣的概念導(dǎo)致了連鎖反應(yīng)和其他OOP概念的濫用。大多數(shù)工程師都不知道這些概念是怎么來的，只是在不斷的使用。 

6. Adopter依賴綜合征

在發(fā)現(xiàn)了Generics之后，現(xiàn)在，就連一個簡單的“HelloWorldPrinter”都變成了“HelloWorldPrinter<String,Writer>”。

在數(shù)據(jù)類型如此明顯的情況下，我們并不需要使用Generics。

在發(fā)現(xiàn)了策略模式后，連“if”條件都變成了一種策略。

為什么？

學(xué)會了DSL之后，我們在哪里都在使用DSL。

在用過Mocks之后，我們就對每一個對象進行模擬。

Metaprogramming真好用，我要在任何地方都使用。

這樣做并不好。

7. <X>–ity

• 可配置性

• 安全性

• 可擴展性

• 可維護性

• 可延伸性

• …

實例1：我們來做一個可延展的CMS吧，負責商務(wù)的同事可以輕松的添加新的領(lǐng)域。

結(jié)果：負責商務(wù)的同事從來就沒用過。當他們必須要添加新領(lǐng)域的時候，他們也會找來一名開發(fā)人員幫他們完成。也許我們需要的只是一個簡單的開發(fā)者指導(dǎo)。 

實例2：我們來設(shè)計一個擁有可配置性的大型數(shù)據(jù)庫層面吧。我們應(yīng)該擁有只用一個Magic文件就可以切換數(shù)據(jù)庫的能力。

結(jié)果：近10年來，我只見過一家公司用過這樣的功能。而在切換數(shù)據(jù)庫的時候，那個Maigc文件并沒有發(fā)揮什么作用。 

實例3：我們來打造一個OAuth系統(tǒng)吧，讓軟件更具安全性。

結(jié)果：如果真的有人要黑我們的系統(tǒng)，他們不會經(jīng)過OAuth層面，他們隨便找一個其他曾的漏洞就黑進來了。

8. 內(nèi)部“發(fā)明”

剛開始的時候你會感覺不錯。但是今年之后，你的發(fā)明就會成為通用資源。例如：

• 內(nèi)部庫(HTTP, mini ORM/ODM, Caching, Config等)

• 內(nèi)部框架(CMS, Event Streaming, Concurrency, Background Jobs, etc)

• In-house tools (Buildchains, Deployment tools等)

9. 跟隨現(xiàn)狀

當某個東西按照某種特定方式部署完成之后，所有人都會在其基礎(chǔ)上進行開發(fā)。沒有人會質(zhì)疑這種現(xiàn)狀。只要代碼能夠工作，我們就默認這種方式為“正確的方式”。 

有的時候現(xiàn)有的方式并不是最簡潔的方式，有的東西完全是可以去除的。 

10. 糟糕的自我評估

很多次我都見過非常優(yōu)秀的團隊做出糟糕的軟件。在看到他們的代碼庫的時候，我們不禁在想：“怎么回事？這真實那個團隊/人做的嗎？”

優(yōu)秀的質(zhì)量不僅需要技巧，還需要時間。一個優(yōu)秀的開發(fā)者總是會高估自己的能力，給自己定了不切合實際的開發(fā)截止日期，導(dǎo)致最終軟件呈現(xiàn)的質(zhì)量讓所有人失望。

過分的自信在項目剛剛開始之前就會毀掉產(chǎn)品的最終質(zhì)量。