回顧最近項目中存在的問題

國慶期間，我以批判性的態度來審視，最近的一個月以來我主導的兩個項目當中存在的問題。

項目1:

      這個是純粹網絡系統，由多個端組成的，沒有界面。

得:

   a. 協議文本化

       從項目一開始，就說服你們採用文本化的協議，這樣便於閱讀和理解通訊過程。

       透明性和可顯性大大加強，同事們開始體會到這樣作的優點了。

       這樣作增大了編解碼的難度，不過是划算的。

   b. 日誌

       對於多端的程序共同協做來完成某個任務，日誌是很是重要的。項目的初期由於沒有日誌，致使

       不少本來不該該發生的Bug或者能夠避免的Bug。如今你們慢慢養成看Log的習慣。

失：

   a. 網絡庫的選擇

       在項目中採用libuv庫，如今看來多是一個不大不小錯誤。所以致使如今的代碼感受有點不三不四。

       爲何不直接用Boost當中的ASIO呢！

       這樣跨平臺能力沒有受到影響，同時直接採用Boost以後，基本上再也不須要引入其它第三方的庫了，

       如今的Boost庫已經很是豐富了，豐富的都不行了。

   b. 測試工具

       各類測試工具的開發和使用沒有跟上項目的進度，開發人員老是說還有一點小問題，彷佛沒有盡頭。 

---

項目2:

       項目2的開發時間已經不短了，可是隨之而來的多方面的問題卻愈來愈嚴重。

       國內大多數程序員的有一個毛病，即設計能力大大超越了他們實現和排錯的能力，一旦出現問題頗有可能依靠他們的能力沒法解決，如今的這個項目遇到了這個問題。

       所以在9月28日，內部開會決定重構。

       如何重構呢？我提出了幾條原則和想法。

       1. 利用Erlang思想，移植到C++的項目當中

           學習過Erlang以後，我真的很是佩服設計Erlang的那幫人，在上個世紀八十年代就開始考慮如何進行多核併發的問題，他們真的超越了那個時代。

           我從Erlang的思想庫中引入兩條：

           I.   多進程
           II.  文本化的消息

           多進程和文本化的消息其實都不是Erlang首創，但Erlang是把它發揮到極致的。

           我反對將程序寫成一個龐然大物，我更喜歡直接拆分紅不少能夠獨立調用的小程序，這樣一來，不少小程序能夠進行獨立的替換和測試，而不影響全局。

           多進程的作法，骨子裏其實仍是Linux/Unix思想，即」Do one thing, Do it well」。

 

       2. 消息模型

          從新認識消息模型，原先的代碼中，處處都是充斥着指針，各類由於指針引的崩潰。這裏我還要說Erlang的思想。

          其實Erlang的思想很好理解，說白了就是把人類的併發模型移植到計算機當中，人類社會是如何併發的，Erlang裏面就怎麼併發。

          好比，一個團隊在作一件事情，這就是一個小規模的併發模型，每個人如同一個獨立的模塊，這些模塊之間的協同工做是依靠說話的方式，計算機術語叫消息。

          每一個人都有獨立的運算單元及獨立的內存，人與人之間的協同，是不可能把一我的頭腦中的一片內存指針分享給其餘人的。協同全面依靠消息，這就是Erlang的併發模型。

          因此，咱們在重構時，要把握這點，模塊之間儘可能採用消息的模型，而不是用指針。

          模塊是一個相對的概念，能夠是一個類也能夠是一個lib還能夠是一個dll或者是其它什麼，只要是邏輯上相對獨立的東西，就能夠稱爲模塊。

          更進一步，能夠把Qt當中的信號和槽理解成另類的收發消息的機制，這樣一來類與類之間的溝通就變成消息的通知。

          所以，模塊之間的耦合性降到最低了。

       對於這個項目，2013年國慶將是明顯的分界線。