隨想錄（軟體開發不能是加工作坊）

【 聲明：著作權，歡迎轉載，請勿用於商業用途。  聯絡信箱：feixiaoxing @163.com】

     前一段時間看了一本《走出軟體作坊》，心情很沉重。不管你是否承認，書中描述的情況在現在的國內IT企業中確實存在，可能涉及的範圍還很廣。聯想到自己目前處於的行業，心中不免唏噓不已。類似的事件，類似的方法，每天都在上演著。無休止的版本修改，無休止的測試，無休止的開發需求，人員的流失和更替，心中除了累還是累。現在的IT早已經不是10年前的香餑餑行業，大家都在經受著挑戰和煎熬。現在的IT行業分布很廣，IT資訊化公司、網站公司、通訊公司、嵌入式產品公司、晶片公司、網遊公司、ERP公司，這些公司由於所處行業的上下遊位置不同，公司的境遇差別很大。特別辛苦的是那些本身技術門檻比較低，缺少技術壁壘的公司，員工在承受著低福利的同時還要承受著與之不匹配的工作強度。這就是我們的生活現狀。我們的IT開發非要這樣不可嗎？

    一般認為，IT項目開發的過程都是按照需求分析、軟體設計與實現、整合測試與系統測試、後期維護這幾個步驟進行的。我們應該好好反思一下，這幾個步驟有沒有提高和改進的空間。

（1）加強需求分析

    從商業的角度來說，交易的出發點就是為了滿足客戶的需求。只有精準地滿足了客戶的需求，我們才能更好地交付產品，實現雙贏。當然，完成這一切的前提就是需要我們能夠準確把握客戶的需求。對很多公司來說，需求分析都是由銷售來說，這是十分不靠譜的一個舉動。因為，我們知道，銷售人員的目標就是完成更多的簽單，所以很多時候他會毫無原則地接受客戶的一切要求。至於這些要求客戶是不是真實需要，或者說這些需求本身技術能不能實現，那就超過了他本身的理解範圍了。很多銷售的理解範圍其實就是入職時培訓的那一些內容，至於技術細節或者產品效能方面的東西，那真是無能為力了。作為優秀的需求分析師，他不僅僅可以準確把握客戶的需求，甚至在某種程度上可以影響客戶的需求。這種例子雖然不多，但是也不鮮見。無原則的接單，不僅浪費了開發的資源，從大了說，也會影響公司的誠信水平，甚至危害公司的發展。

（2）抽象公用平台

    現在的伺服器系統平台很多，windows可以，linux可以，unix也可以。因此，很多情況你不知道自己的服務端程式最終跑在哪一個作業系統上。所以，你要做的就是做一個抽象的公用平台。在這個平台上面，你可以忽視具體的細節，因為你使用的函數都是平台的函數，你使用的資料類型都是平台的資料類型，所以不管什麼作業系統，你的伺服器程式都可以準確無誤地運行。為了做到這些，你可能在構造平台的時候需要對很多函數重新進行封裝，比如，

a）記憶體申請、釋放

b）socket建立、接受、發送、釋放

c）訊號量操作

d）檔案建立、開啟、讀、寫、關操作

e）定時器

f）訊息發送和接受

g）延時函數

h）線程建立、優先順序設定、屬性設定、屬性擷取等等

（3）構建自己的軟體庫

    軟體作為一個工程來說，事實上它也是由很多的子模組組成的。這裡面的模組很多，比如說基本演算法模組、資料庫訪問模組、圖形模組、解析模組、日誌模組、解壓縮模組、pic讀模數塊。對於很多項目來講，很多模組的功能都是可以複用的，那麼如何把這些模組抽取出來就是我們需要完成的一個工作了。最最理想的情況就是，我們所有的軟體都是由各個模組按照搭積木的方式組成的，如果我們需要對應的功能，那麼開啟對應的編譯宏就可以了；反之，如果不需要這個功能了，那麼關閉對應的宏即可。這方面，我們可以看一下linux代碼。它上面的很多代碼都是以模組存在的，那麼多cpu、那麼多fs、那麼多chip都可以在上面運行，這說明linux整個系統的設計是非常開放和健壯的。

（4）抽象流程

    作為一個軟體的主流程，這好像應該是軟體主程式員應該負責的事情。其實，作為某一個模組的程式員，我們也可以從中學習到一些東西。就拿我經常說的一個例子來說，假設現在我們需要設計一個音頻播放器，它需要支援mp3、wav、ogg等多種音頻格式檔案。看到這裡，大家可以先考慮一下，這個軟體應該設計？在這個地方，我們應該思考一下，所有的檔案操作有什麼共性的地方，能不能在各種音頻檔案之上構造出一個通用的檔案訪問流程。有了這個抽象的訪問流程之後，那我們對各種音訊處理就是一個簡單的註冊和解析工作了。即使我們寫的程式不正確，也不會影響原來主流程的運行過程。有了這一層抽象之後，可以極大提高我們工作的開發效率。

（5）單元測試

    單元測試是一種非常好的方法。本質上說，代碼設計者應該是代碼的最終負責人。可是在實際工作中，我們把軟體的品質問題過多地放在了測試人員身上。好多人認為軟體測試是一個非常無趣且單調的工作。其實，情況並非如此。對於功能性測試，我們應該儘可能採取自動化測試的方法，實現版本的每日構造和每日煙霧測試 (Smoke Test)。而對於模組的測試，那就要進行代碼的單元測試。就我個人的經驗而言，如何設計stub函數，如何設計單元測試是非常考驗人的一件事情。隨著單元測試用例的增加，我們的代碼會越來越健壯，整個模組也會越來越穩定。可是在很多公司，單元測試做的很不足，或者說很多公司乾脆徹底就不做了。

（6）自己編寫測試載入器

    平時測試軟體的時候，我們的方法其實不多。有的人習慣使用windows的效能分析工具，或者如果公司比較富裕一點，會自己購買pure coverage等工具。但是，其實很多時候我們是可以自己編寫測試載入器的。這些工具的編寫不複雜，比如說

a）可以利用malloc重新導向的方法，統計malloc的記憶體個數，看看記憶體有沒有泄漏

b）利用開源工具gcov測試程式碼涵蓋範圍

c）自己編寫指令碼解析模組，靈活地對代碼功能進行測試

d）利用assert屬性，捕捉一切異常的屬性等等

（7）模擬工具

    在嵌入式開發中，實際環境常常是非常有限的。所以，建立一個有效模擬平台是什麼重要的。就拿android來說，我們就是在windows上面開發一個android的模擬環境，那麼app的開發人員就不需要每次開發一個版本之後，到實際phone上下載之後才能看到實際的運行結果。有了pc的模擬之後，他在pc上看到的結果基本上就是在phone上看到的效果。這中間沒有別人的打擾、沒有實際環境的搭建，工作的效率自然而然就可以提高上去了。當然不僅GUI可以模擬，原則上只要不和具體硬體相關的操作都可以而且應該放在pc上來解決。

    上面很多的內容都是我個人的一些總結和意見，歡迎朋友們多多交流看法。