避免過度設計
- 2019 年 10 月 3 日
- 筆記
許多文章都在強調不要過度設計自己的系統，但是沒有道出個所以然來，所以本文列出一些經典的過度設計，希望能給你帶來啟發，在工程上做一些平衡，避免過度設計把我們推到另外一個複雜度上
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、<X>–ity
例子1、實現一個CMS系統，要求具備可擴展性，業務人員可輕鬆添加字段
結果：業務人員從來不使用這個功能，當他們需要時，會要求工程師在旁邊協助，也許我們所需要的只是一個簡單的開發人員指南，可以在幾個小時內添加一個新字段，而不是點擊式界面
例子2：設計一個可輕鬆配置的包羅萬象的數據庫層，我們可以通過文件配置輕鬆切換數據源
結果: 過了很長時間因為某種原因需要切換數據源，但是修改配置文件無法滿足我們的要求，現在業務有了很多的功能差距，導致不兼容
實際上，建議將數據庫視為解決方案的一部分，拋棄可配置性，否則很難保證兼容性。當設計時，多問自己使用場景是什麼，然後深挖下去，你可能會發現大部分特性都是沒有必要的，包括可配置性、安全性、可擴展性、可維護性、可繼承性。總之，不要在沒有被要求時加上各種特性，應該明確地定義與評估場景、用戶故事、需求、用途
文章翻譯修改自:
https://medium.com/@rdsubhas/10-modern-software-engineering-mistakes-bc67fbef4fc8
文章來源：www.liangsonghua.me
作者介紹：京東資深工程師-梁松華，在穩定性保障、敏捷開發、JAVA高級、微服務架構方面有深入的理解
