1、架構和算法的可行性測試分析:主要包括性能、并發等方面
2、CodeReview:很簡單,但很多人沒有這樣做;其實這比“黑盒測試”更輕易發現邊界問題、流程正確性問題等。值得推廣!
3、測試驅動和單元測試,很多人為了達到那些并不太懂編程治理層的要求,往往是少了這些看似不輕易出成績的步驟。(很大程度上改變設計思維)
知道可能出錯的地方,當然輕易避免出錯。
4、UML和用例:非凡是UI建模,個人覺得最不可少;UML和用例至少要能覆蓋核心內容。
具體如何做,要根據每個人、每個單位甚至每個項目做具體優化,這里提供思路。
5、專心架構(各功能模塊的關系%26lt;用例等%26gt;、分布式計算的節點關系%26lt;即分層%26gt;、類的層次結構%26lt;UML圖%26gt;、升級的備案、數據庫架構、數據庫表的范式%26lt;ER圖%26gt;、并發訪問和多線程等):不好的架構,Code起來吃力、問題又多又不好解決!以個人的經驗認為,一般可分為六個階段:
A 用戶需求收集、訪談和確認--%26gt;
B 架構和可行性分析并文檔化--%26gt;
C 開發測試部署和維護具體計劃--%26gt;
D1 單元編碼、測試%26lt;--%26gt;
D2 部署測試--%26gt;
E1 開發環境集成和測試--%26gt;
E2 真實環境模擬測試--%26gt;
E3 部署預演--%26gt;(原系統備份)--%26gt;
F 部署
1) 各階段主要的“產出”(不考慮投入)
A:需求說明書、UI建模、用例和UML圖和系統使用幫助文件初稿、系統可能存在的風險報告
B:系統架構圖(邏輯圖和物理圖)、核心算法代碼和測試報告、第二方和第三方組件的風險分析報告
C:系統各模塊的具體說明書,數據庫架構和測試,各功能的開發、CodeRivew和測試計劃、部署計劃(相當于每日構建)、集成測試計劃、系統的升級考慮和方案。注重,盡可能在Code前將數據庫可能的問題解決掉!
D:代碼、BUG治理、可執行文件、開發環境、測試環境
E:可發布的安裝包、最終用戶文檔、修改之前相關的文檔到和現在的系統一致
F:可能的問題預案、安裝和不斷依實際情況優化,進入維護階段
2)時間分配:A:B:C:D:E:F=10:10:20:50:5:5,A階段的時間這里指項目啟動時算起,啟動前的時間不計在內。
真正的Code時間一般可能占50%
原文轉自:http://www.anti-gravitydesign.com