KISS My YAGNI

        英文原文：KISS My YAGNI

        我們都知道 KISS (Keep It Simple, Stupid)和 YAGNI (You Ain’t Gonna Need It)軟件開發原則，然而，過度復雜的軟件仍然隨處可見。

        假設我們需要一個應用服務。沒錯，缺少分布式事務管理系統是不行的。而且需要一個消息隊列——用來實現系統低耦合。哦，我們的業務邏輯看起來有很多的業務規則，那就用規則引擎來管理吧。還需要一個 ESB，沒錯，ESB——沒有它如何能讓我們分布式的多個模塊相互獨立不依賴？數據庫？當然是 Oracle。但 CouchDB 和 Cassandra 也是需要的，因為關系型數據庫有時不善于做某些事，我們需要更高的性能。我們還需要一些額外的應用層。還需要一些 facades。還有模塊化——我們可不希望我們的應用是鐵板一塊，否則如何能復用我們的組件？你說對了，我們要使用 OSGi，這個東西很適合我們。我忘了說 Web Services 嗎？SOA 很重要。并且 ESB 是少不了它的。

        即使沒有架構師來設計，這些技術也會很自然的出現在架構設計中。每一樣都看起來合情合理，無可厚非。

        不。YAGNI (你不需要它們)。你開發的業務系統極有可能只有幾百人同時在線，有可能只有一些業務邏輯，其余的都是大量的不報表和統計。為了實現一個可用的、而且簡單好維護的軟件應用，你不需要上面提到的那些技術架構。

        我是不是有些自相矛盾？因為之前我還堅持說 frameworks are there for your good，能夠降低軟件的復雜度，但現在卻宣稱應該遠離那些技術和框架。其實并不沖突。

        如果后來證明你真的需要一個消息隊列模塊——那就增加，把同步調用代碼替換成發送消息隊列的代碼。如果后來你的 postgresql/mysql 數據庫不能很好的處理這樣大的數據，那就換成 Oracle。如果你的用戶開始增加到百萬級，那就考慮 Cassandra。你只需要重寫那些 DAO 類就行了。如果后來發現需要在系統里集成很多第三方的軟件，那就研究一下 ESB。如果你發現在很多項目間需要將一些代碼拷來拷去，那就歸納提煉，做成可復用的組件。

        但不是在這種需求出現之前就做這些事情。因為系統會因為它們而變得復雜度陡增，很難迭代，尤其是當團隊里并不是每個人都熟悉這些技術的情況下。

        這是在倡導在計劃中走一步看一步嗎？難到我們積累的經驗不能讓我們事先判斷將會需要什么嗎？是的，我們可以有預見，但那是在有足夠的數據支持下。在項目的前期，我們幾乎什么數據都沒有。

        有兩種東西我們知道可能會是需要的。第一，實用工具。那些能簡化我們的工作的工具。例如，ORM，它通常(但并不是總數)能簡化我們的數據庫訪 問。一個依賴反射注入框架，它能簡化代碼之間的交互。其次是子系統。某種形式上的消息隊列服務系統，NoSQL 數據庫，ESB，這些都是子系統。它們并不屬于我們的系統的原生部分，它們不是工具。它們會增加開發、配置、部署的復雜度。我們自己需要去評估使用它們給 系統造成的影響，是否值得一用。

        在“凡事自己動手”的錯誤做法和 YAGNI 開發原則之間其實有清楚的界限。這都是常識。這是我們的經驗發揮作用的地方——判斷什么是最好的工作輔助工具，什么只是很酷的“也許會有幫助”的工具。

        當有人對我說“讓我們使用X來實現Y吧，”我會說：“不，我們要保持簡單。我們現有的技術架構能處理它”。這樣做的結果就是：更簡單的軟件。易于維護，易于讓新手接手。而且不失功能性。