對軟體開發的一點心得體會 (轉)

對軟體開發的一點心得體會 (轉)[@more@] 

對開發的一點心得體會:namespace prefix = o ns = "urn:schemas--com::office" />

Ryan Liu

liurui@radfort.com

 

一、前期規劃：

我理解的前期規劃是：在市場人員們彙總一個需求提交給產品專家帶領的產品經理團隊，然後經過這個團隊根據公司具體情況再次分析和規劃出一個最終需求文件。

  這個需求文件應當首先提交給技術研發部門的負責人以及核心開發人員。由開發團隊對其進行技術和風險分析。如果對此需求統一有異議的地方，需要返回給產品團隊，重新修正需求。反覆如此，直至需求完善準確，細緻，清晰。

前期規劃就像高樓的地基，如果馬馬虎虎，就算是一塊磚塊沒擺好都可能導致整個高樓建設的失敗。在規劃中我認為，交流永遠是需要雙方積極主動，能認真聽取每個人的建議。前期工作思維不慎重，不細緻，不認真，不夠完善，將產生連鎖效應直接導致整個工程和專案的失敗。

這種失敗可能表現為：第一種，軟體按需求實現但是功能根本不能滿足需要。第二種，功能都有了，軟體沒有達到可用性、易用性。

對於第一種，當然是因為前期規劃疏漏了某些細小功能，沒能把需求文件做完善。應該是規劃工作做的還不夠認真和細緻。

對於第二種情況，我認為更多是在產品設計規劃方面還不夠成熟。這種問題應該是很難避免的。因為每種新產品對產品團隊來說都很陌生。即使以前做過類似的東西，也難免面面俱到。這隻能透過不斷努力和認真的態度來彌補。

前期規劃的交流涉及了市場、產品和技術研發等多個團隊之間。需要的不僅是團隊內部的交流，更多需要協調好團隊之間的交流。可能有時候需要公司高層和中層參與協調。

目前，很多開發人員深感專案的需求文件寫的都很單薄。大家可以想一想，如果沒有好的開始，怎麼會有好的結束呢？需求文件單薄，不夠細緻，由誰來繼續完善呢？難道讓員們自己去完善。我想程式設計師也可能沒有這種能力。對於程式設計師能把程式碼寫的很健壯很穩定就已經是很不容易的事情了。

 

二、概要設計：

我理解的概要設計步驟：（以專案為中心的開發流程）

1〉  專案經理仔細閱讀專案需求文件。

2〉  專案經理召集專案開發成員，開專案啟動會議。具體商議專案的開發任務和責任分配。

3〉  核心開發人員開發確定，以及各模組開發人員確定。

4〉  由分析員和核心開發人員仔細閱讀需求文件，對系統整個架構分析和做技術規劃。

5〉  系統分析員整理和書寫最終的系統架構和概要設計文件。

6〉  系統分析員在文件提交日，提交給專案經理。專案經理確認文件並審批。

 

7〉  專案經理召集專案開發成員，開一個概要設計以及系統架構確定的會議。向每個成員分發文件，並討論確定最終概要設計文件。

8〉開始詳細設計文件的工作

三、詳細設計：

1〉  專案經理組織成立各個模組的開發小組，並確定開發小組組長（程式經理）。

2〉  各開發組長書寫各自模組的詳細設計文件，開發成員需要協助，配合。

3〉  在指定提交日，開發組長提交文件給系統分析員。由系統分析員審批。

4〉  系統分析員組織召開一個詳細設計文件確認的會議。

5〉  然後開發組長分發各自模組的詳細設計文件給程式設計師，程式設計師在指定時間內完成。

6〉  程式設計師做內部測試。開發組長協調並配合。

7〉  確認無提交給開發組組長。

8〉  所有模組整合工作，由整個開發組成員參與完成。由所有開發組長和系統分析員負責主要部分工作。程式設計師協助和配合。

9〉  對整合後工程做詳細測試。

10〉  確認測試透過後，開發組長根據開發成員表現以及提交成果填寫績效考核表。然後提交給專案經理。

11〉  專案經理會召開專案總結會，同時向優秀成員頒獎。同時鼓勵所有成員繼續努力。對不能按時完成導致專案能按時提交，以及對導致失敗的關鍵人員給與懲罰處理。

 

當然，以上只是一個簡單的開發流程，一定是有很多不足的地方。希望能起到拋磚引玉的作用。大家都明白，流程和制度是死的，但人是活的，所以如何按流程做得好，關鍵還是在人本身了。沒有一個流程和制度，一個團隊也必將是一盤散沙。正所謂“無規矩無以成方圓”。這句話說得很有道理。

 

四、具體編碼：

開發幾個專案之後，對編寫程式有了更進一步的瞭解。

好的程式應該具有: 易讀性，易擴充套件性，容錯性。

  易讀性:  所有變數和以及類名用簡單易懂易記憶的命名方式。所有類和函式甚至變數都有關鍵的註釋說明。這點很重要，也是最基礎的。如果程式碼書寫不夠美觀和易懂，我想自己以後也不想再看。就更別談功能的擴充套件和新版本開發了。

  易擴充套件性: 整體系統架構邏輯簡單清晰。模組與模組之間儘量做到互不影響，也就是儘可能的獨立。這部分工作主要體現在前期設計工作中，需要掌握好的設計經驗和方法才能夠做得比較好。

  容錯性:  對資料流和指標以及陣列都做資料有效性檢查；對第三方介面的失敗的容錯性。對所有程式碼都做呼叫失敗後的錯誤處理。以及在大的工程中加入trace輸出，把關鍵的資料流和關鍵處理部分的操作資訊輸出。以便對工程異常情況產生條件的定位，及時解決問題。

我覺得程式設計師能在這三方面做得很好就算一個優秀的programmer了。

 

五、、跟蹤與測試：

1 測試需要注意的：

對每個模組的介面做測試，資料邊界的檢查。在對整個模組做測試。

  主要測試穩定性，以及功能是否正常。

  確認單個模組完全正常後，再加入工程。

  在系統架構設計的時候，可能會引入原型參考。要對原型做完成測試後，確認沒有問題後，才可使用。

  2 可以採用VC自帶Trace或者將資訊輸出為文字檔案的方式跟蹤程式並輸出關鍵資訊，以便定位程式異常的原因。

  3 對於通訊模組的測試，特別注意服務端和客戶端的資料流。可以針對性的寫一個客戶端或服務端的測試程式，檢驗通訊過程是否正常。

  4 在用VC做開發中，一定先要讓Debug版本正常執行，保證沒有任何異常，洩漏和Assert等除錯警告資訊。如果用到其他Lib,一定要保證Lib本身不存在問題。

  這裡只是提到一些自己容易忽略的東西，希望能對大家有所幫助，歡迎指正！謝謝。