Re: 這樣的方式我應該如何選擇--文件與經驗傳承

[thinkniht (不下棋=.=)]

※ 引述《NDark (溺於黑暗)》之銘言：
: ※ 引述《ggg12345 (ggg)》之銘言：
: 1. 工程人都不喜歡寫文件。這是真的，喜歡寫文件能寫文件的可能就不會走這條路。
: 2. 文件是為了承先啟後，如果我們想一輩子做底層的程式設計師，當然功能做好等下班
:    就好。
: 3. 文件寫到夠用，看得懂就好。使用一些共同編輯的工具減少文件的維護問題（譬如說
:    註解或wiki）。
: 4. 不要硬逼工程人員達到不可能的標準，反而要逐步教育，一次只要求多一點，反彈就
:    會比較小。
: 5. 從源頭開始，從程式碼註解開始，寫程式碼的人最熟程式碼，讓他們在習慣的地方寫
:    文件。
: 6. 使用自動化的軟體建立文件，教育程式人員寫Doxygen的註解，減少撰寫無謂的文件
:    的時間（類別，成員，定義等等）。
: 7. 從進程式碼（commit）的註記開始，確保每次的改動都知道為了什麼。也就是有些人
:    提倡寫User Story，一口氣沒辦法從無到有把完整的文件建出來，那就從每次改程式
:    發生了什麼事情開始，一次只寫一點，累積這些軌跡，一樣有他的效果。
: 8. 先寫文件，再開發。讓程式人員在還沒真正寫程式之前把規格，問題，以及要做的事
:    情都搞清楚。避免過度設計或做多餘的介面與功能。
: 9. 開發後，寫文件。補充介面的註解，為什麼要寫這個功能，撰寫Tutorial或Example
:    。讓其他人知道到底這個功能：為什麼，是什麼，該怎麼用。
: 10.找助理來幫忙寫註解／文件，讓程式人員沒有藉口。
: 11.文件是為了溝通，用嘴巴講都很簡單，用嘴巴講都說就是這樣沒錯，一寫下來清清楚
:    楚白紙黑字賴不掉，馬上就改口說其實我的意思不是這樣。
: 12.文件從寫完的那一刻開始就過時了，但是一個過時的文件都比沒有文件來的好。
我認為寫文件要看是甚麼文件
像我比較討厭那種就只是給人看爽的文件
寫那種東西沒啥意思
如果是對之後的開發有用的文件
我會比較有興趣

至於要程式設計師寫程式碼的註解...
會有一個問題
就是程式設計師要不要花時間讓別人好接手

找助理幫忙寫註解或文件...這或許是個好主意
不過這當中通常都會有另一個問題...
"公司捨不捨得出錢請助理來做這些"
比較常見的結果就是...讓PG全包了

其實很多問題都是可以解決的
但是通常...人們為了不想付出時間或金錢
使得問題沒有被解決掉....

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 114.44.17.79
→ awert:隨便弄到最後受苦的還是自己居多..
推 NDark:藏私的工程師升到最後最多就是個資深工程師.
→ NDark:很簡單回答一個問題就好 藏私的工程師要怎麼教自己的小弟?
推 luciferii:我覺得作資深工程師比作主管開心多了...
推 NDark:我想賣雞排當老闆會更開心XD
→ NDark:單打獨鬥的年代已經過去了.一個人一天就是8小時工時.
→ NDark:超時工作 是撐不了幾年的.打組織戰才是正確方向.
→ NDark:資深工程師負責提供經驗 作出好的"設計",實作給源碼戰士來.
推 b6byc:台灣老闆只想急行軍,死了多少人毫不在意.
推 NDark:短視造成的問題很清楚.累積不了自己的能量.撿菜尾而已.
推 ggg12345:最好是寫完程式碼也就等於同時寫完文件,提高可讀性就可以
→ bndan:光放一個正妹助理在你旁邊幫你寫註解就不知道羨煞多少人(誤)
→ bndan:全包必然玩到最後會為了加速而造成文件或註解品質大降