關於最近重構代碼的一些思考

最近一直在參與重構項目中的代碼。

以前寫的代碼最大的問題在於「想到哪裏寫到哪裏」，沒有從功能上先總體地進行分析，而後將相似的業務分類到一些，有條理地書寫代碼。應該來講原本是能夠這麼去作的， 由於咱們花了很多時間去作詳細設計。寫代碼的同事已經對業務的邏輯有了相對完整的理解。但因爲很多同事在寫代碼方面經驗還比較少，所以很難作到這一點。因此就想到哪裏寫到哪裏，也比較少審視先後寫的代碼一塊兒來看是否是結構合理的，原本能夠共通進行處理的部分也沒有合併到一塊。代碼中出現大量的重複。這是最明顯的一個問題，也是最初級的一種問題。

第二種問題來自於對狀態遷移表的理解的僵化。咱們幾乎全部的模塊（除了共通的API層）都是使用狀態遷移表的方式來進行設計的。這有不少的好處（找機會另寫一篇文章聊），可是並非說除了狀態遷移表以外其它的設計手法（模式）就不能用了，或者說不知道如何把其它手法融合到狀態遷移表中去。所以業務邏輯稍微複雜一些的時候狀態遷移表就變得巨大無比，並且特別容易出現其中某些格子處理特別複雜，不少格子中的處理又過於簡單甚至不須要處理。使得設計文檔變得比較難以理解。

第三個問題是不懂得細分。特別是使用C++的模塊，原本能夠用類/類體系很好地將各類類似的邏輯放在一塊兒去處理。用C++來走C的路。

具體的例子由於涉及到公司的IP，不能貼出來。之後找機會總結一下，換些Dummy的代碼來講明。

再說一個關於語言的問題：

對於一個項目來講，業務的邏輯複雜度是本質性的，需求不變的狀況下，複雜度是必定的。咱們要作的就是讓代碼實現能儘可能地接近業務複雜度，我重構的目標基本上也是這樣：把因爲拙劣實現而產生的多餘的複雜度去除。因爲某些限制，咱們的項目中有些模塊必須使用C來寫，有些模塊能夠用C++寫。可能因爲本身寫程序長期使用C++的緣由。在重構C和C++代碼的時候，感受明顯不同。C++在語言上給出了更多功能，所以，咱們有更多的手段去讓代碼更貼合業務，就容易寫出更好維護，更容易懂的代碼來。好比OO（以及所以發展出來的相應的模式），泛型（將語言數據類型這種在業務描述中並不太關心的東西的影響去除掉）。用C++寫明顯要「輕鬆」不少，能夠給出的辦法也比較多，代碼量也要小很多。而C++11/14的進步，使用C++在寫業務層的東西的時候變得更加簡單的高效（不管是語言層或者標準庫）。C++很是適合在嵌入式的領域。C除了在特別靠近硬近的代碼的時候沒有明顯地劣勢以外，寫業務邏輯時明顯要感受到要爲語言的簡陋走些彎路，作些妥協。我以爲這個觀點的一個更好的例子就是用函數式編程語言寫快速排序。代碼極其簡潔，貼近算法自己，而用OO和過程式的語言就要帶入那些與「算法」自己無關的東西進來，這些都會加大編程和維護的負擔。固然，對於C++我也有不少不爽的地方，好比模塊的語法我以爲很醜，Lambda表達式也是各類語言中比較笨重的一種，編譯器還應該能爲程序員作更多的事，就像Scala那樣。

在我看來，只要有可能，就應該選用更多「選擇」的語言（在個人選擇中，嵌入式開發中能用C++就用C++，能用C++11/14就用C++11/14）。目標就是如何能實現得更簡單更快更好維護。

PS: 這幾天的新聞，ARM的新編譯工具鏈是基於LLVM進行構建的。LLVM在C++語言以及各類C++代碼處理/分析工具上的支持都很棒。我相信在嵌式開發中，C++11/C++14會很快地獲得很是好的支持。只要工程團隊技能跟上，那麼是能夠提升開發效率的。