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