最近項目重構的一些感想

緣起

最近，由於多個因素綜合做用的狀況下，我有幸得以負責一個項目的重構事項，而且時間/空間上都是至關寬鬆。並且因爲系統較爲複雜，須要對接多個業務開發部門，致使各類大需求小需求特別多，所以若是我代碼設計得爛，那麼我就要面臨加班擦屁股的尷尬局面。這也致使了我不敢隨意寫爛代碼，儘可能避免各類『破窗效應』。所以想記錄一些比較雜碎的感想，基本上是想到哪寫到哪，不會注重文章的結構佈局。

面向對象仍然是主流的設計風格

這裏要理解什麼是面向對象，而不是去背教材中的『封裝，繼承，多態』。軟件開發原本就是講究實踐的東西，背教材是最沒用的。『封裝，繼承，多態』可能偏偏是最不重要的，重要的是這些：

1. 什麼是『控制反轉』，什麼是『依賴注入』，除了在Spring/Angular這樣的框架中見到以外，對咱們實際設計代碼有什麼實際的啓示。
2. 什麼是『SOLID』原則，有什麼實際啓示，哪些很容易作到，哪些看似容易實際上很難作到。

世界是有狀態的，致使咱們的代碼也是充滿了各類各樣的狀態

這實際上是第一點的緣由，大概也是面向對象風格流行的緣由？各類各樣的，骯髒的狀態，可讓其隱藏在一個又一個的class後面，從而限制其影響範圍。

什麼是『組合』，什麼是『組合優於繼承』

『組合優於繼承』，至今不知道是什麼意思，也沒有見到比較有說服力的答案。我感受這句話很像『高內聚低耦合』這樣很正確可是沒有什麼實際做用的廢話。好比『裝飾器模式』是組合一個很經典的例子，OK，講完『裝飾器模式』以後，我大概懂了這個模式，可是我仍是沒懂『組合優於繼承』這句話的具體意思。大概只能靠意會了吧？

『繼承』沒有那麼不堪，『多繼承』可能要避免

承接上一段。貌似總有人將『組合』與『繼承』對立起來，而後有選擇地舉幾個例子，說『繼承』哪哪很差，『組合』哪哪好，而後得出上面那句話的結論。這種文章通常犯了『倖存者誤差』的錯誤，通常也夾帶了不少私貨，沒有啥養分。

其實我倒以爲，沒有孰優孰劣，由於二者只不過是兩種不一樣的手段而已，好比吃飯能夠用刀叉，也能夠用筷子，解決問題仍是要看場景。繼承沒有大V們吹的那麼噁心，畢竟也是根據實際問題而發明的手段，總不能一點用處也沒有吧？簡單用用其實挺好的，也能重用不少代碼。

可是Java有種特別很差的風氣，就是搞巨多class，而後設計很複雜的繼承（接口）關係，層層封裝，真實意圖每每隱藏在層層代碼以後。更有甚者，幾乎每個class都搞一個interface，美名其曰爲拓展設計，實際上是『過分工程』。這種風氣下來，讓人寫Java缺乏快樂的感受，我猜大V批判Java主要是指的這個吧。

反正我寫Java是挺快樂的，想到哪寫到哪，也不刻意搞不少interface，大不了到後期再提取interface就好了，反正如今的IDE工具都是這樣強大。

『設計模式』頗有用

這個東西真是強求不得，若是是強行搞『設計模式』，基本死得很慘，還不如不搞。在項目重構的過程當中，我主要使用了『工廠方法、模板方法』這幾個模式，搞出來的代碼確實讓人感到賞心悅目。特別是『模板方法』模式，咱們的業務過程當中有太多場景適合這個模式了，我幾乎所有都使用了它，改起Bug來嗖嗖的。

OOP與FP

OOP懂一點，FP基本不懂，不懂得領域，就不隨意評論了。對於FP，我發現一點，就是總有人拿它和OOP進行類比，列舉出個OOP的幾個缺點和FP的幾個優勢，而後將OOP批判一番，而後得出『FP更優』的結論。講真，計算機世界的不少概念和事物，是不適合用類比來理解的，就像人的食指和中指，在實際生活中，各自完成不一樣的功能，各司其職，從而使咱們能完成各類各樣的動做。若是你硬是將其對立起來，有其一就不能有其二，這不扯淡嗎？OOP和FP同理，原本就是兩種不一樣場景下的手段，若是硬是將它們對立起來，得出個孰優孰劣的結論，反而沒有什麼意義。各司其職，融合着使用，纔是解決之道。

分層思路

任何軟件都是分層的，分層能夠顯著下降人腦思考的難度，從而設計更加大型的軟件。在這種語境下面，『模塊化』『分層』等概念，基本上是某種概念的不一樣側重點，基本上是同一個意思。

可是分層也不能太細太碎太多，這樣基本走向了反面，帶來了累贅。『中庸之道』纔是硬道理，得靠大量積累的實際經驗。

《重構》、《Clean Code》

兩本好書，很影響人。看了好幾遍了，每次看都有新的收穫，看得次數越多，逐漸地會吸取做者『只可意會不可言傳』的某些內容，：）。