前一段時間看了一本《走出軟體作坊》，心情很沉重。不管你是否承認，書中描述的情況在現在的國內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）抽象流程
（5）單元測試
單元測試是一種非常好的方法。本質上說，**設計者應該是**的最終負責人。可是在實際工作中，我們把軟體的質量問題過多地放在了測試人員身上。好多人認為軟體測試是乙個非常無趣且單調的工作。其實，情況並非如此。對於功能性測試，我們應該盡可能採取自動化測試的方法，實現版本的每日構造和每日冒煙測試。而對於模組的測試，那就要進行**的單元測試。就我個人的經驗而言，如何設計stub函式，如何設計單元測試是非常考驗人的一件事情。隨著單元測試用例的增加，我們的**會越來越健壯，整個模組也會越來越穩定。可是在很多公司，單元測試做的很不足，或者說很多公司乾脆徹底就不做了。
（6）自己編寫測試工具
平時測試軟體的時候，我們的方法其實不多。有的人習慣使用windows的效能分析工具，或者如果公司比較富裕一點，會自己購買pure coverage等工具。但是，其實很多時候我們是可以自己編寫測試工具的。這些工具的編寫不複雜，比如說
a）可以利用malloc重定向的方法，統計malloc的記憶體個數，看看記憶體有沒有洩漏
b）利用開源工具gcov測試**覆蓋率
c）自己編寫指令碼解析模組，靈活地對**功能進行測試
d）利用assert屬性，捕捉一切異常的屬性等等
（7）**工具
上面很多的內容都是我個人的一些總結和意見，歡迎朋友們多多交流看法。
軟體隨想錄
最近閱讀了由阮一峰翻譯的，有程式設計師部落酋長之稱的 joel 撰寫的 軟體隨想錄 精華摘抄如下 就如同所有行業最好的人才一樣，那些優秀的程式設計師是不會出現在招聘市場的。通常優秀的程式設計師在整個職業生涯中，可能會有4次求職。實習生制度創造了輸送優秀人才的管道，但是這個管道比較長，而且一路上損耗很...
軟體隨想錄
在圖書館閒逛，翻到這邊書，書如其名，像本雜記。書翻譯得極好，每個不明晰的名詞作者都給做了標記，使得外行的人，也能看的明白。1.畢業前練好寫作，但凡出眾的程式設計師，大多能夠清晰地表達自己的思想。2.畢業前學好一門偏底層語言，如c c 3.畢業前看一看微觀經濟學，至少認識市場對軟體的需求。4.不要因為...
隨想錄（軟體除錯）
對於很多程式設計師朋友來說，編寫 要比除錯 快樂的多。似乎創造軟體比維護軟體更能給人帶來成就感。然而，在企業裡面維護前人留下的 也是工作中不可缺少的一項內容。所以，如何除錯軟體，更快更好地尋找軟體中的bug，就成了我們必須學習的一門功課。當然，有人查詢故障很快，而有的人卻要慢一點，這中間的原因很多，...