Re: 這樣的方式我應該如何選擇--文件與經驗傳承
※ 引述《lgd1008 (lgd1008)》之銘言：
: 程式碼的交接, 其實 "文件" 並非最大的問題, "人" 才是最大的問題.
: 因為並非只有文件能達到說明的功能. 一個願意說明的人, 在文件以外的眾多地方, 在變
: 數的命名上, 在程式的架構上, 在工具的選擇上, 測試的案例上, 都會有能留下更多解說,
: 造福後人的機會.
: 但對於 "留一手", 或 "本來就應付不太來" 的人, 就算他給了你文件, 程式碼, 你看不
: 看得懂是一個問題, 值不值得看又是一個問題了; 而就算是對於很無私, 又很高明的人而
: 言, 他留下的東西, 也不一定能完全切合你的需要. 所以制度的建立很重要, 平時就該常
: 常review, 常常進行合作了, 並非等到交接再來檢查,再來移轉.
: 而且人替換得越多次, 東西擁有淺在問題的風險, 就越高. 有時要考慮的, 不只是人如何
: 替換, 而且這個人的遺留物, 也要考慮該不該替換...
: -----
: www.facebook.com/java.tw
我挺同意你的看法
其實對於接手的事情
有很多種做法
code review是一種
pair programming則"應該"是更有效的做法
(我沒實際用過pair programming)
但管理層級的人通常不會想這樣玩
常見的情況是平常就開發就好
人要跑了再說留文件
之後就都讓接手的人自己看著辦了
誇張的情況是人都離職一年以上了
還找對方"幫忙"看code(也就是靠人情)
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.42.240.178
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 6 之 6 篇)：