沒有銀彈：談談軟件設計的幾個矛盾
最近在做項目的重構和功能改進，設計做了很多，也發(fā)生了一些爭執(zhí)。其實總結下來，很多爭執(zhí)的內容其實早就是經(jīng)典的問題。這些問題沒有孰優(yōu)孰劣，具體采用哪種方案，還得因地制宜，詳細分析項目需求和復雜度之后，再做決定。之前很多人都試圖只從宏觀指導思想來決定設計，最后大家誰也不服誰，所以先把問題確定下來，至少以后思考問題會直接一點。
1. 拆分與合并
從現(xiàn)實世界來說，事物本身就是互相聯(lián)系的，從這個觀點來看，任何對事物的拆分都是不完全正確的。
但是軟件開發(fā)中，人的理解能力是有限的，而拆分目前看來是降低單個項目復雜度最有效的辦法。
拆分有很多級別，最小的可能是拆分代碼段，用多個函數(shù)代替單個函數(shù)，然后是用多個類代替單個類，在Java里面，還可以拆分package，然后拆分jar包，最后拆分成不同的項目。
之前有過很多的爭執(zhí)，關于一個項目要拆還是不拆，以及如何拆。關于這個，我的建議是：
-
拆與不拆沒有對錯
Windows是微內核架構，Linux是單內核架構。微內核意味著內核很小，你可以通過很多個模塊去補充它，內核與模塊是解耦的。Linux是單內核，就表示所有內核功能會在編譯時就確定?？赡艽蠹叶加X得微內核更好，很多時候它確實更好，但是Linus有個經(jīng)典的論斷：“你不需要管理各個模塊，但是你需要處理模塊之間的依賴，這個可能比模塊本身更復雜”。因為事物本身就是互相聯(lián)系的，你覺得他們不存在耦合，只是當前使用場景用不到而已。
-
系統(tǒng)內部實現(xiàn)對外部透明，保留拆或者不拆的選擇權。
項目自身的復雜度，完全可以靠內部實現(xiàn)解決，對外保持約定好的API，這樣對于以后內部的重構，會簡單得多。相反，如果暴露了內部實現(xiàn)，那么修改就很困難了。
-
對于項目拆分，如果沒有充足的理由支持拆分，就不要拆。
不成熟的拆分，最常見的結果是，隨著需求的變化，你不得不打破這種解耦關系，這樣反而會帶來更多的問題。建議是需求穩(wěn)定之后，再考慮拆分。
-
在系統(tǒng)內部多多進行代碼級別的拆分，管理復雜度。
相比項目的拆分，函數(shù)和類級別的拆分成本非常低，值得多用。
2. 配置化與靈活性
一段代碼，如果使用一遍，那么我們就直接通過代碼實現(xiàn)了。如果我們有幾十上百個類似的任務，那么我們就不希望寫重復的代碼了，我們希望能夠通過配置幾個不同的參數(shù)，從而實現(xiàn)不同的任務。如果以后還有不斷變化的需求，我們甚至不希望自己寫配置，而是有一個運營后臺來讓需求方(可能是不懂開發(fā)的人)直接完成配置。
配置化的開發(fā)方式往往對開發(fā)者來說有很大的誘惑，從而忽略其中的成本，這個配置最近還有個很火的名字，叫做DSL。但其實配置化和靈活性是矛盾的，配置的表述能力自然要弱于通用語言。當然，也有人嘗試使用配置解決所有問題，結果只不過是發(fā)明了一門很難用的語言而已。
我自己的框架WebMagic是一個經(jīng)典的配置與靈活性權衡的例子。WebMagic是一個垂直爬蟲框架，爬蟲最復雜的是規(guī)則的編寫，你可以認為這是一個可配置的東西。公司基于它做了一個配置后臺，即使是這樣，仍然有一些情況，不得不手寫Java代碼來實現(xiàn)一些功能。
對于這個問題，我的建議是：
-
先寫代碼解決問題，但是提前約定接口。
第一個階段，沒有誰能預測以后的需求，所以先用你熟悉的代碼實現(xiàn)?？梢愿鶕?jù)你的輸入和輸出，約定程序級別的接口，相比配置化，這一般來說會容易，如果接口設計得當，也會有具有很大靈活性，以后基本無需更改。
-
在有一定積累之后，基于以往的任務做配置化。
配置的內容是什么呢？首先公共邏輯肯定會在整體框架中，配置的內容應該是不同任務彼此獨特的部分。這個配置格式，或者DSL的語法的約定，首先應該基于已有的任務，然后可能考慮一下未來的情況。我是個實踐主義者，所以我更多的會參考已有的情況，如果發(fā)現(xiàn)這個配置化的框架，對之前的任務都不能滿足，那么就需要思考一下它的可行性和必要性了。
-
在任何時候都保留能使用代碼實現(xiàn)的能力。
我是個實用主義者。有了配置，如果不提供代碼實現(xiàn)的能力，而又有一些復雜的需求，那么就只能擴展配置的能力了。這樣只可能會導致這個配置解決框架變得極其龐大和復雜，而相對收益卻很低。這個時候，可以通過配置解決大部分問題，然后通過代碼解決少量問題，也是不錯的選擇。
3. 總結
其實還有很多東西沒說到，以后補充吧。以上的建議都是拋磚引玉，未必是最合適的方案，歡迎大家討論。
總結一句話：軟件設計要適應并滿足需求，同時不斷演化。
