寫程式一定要先寫規格文件嗎?

寫程式一定要先寫規格文件嗎?

2009/9/13 下午 11:24:03
很慚愧寫了七八年程式從沒有好好寫過文件，最近開始認真思考”程式無錯就優” 和”文件的重要性”，每當上頭交代下來一個功能或模組，了解需求後就開始直接寫，所有的架構和流程都在頭腦裡，兩個小時就可以交差了，程式也可以跑，正常情況下也都不會有錯。

但仔細思考下面幾個問題，
這個程式有哪些狀況，會導致致命的錯誤？
如果發生錯誤，程式會有哪些狀況？
如果發生錯誤，程式還會繼續跑嗎？
要增加新功能或功能不堪使用！！
使用者反應程式越跑越慢！！
使用者反應程式有漏資料！！
還有過一段時間後，你還記得程式怎麼寫的嗎？

為了應付上面問題，肯定會把程式翻出來看，然後再重寫，過不了多久明明是一個簡單的程式，變成不是異常龐大就是怪獸，然後改了這個壞了那個。有研究指出因為修改需求，而導致其他錯誤發生的機會有20%~50%。

而上面的還只是一個小模組或小功能，如果是一個專案呢？那真是很難想像，在一個怪獸級專案上面維護和加功能需求，每天除不完的Bug，加不完的班。

因為沒有像樣的文件，連要找人來寫，都要解釋半天，最後只好自己寫比較快。

因此多年後的現在，我開始思考規格文件的重要，要如何寫？軟體工程很多理論，到底那一套才是有效的？我應該要學哪一種理論？那一種理論適合我現在的工作，並且可以馬上適用？

最後我領悟與歸納出下面的方式，來應付小專案或小模組的開發模式

1. 採用物件導向開發，但一定要研究過物件設計模式，因為如果沒有研究過設計模式，寫出來的程式充其量只能說是物件化的模組，對於這個我最近有深切體會。

2. 善用活動圖，物件圖與循序圖，著手開發前一定要至少畫出物件圖，不過一定要研究過設計模式，並且有深刻研究過物件導向的特色，這樣畫出來的圖才可以真正的表現出物件導向的特點。

3. 時時重構，每開發完一個功能後，必須審視您的物件圖與程式是否一致，並思考程式是否有符合物件導向最高原則，開放封閉原則，一旦發現可以調整的地方就要重構。

4. 自動化單元測試，因為採物件導向的開發，所以可以很容易的撰寫單元測試的程式，這樣往後的每次修改，只要將單元測試拿出來跑一次，就知道這次的修改是否有影響到其他的程式，至少可以保證一定的程式品質。所以單元測試程式隨著功能的增加，會越累積越多。

有一種軟體開發方式XP敏捷式開發，就是講究開發之前要先寫單元測試，叫做測試驅動，透過先撰寫測試程式來引發需求功能，不過個人認為開發前最好要先劃出物件圖。


當然上面的方式只是用來開發小型功能或模組適用，要開發大型專案，就這點當然不夠，專案開發包含了時程人力規劃，時程追蹤，測試規劃，系統架構規劃，系統整合等…。

2009/9/14 上午 01:19:48
測試驅動跟你的「開發前最好要先劃出物件圖」並沒有直接的衝突。

測試驅動講求的是feedback，由另一個完全不同的角度下去思考程試的架構。你可以先有一個想法(比如你所謂的先劃出物件圖)，用測試驅動來看看這個架構好不好，利用這個測試得到的feedback來不斷修改。或者，你也可以直接使用測試驅動來引導出理想的設計。測試驅動也會使你往後的自動化單元測試更容易撰寫。

我不知道物件導有所謂的「最高原則」。不過Uncle Bob提出他對OOD的想法，簡稱SOLID principle。Open Closed principle只是其中一個。
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

使用測試驅動後，都會很自然的得到符合SOLID的設計。也許你可以參考看看。

2009/9/14 上午 08:53:50
感謝您的糾正~~

我再補充依下，物件導向的確是有很多其他觀點，
我用錯了描述，不應該用最高指導原則，我想表達
的是，不管是依賴到轉、里氏替換...等，其實應該
都是要達到"開放封閉"的原則，當然這只是我的體
會。

另外關於您說的透過"測試驅動"，來驗證"物件圖"，
並找出需要修正的地方，我認為非常有道理，有機會
我會來試試看。

2009/11/16 上午 12:55:19

文件是一定要的. 我當PM的經驗和做法是 必須文件交出後, 才可以算是完成 一項里程(Milestone), 文件交付客戶前, 專案經理及主要規劃人員要簽字, 表示負責的態度. 然後, 要求客戶簽字.

當然, 文件必須依雙方談妥的內容記載 要求客戶簽字前, 也要有合理的時間讓客戶詳閱,.客戶簽字逾期, 下個里程會順延.

以客戶簽字的憑證 證明客戶同意我們幫他們所規劃或設計的內容. 這樣的憑證有下列的作用:

1. 證明專案進度已經完成一個里程, 可以請領這個里程的工程款.

2. 我方保證依文件的內容作為下 一階段的基礎, 專案進度往下一個里程前進.

3. 組員與客戶或下包商都以文件作為溝通的憑據. 當然, 各個參與專案的成員所規劃或設計的內容的必須符合文件規範.

4. 客戶如果要變更先前同意的事項, 必須負擔因變更所產生的費用.

文件的名稱與里程之對照如下:

里程名稱 文件名稱
---------------- ----------------------------------------
開工會議 專案計畫書
需求訪查 需求規範書
高階設計 功能規範書
細部設計 細部設計文件
品質保證 品質保證計畫書
程式設計 程式及Release Note.
整合測試 整合測試報告書
系統導入 導入計畫書
客戶驗收 結案報告書與系統保固書

有些合約是完成幾個里程, 才請領一次工程款.

以上的做法在中大型的專案是絕對必要. 就開發成本來說, 好像是高出許多, 但實際上, 會減少失誤的機率與後續的維護成本. 總成本不會增加.

樓主所言軟體工程的方法, 也要在專案計畫書中述明. 因為軟體工程的方法不同, 因為文件的交付項目或交付的時間會依方法不同而異. 例如採用測試驅動設計方法時品質保證計畫書應在功能規範書出來後不久就要完成, 而且測試的程式也必須列入清單或交付項目. 如何規範則是合約內容而定.

2009/11/16 上午 10:57:35
market requirement document from project manager , then software manager will follow it and discuss with project manager and other related staffs to design a software requirement specification or software requirement document.
this doc is an engineering specification , of course , you may refere to some industrial standards , such as IEEE or dod and so forth. In this doc , software manager uses some modeling languages , e.g. UML or SSADM , DFD to describe those features and floows those principles which were proposed by IEEE.
Once SRS has been completed , software architect starts designing software arcitectures . Software architecture has no any specified principles , he or she designs it alternatively.

When the softwre architecture has been completed , software engineers or programmers start coding or programming those modules which they own in some high level programming languages , such as C/C++, java, C#,
vb, delphi and so forth , meanwhile , they should design those docs - SDD ( software description documents) in
some pesudo languages , such as PDL or english-like programming languages.
this process belongs to the verification phase of V&V model. Of course , in this model still exists a problem , that is ,
when your customers want to the result of design in early stage, this model will face some difficultities.
because engineering team spends a lot of time to design documentations , customers will see their products in later stages. All processes were well-defined.

Reference:
http://www.programmer-club.com/showSameTitleN/exp/13992.html