Re: 這樣的方式我應該如何選擇--文件與經驗傳承
※ 引述《ggg12345 (ggg)》之銘言:
: ※ 引述《howshou (好小 )》之銘言:
: : 如果你真的有認真看過文件,你會越來越不相信文件。
: : 我記得前幾年我看約耳談軟體(Joel on Software)這本書時,
: : 覺得超有幫助的,果然任何變更都要有文件。先有文件再寫軟體。
: : 所有的專案管理經驗與書籍也會告訴你, 寫文件比寫程式重要。
: : 它們說得都對,你說的也對。
: : 但是我不知道為什麼,現實生活就是窒礙難行。
1. 工程人都不喜歡寫文件。這是真的,喜歡寫文件能寫文件的可能就不會走這條路。
2. 文件是為了承先啟後,如果我們想一輩子做底層的程式設計師,當然功能做好等下班
就好。
3. 文件寫到夠用,看得懂就好。使用一些共同編輯的工具減少文件的維護問題(譬如說
註解或wiki)。
4. 不要硬逼工程人員達到不可能的標準,反而要逐步教育,一次只要求多一點,反彈就
會比較小。
5. 從源頭開始,從程式碼註解開始,寫程式碼的人最熟程式碼,讓他們在習慣的地方寫
文件。
6. 使用自動化的軟體建立文件,教育程式人員寫Doxygen的註解,減少撰寫無謂的文件
的時間(類別,成員,定義等等)。
7. 從進程式碼(commit)的註記開始,確保每次的改動都知道為了什麼。也就是有些人
提倡寫User Story,一口氣沒辦法從無到有把完整的文件建出來,那就從每次改程式
發生了什麼事情開始,一次只寫一點,累積這些軌跡,一樣有他的效果。
8. 先寫文件,再開發。讓程式人員在還沒真正寫程式之前把規格,問題,以及要做的事
情都搞清楚。避免過度設計或做多餘的介面與功能。
9. 開發後,寫文件。補充介面的註解,為什麼要寫這個功能,撰寫Tutorial或Example
。讓其他人知道到底這個功能:為什麼,是什麼,該怎麼用。
10.找助理來幫忙寫註解/文件,讓程式人員沒有藉口。
11.文件是為了溝通,用嘴巴講都很簡單,用嘴巴講都說就是這樣沒錯,一寫下來清清楚
楚白紙黑字賴不掉,馬上就改口說其實我的意思不是這樣。
12.文件從寫完的那一刻開始就過時了,但是一個過時的文件都比沒有文件來的好。
--
"May the Balance be with U"(願平衡與你同在)
視窗介面遊戲設計教學,討論,分享。歡迎來信。
視窗程式設計(Windows CLR Form)遊戲架構設計(Game Application Framework)
遊戲工具設計(Game App. Tool Design )
電腦圖學架構及研究(Computer Graphics)
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.42.150.90
※ 編輯: NDark 來自: 114.42.150.90 (04/05 22:22)
→
04/05 22:27, , 1F
04/05 22:27, 1F
→
04/05 22:28, , 2F
04/05 22:28, 2F
→
04/05 22:28, , 3F
04/05 22:28, 3F
→
04/05 22:50, , 4F
04/05 22:50, 4F
推
04/06 01:31, , 5F
04/06 01:31, 5F
→
04/06 08:12, , 6F
04/06 08:12, 6F
推
04/06 12:51, , 7F
04/06 12:51, 7F
→
04/06 18:41, , 8F
04/06 18:41, 8F
推
04/06 21:38, , 9F
04/06 21:38, 9F
→
04/06 22:10, , 10F
04/06 22:10, 10F
→
04/06 22:16, , 11F
04/06 22:16, 11F
→
04/06 22:17, , 12F
04/06 22:17, 12F
→
04/06 22:17, , 13F
04/06 22:17, 13F
→
04/06 22:17, , 14F
04/06 22:17, 14F
→
04/06 22:28, , 15F
04/06 22:28, 15F
→
04/06 22:31, , 16F
04/06 22:31, 16F
→
04/06 22:37, , 17F
04/06 22:37, 17F
→
04/08 13:05, , 18F
04/08 13:05, 18F
討論串 (同標題文章)