?? 前一段時間看了一本《走出軟件作坊》，心情很沉重。不管你是否承認，書中描述的情況在現在的國內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）單元測試

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

（6）自己編寫測試工具

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

a）可以利用malloc重定向的方法，統計malloc的內存個數，看看內存有沒有泄漏

b）利用開源工具gcov測試代碼覆蓋率

c）自己編寫腳本解析模塊，靈活地對代碼功能進行測試

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

（7）仿真工具

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

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