個人經驗談一談軟體構建

標籤：style   sp   on   資料   問題   代碼   時間   工作   size   

項目開發過程的活動：定義問題、需求分析、規劃構建、軟體架構、詳細設計、編碼與調試、單元測試、整合測試、整合、系統測試和保障維護。

當初在書上看到這些的時候，確實一頭霧水，但是最近自己主管項目開發的時候確實深有體會啊。

需求真的很重要，在開始動工前就一定要確定好，不然後面經常修改的話，既做了很多無用功浪費時間，又加大了開發成本延誤工期。所以，開發項目的首要工作就是出一份全面合格的需求文檔。

規劃構建該怎麼實施呢？當然，做項目不能說走一步算一步，必須事先算好工作量，合理分配時間和工作。例如，這個項目有哪些功能或模組組成，每一部分大致需要多少時間來完成，哪些是可以同時進行的，哪些是需要優先完成的等等，以及項目架構該怎麼設計，資料庫該怎麼設計，成員任務該怎麼合理分配。另一點，多次開發經驗告訴我，不要太完美化，剛開始的時候不要把什麼都考慮進來，而是應該先完成一個簡易功能的測試版，先要能用，然後往上面加功能，不然反而會適得其反。

軟體架構也很重要，不然維護會很困難。至於詳細設計與編碼調試，那就要分工明確，把控好時間，以及做好交流工作。

單元測試雖然會加大開發成本(學習成本比較高，設計的技術多，單元測試的代碼工作量等)，但是它不但可以在我們編寫代碼的時候提升代碼品質、減少bug，還能促使開發人員思考工作代碼實現內容和邏輯的過程，提升反饋速度，減少重複工作，提高開發效率，讓代碼更易維護。

至於後續步驟這裡就不多說了，這裡還是要側重於“構建”。很多程式員在自主開發項目的過程中都不會按照上面的步驟來做，在他們眼裡，這些活動很可能都被歸為“編程”了。那麼軟體構建真的很重要嗎？

回答是必然的。軟體開發並不是做出來就可以了，提高軟體的品質和開發人員的生產率都是十分重要的。我有一個朋友，他的能力是挺強的，但是他不適合開發。他是屬於那種完成型而非思考型的程式員，他完成一個項目或者一些模組的工作是挺快的，但是，品質不行，真正用起來的時候會發現很多弊端，例如最致命的問題————崩潰、記憶體泄露，這無疑是一款軟體的致命傷。

一款理想的軟體項目在進行構建之前，都要經過謹慎的需求分析和架構設計。

一個理想的軟體項目在完成構建之後，也要經過全面的、專業的系統測試。

現實中很多不那麼完美的軟體項目，往往跳過需求和設計，後期又由於沒有太多時間修正錯誤，測試環節也被拋到了一邊。但是，構建不能沒有！不是嗎？

個人經驗談一談軟體構建