項目經驗教訓

我今天在HCA下調試了一下為什麼加載h323ras.hca消息會crash的問題。找到了原因，發現是Joe修改後的代碼邏輯上的錯誤造成的。去年我們安排了三個人花了幾個月的時間在搞H323和III ASN.1 Tool，我們對于這個東西應該已經是比較清楚了。是以在在移植Joe的代碼時，我們就應該能發現這個問題。實際上在HCA裡面會産生crash的兩個extract()函數體被注釋掉了，當時并沒有發現這個問題。應該即時發現這個問題，去解決它或者記錄它，而不是隐藏它。即時發現了不自己去解決，也可以跟Joe協商去讓他解決。這是一個處理問題的态度問題，我們在遇到問題或者看到代碼寫的不好時，往往想偷懶而不願意去面對它。實際上這些問題積累下來以後會給将來造成更多的麻煩。

我的另外一個感覺是我們在面對困難的問題是缺乏信心和毅力，III ASN.1 Tool總共加起來都沒有兩萬行代碼，除去ASNParser當時我們不需要關心外，其它代碼不到5000行，背我們也要把它背下來。黃祥華是一個身邊值得學習的榜樣，他在做Codec的開發時遇到的問題絕對比我們所有其它項目的困難要大，但是他通過正确的方法和堅韌的毅力最終解決了問題。他接手comscore的sniffer開發時同樣有許多困難，就是他處理問題的方式使他能夠成功的接手這個産品。

H323 Decoder已經是很久以前的事情了，我不是為了以前的事情來責備誰。我隻是想從這個事情裡面總結一些經驗。

1．我們做一個功能的時候要徹底把它搞清楚，也就是前期的分析和設計。可靠的功能需要我們在編碼之前把問題分析清楚并做出良好的設計，而不能完全靠QA的測試，QA隻能幫我們發現問題，但是不能替我們解決問題。我們可能會做的慢一點，但是完成一個穩定可靠的功能比完成兩個不太确定不易維護的功能更重要。

2．有些項目不太容易在一開始就做出設計，這對我們很常見。例如黃祥華加codec，和你們做H323 Decoder。這樣的項目需要我們做預研做嘗試。但是預研後一定要回顧，并基于嘗試進行設計。如果僅僅是嘗試之後發現功能實作了就進入測試階段是危險的。這表示我們将依賴測試來保證品質，而不能確定自己有可靠的設計。（對于這一點我自己需要檢讨，因為我當時還能體會到這一點并對我們的開發過程做出幹預）。這樣做的另外一個問題是增加此功能以後的不确定性和維護困難度，原因應該很容易了解。

3．我們要有信心。通過合理的分析，大部分的問題都會有合理的解決方案。我們組一路走來遇到許多問題，也會遇到新的困難，分析問題和解決問題的能力是我們重要的立足之本。即使有一天我們不做開發了，培養出來的這種素質對我們依然重要。

4．項目裡面遇到問題的都要用一個清單記錄下來，按照優先級來安排時間解決，而不是最後全部都忘掉。

5．追求完美，拒絕偷懶。在遇到問題或者開到代碼不合理時，我們需要在解決成本和收效之間取個折衷。值得修改的就及時修改，避免将問題遺留，進而給以後帶來更多的問題。偷懶有的時候會需要将來更多的時間浪費作為代價。