最后補充一點東西，一個軟件項目研發的設計流程是怎樣的呢？以通常標準的設計方法為
例，（不過筆者喜歡快速原型法）。
?
第一個步驟是市場調研，技術和市場要結合才能體現最大價值。
?
第二個步驟是需求分析，這個階段需要出三樣東西，用戶視圖，數據詞典和用戶操作手
冊。
?
用戶視圖是該軟件用戶（包括終端用戶和管理用戶）所能看到的頁面樣式，這里面包含了
很多操作方面的流程和條件。
?
數據詞典是指明數據邏輯關系并加以整理的東東，完成了數據詞典，數據庫的設計就完成
了一半多。
?
用戶操作手冊是指明了操作流程的說明書。
?
請注意，用戶操作流程和用戶視圖是由需求決定的，因此應該在軟件設計之前完成，完成
這些，就為程序研發提供了約束和準繩，很遺憾太多公司都不是這樣做的，因果顛倒，順
序不分，開發工作和實際需求往往因此產生隔閡脫節的現象。
?
需求分析，除了以上工作，筆者以為作為項目設計者應當完整的做出項目的性能需求說明
書，因為往往性能需求只有懂技術的人才可能理解，這就需要技術專家和需求方（客戶或
公司市場部門）能夠有真正的溝通和了解。
?
第三個步驟是概要設計，將系統功能模塊初步劃分，并給出合理的研發流程和資源要求。
作為快速原型設計方法，完成概要設計就可以進入編碼階段了，通常采用這種方法是因為
涉及的研發任務屬于新領域，技術主管人員一上來無法給出明確的詳細設計說明書，但是
并不是說詳細設計說明書不重要，事實上快速原型法在完成原型代碼后，根據評測結果和
經驗教訓的總結，還要重新進行詳細設計的步驟。
?
第四個步驟是詳細設計，這是考驗技術專家設計思維的重要關卡，詳細設計說明書應當把
具體的模塊以最＇干凈＇的方式
(
黑箱結構）提供給編碼者，使得系統整體模塊化達到最
大；一份好的詳細設計說明書，可以使編碼的復雜性減低到最低，實際上，嚴格的講詳細
設計說明書應當把每個函數的每個參數的定義都精精細細的提供出來，從需求分析到概要
設計到完成詳細設計說明書，一個軟件項目就應當說完成了一半了。換言之，一個大型軟
件系統在完成了一半的時候，其實還沒有開始一行代碼工作。
?
那些把作軟件的程序員簡單理解為寫代碼的，就從根子上犯了錯誤了。
?
第五個步驟是編碼，在規范化的研發流程中，編碼工作在整個項目流程里最多不會超過
1/ 2
，通常在
1/3
的時間，所謂磨刀不誤砍柴功，設計過程完成的好，編碼效率就會極大提
高，編碼時不同模塊之間的進度協調和協作是最需要小心的，也許一個小模塊的問題就可
能影響了整體進度，讓很多程序員因此被迫停下工作等待，這種問題在很多研發過程中都
出現過。編碼時的相互溝通和應急的解決手段都是相當重要的，對于程序員而言，
bug
永
遠存在，你必須永遠面對這個問題，大名鼎鼎的微軟，可曾有連續三個月不發補丁的時候
嗎？從來沒有！
?
第六個步驟是測試
?
測試有很多種：
?
按照測試執行方，可以分為內部測試和外部測試
?
按照測試范圍，可以分為模塊測試和整體聯調
?
按照測試條件，可以分為正常操作情況測試和異常情況測試
?
按照測試的輸入范圍，可以分為全覆蓋測試和抽樣測試
?
以上都很好理解，不再解釋。
?
總之，測試同樣是項目研發中一個相當重要的步驟，對于一個大型軟件，
3
個月到
1
年的外
部測試都是正常的，因為永遠都會又不可預料的問題存在。
完成測試后，完成驗收并完成最后的一些幫助文檔，整體項目才算告一段落，當然日后少
不了升級，修補等等工作，只要不是想通過一錘子買賣騙錢，就要不停的跟蹤軟件的運營
狀況并持續修補升級，知道這個軟件被徹底淘汰為止。
?
寫這些步驟算不上賣弄什么，因為實話講我手邊是一本《軟件工程》，在大學里這是計算
機專業的必修課程，但是我知道很多程序員似乎從來都只是熱衷于什么《
30
天精通
VC
》之
類的，他們有些和我一樣游擊隊出身，沒有正規學過這個專業，還有一些則早就在混夠學
分后就把這些真正有用的東西還給了老師。
?
網上現在也很浮躁，一些
coding fans
亂嚷嚷，混淆視聽，實際上真正的技術專家很少在
網上亂發帖子的，如筆者這樣不知天高地厚的，其實實在是算不上什么高手，只不過看不
慣這種對技術，對程序員的誤解和胡說，只好挺身而出，做撥亂反正之言，也希望那些還
沉迷于一些錯誤人士的
coding fans
們能認真想想，走到正途上，畢竟那些聰明的頭腦還
遠遠沒有發揮應有的價值。
?