如何撰寫程式開發的（維護）說明文件

　　為程式建說明檔是個好習慣，怎麼寫最好？當然是以讓任何一個接手的開發人員能夠愈輕鬆接手愈好。就算程式當初是自己寫的但過了一陣子後，也是會需要再重新了解當初的內容。故安排好開發計畫的時程除了基本的需求，最好也對程式的相關說明撰寫列入考量或當做是例行工作。

參考
Writing a good README
http://blog.thefrontiergroup.com.au/2013/05/writing-a-good-readme/

以下是上面網頁提供的該如何寫好程式說明文件的大概內容(準確的還是得再看原文)
基本的說明資訊：
1.案件的名稱
2.顧客跟任何合作的第三方廠商連絡資料
3.案件開發者的名子
4.簡單描述這個案件主要是要解決什麼問題
5.案件的架構及使用的技術、開發、使用平台、程式語言、資料庫、ORM
6.與此相關的案件
7.連結到該應用的相關線上工具（儲存、案件追蹤...etc）

起手：
說明如何存取相關開發程式所需資源(文件、程式)及建立該程式的開發環境及其相關設定和執行方式，包括測試、及相關資料路徑，使用者認證的格式清單(這個應該是指像是網站登入不同權限認證之類的東西)

測試：
可提供一些測試用的參數，輸入或進行什麼操作時應該得到什麼結果

上架&生產環境：（應該是指讓成果驗證或上架的地方）
1.程式在哪個server執行(放到哪)
2.怎麼放到server要不要權限，跟誰要這個權限
3.程式是要放到server的哪個路徑
4.部署的流程
5.程式是不是需要排程及給相關的開發者知道

網頁的作者是建議養成撰寫文件的習慣，例如每個禮拜都花個30分鐘來更新最近工作的相關說明文件，在短期內或許不能看到特別的效果但經過一年以後，無論是否仍是自己去維護該程式，只要是接手的人都會很希望看到清楚的案件說明。

整個開發循環大概就是重複下面的事
1.計畫功能
2.寫測試
3.實作功能
4.更新說明文件（假如需要的話）
5.重新檢視程式並確認程式能通過測試
6.整合相關功能

基本上花時間寫文件是為了節省未來維護的時間，而大多數的系統開發所花的資源大多是在維護上，故做計畫或撰寫說明文件最好別為了搶快而造成更多的成本浪費。