看板
[ Soft_Job ]
討論串這樣的方式我應該如何選擇--文件與經驗傳承
共 6 篇文章
內容預覽:
程式碼的交接, 其實 "文件" 並非最大的問題, "人" 才是最大的問題.. 因為並非只有文件能達到說明的功能. 一個願意說明的人, 在文件以外的眾多地方, 在變數的命名上, 在程式的架構上, 在工具的選擇上, 測試的案例上, 都會有能留下更多解說,造福後人的機會.. 但對於 "留一手", 或 "本
(還有279個字)
內容預覽:
恕刪其它. 分享一下我自己的經驗. 首先，先搞清楚文件要到什麼樣的等級. 如果你是寫Library來賣的或是開發Library，請參考一下Java Doc或MSDN. 這一類的文件是給千萬人讀的，當然就應該答到更高的水準/要求. 再考慮什麼樣的文件是合理的情況之前，請先考慮好你的讀者. 舉個例來說，
(還有1095個字)
內容預覽:
我認為寫文件要看是甚麼文件. 像我比較討厭那種就只是給人看爽的文件. 寫那種東西沒啥意思. 如果是對之後的開發有用的文件. 我會比較有興趣. 至於要程式設計師寫程式碼的註解.... 會有一個問題. 就是程式設計師要不要花時間讓別人好接手. 找助理幫忙寫註解或文件...這或許是個好主意. 不過這當中通
(還有4個字)
內容預覽:
1. 工程人都不喜歡寫文件。這是真的，喜歡寫文件能寫文件的可能就不會走這條路。. 2. 文件是為了承先啟後，如果我們想一輩子做底層的程式設計師，當然功能做好等下班. 就好。. 3. 文件寫到夠用，看得懂就好。使用一些共同編輯的工具減少文件的維護問題（譬如說. 註解或wiki）。. 4. 不要硬逼工程
(還有705個字)