軟件的精髓在于設計

軟件的精髓在于設計，設計是一件費腦子的事情，因為軟件設計背后是權衡的動作，比如時間換空間、空間換時間、TCP還是UDP、同步還是異步、數據冗余與一致性、微服務邊界如何劃分、架構中的功能性邏輯與非功能性邏輯等。

但往往很多程序員花在設計與權衡上的時間太少了，花了大量時間在寫代碼、重構、問題排查。

如果缺少足夠的設計思考，一上來就去寫代碼，勢必造成很多瑕疵、隱患與質量問題存在，而這部分在未來會變成新的成本、耗費精力，殺死你的時間。

同樣一個架構在早期沒有考慮好其功能性與非功能性的設計擴展的話，未來的某一天架構去解決高性能問題、高可用問題時，因為缺少足夠的擴展性，難以快速解決這個問題，甚至出現推倒重建的情況，這部分依然是個逃不過的成本。

重構是件好事，但頻繁的重構是噩夢，頻繁重構代表了這個系統(tǒng)的設計者缺少足夠的思考，沒有留有擴展性，沒有考慮到業(yè)務可能的發(fā)展方向，缺少規(guī)劃。不斷重構表面上消耗了人力與時間，背后會讓團隊情緒低落，產生厭倦情緒。

如果你花了時間在架構的設計上，比如和業(yè)務聊了下發(fā)展趨勢與變化，做好了技術難點細節(jié)的隔離，推敲了一段設計的合理性、風險、復雜度，看到了設計上的缺陷，那你其實不需要頻繁的重構，因為這些成本在日常的每一次迭代中被低成本的消化了。后續(xù)你的系統(tǒng)將會越來越輕松，越來越穩(wěn)定。

多些時間做設計，不是讓你寫了更多代碼，做了更多迭代，而是考慮到其背后的成本，減少了不必要的冗余，更快更好的交付一個更好的產品。

代碼的好壞有這幾種級別：

1）可編譯

2）可運行

3）可測試

4）可讀

5）可維護

6）可重用

通過自動化測試的代碼只能達到第3）級，而通過設計的代碼少會在第4）級甚至更高。

導致大家認為沒思考時間的原因有幾個：

1. 項目DDL的壓力：這種情況很多人覺得要在速度和質量上做個權衡。但偶爾的時間壓力讓我們非常痛苦是正常的，都會有幾次通宵突擊的情況，但如果這是常態(tài)就不正常了，需要和業(yè)務方與老板聊聊，背后的原因是什么；

2. 過度的設計：我們談了要多一些設計思考，但往往變成了研發(fā)同學的過度設計，一些無關或成本不可控的場景被復雜且過度的設計，出現在一個本不應該投入的地方，導致舍本逐末、買櫝還珠。好的設計不是紙上談兵，需要結合實踐；

3. 團隊成員水平決定：這其實是很常見的一種情況，很多同學缺少建模與面向對象的設計，在職業(yè)發(fā)展初期過多關注于高并發(fā)的術，反而缺少了業(yè)務及基礎技術層面的積累，導致很多過程代碼的出現。團隊是需要培訓的，結合團隊平均能力做合適的設計，比較再好的設計也需要一群人的執(zhí)行，每一個人都有可能變成木桶的短板，而這個短板決定了整個設計的下限；

怎么提高設計能力呢？

我覺得最重要的方式就是多看，看看好的系統(tǒng)怎么設計、好的源碼怎么設計、好的書籍中的例子。

比如《大話設計模式》，里面的例子看似很簡單，但有時候簡單就對了，反而沒必要搞那么復雜。

簡單的面向對象做好如下幾條：

1. 單一、簡潔、模塊化、封裝；

2. 數據與其行為打包封裝；

3. 程序的接口和實現的解耦；

4. 組合優(yōu)于繼承；

5. 依賴接口而不是依賴實現；

6. 高內聚低耦合；

高級一點的就是SOLID原則。

當然更推薦《UNIX編程藝術》。

有時我們會發(fā)現，系統(tǒng)中存在一種膠水層，最開始python、ruby也被叫做膠水語言，這一層用于粘合業(yè)務邏輯和基礎能力，Unix設計哲學認為，膠水層應該盡可能的薄，太厚了你將苦苦掙扎。

比如我們對外部RPC、二方jar都需要加一層防腐處理，也就是膠水層的意思，網關API對不同終端的不同數據結構要求做不同的處理，也是膠水層發(fā)揮作用，千萬不要把這一層隨時可以撕掉的膠水放到邏輯層。