項目前期文檔

Question

我有一個問題，我覺得很多程序員都可以涉及到...

我曾參與過很多小型項目。在我最初的紙腦風暴之後，我傾向於開始編碼。我想到的通常是實際應用的粗略工作模型。我以不連貫的方式進行設計，所以我正在討論底層代碼庫，用戶界面是庫的最後一件事，因爲它們通常會指示UI中需要什麼。隨着我的項目越來越大，我擔心我的「規格」或設計文檔也應如此。

從我的調查結果來看，上述段落以某種方式在互聯網上回響。當涉及用戶界面時，會提供更多信息，但它是用戶界面特定的，並且與代碼庫無關。我開始意識到，也許代碼是代碼。從我的廣泛研究看來，設計文檔和代碼之間不存在1：1映射。

當我需要研究的一個話題我轉儲信息到OneNote中，並從那裏，這樣的發展在相當線性的方式運行，我優先考慮的功能爲版本，然後將相關的塊，我的任務往往看起來像這樣：

1. 實現二進制文件閱讀器
2. 實現二進制文件作家
3. 創建對象封裝數據，爲表達呼叫者

ñ任何值得他的鹽的程序員都知道，這三件事之間的項目可能是一個潛在的代碼牆，可能擴展到多個文件。我試圖爲每個任務繪製完整的代碼過程，但我不認爲它可以有效地完成。當人們破壞僞代碼時，它本質上是代碼，所以時間投資被否定。

所以我的問題是這樣的：

我是正確的假設，最好的文檔是代碼本身。我們都同意需要高水平的概述。這應該有多高？你是否設計了陳述，課堂或概念層面？什麼適合你？

Answer 1

最後，我發現有幾個方法可以解決這個，從心靈映射到概念圖，甚至UML /僞代碼。最後，對個人而言，最有效的方式似乎就是要使用的東西。

Answer 2

我會高度推薦閱讀Code Complete 2，以便對這些問題有一些很好的見解。

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670

Answer 3

我想你想要的是一個軟件需求規格。

以混沌的方式編碼所有的東西是做錯的工作模式！ 你需要的是創建一個函數/非函數需求列表來創建一個鏈接/相關/子/父母與用戶界面的需求和商業角色創建用例的關係。

完成這一步之後，您需要最終管理UML或SPEUDO代碼中的所有設計接口，但是當您規範（對於小型項目）的需求時，需要將UML推遲。

有關代碼的文檔，您可以使用doxygen或javadoc進行簡要介紹， 您在代碼中插入註釋，並使用軟件將所有文檔都放在HTML/PDF中。

有了這種方法，你按順序到達這個東西：

1 - 軟件需求
現在你有什麼是你的軟件的完整的概述，也許什麼功能，你的軟件需要哪些約束（技術/非 - 技術/時間/業務）。 還有用戶案例在開發生命週期的最後階段測試軟件。

2 - UML或PSOUDO CODE
一種簡單的方法將您的工作分解爲其他同事以及簡單的代碼界面設計代碼概述。

3 - 其他程序員像你和所有的好處庫文件，以不浪費太多上場時間，在項目結束時記下所有的文檔！

我的2美分。

谷歌關鍵詞： 軟件工程doxygen的軟件開發生命週期，CMMI，IEEE SRS（軟件需求說明書）。