tsaipifong wrote:
後幾句話看起來似乎成品都沒有文件,也沒有註解似的...
我不相信把文件及註解寫清楚詳細會造成code只有自已會維護的狀況
除非是文件及註解寫得太簡略或其他工程師程度真的差到看不懂
其實說真的從你一位資深工程師口中提出這些觀點
我是一點也不意外
因為這些都正是我從許多資深工程師身上看到的問題
實務上,不是所有系統的程式都有文件
我們都有規定程式的文件,有的甚至要寫wiki給其它team來參考
但事實上,文件都是跟在後面補,有空的補,沒空的就沒有文件
很怪嗎? 很正常,特別是公司的內部開發團隊,不是在賣軟體
還有,這些都跟公司開發團隊的大小有關係
當你的團隊大,還有一堆QA team的人,甚至養一堆人寫文件,可以這樣做
但是如果沒有這麼大的規模,根本就沒有太多要求文件的空間
況且,文件寫的東西往往多是spec或需求,頂多將相關系統關係做描述,
好比用哪些service,有哪些DB info
內部邏輯未必能展現在文件當中
還有,我不只是個資深工程師,我也是principal兼manager,我底下帶team,
公司很多開發的規定也是我在定,可是定再多規矩寫再多文件,東西只要一趕,根本很難實現
很多公司都是如此,包括一些相當大的公司如 IBM,或者美國數一數二大的銀行的內部開發的team
文件很多都還是事後才在補,並不是都是先寫文件再來開發 (剛巧有認識的朋友),而且還是有空才補
這就像當軍人有用槍程序要背,但上戰場時,往往很多只能先抓重點,
因為你的team寫完文件時,人家的team已經寫完project了..
但文件重不重要? 當然還是重要,特別是business requirement document,
但這個不是你程式邏輯的document,靠它,不是每個工程師都能養別人的project.
而且你真認為我丟一本文件給你,你就能養人家的code或者寫一套類似的東西出來嗎?
對我來講,要離職或請長假的工程師,我會盯他的文件要補齊,天天上班的工程師負責的項目,我會跟他們一起review code看有沒有錯的用法,因為我根本沒空去看那些文件,文件也包括不了太多程式邏輯

另外,你說不能怕犯錯而不做
但問題是,根本沒空做,要做就要花時間,你要做還不一定准你做,因為系統上線會要許多人測,要有很多關卡,不是僅一個工程師自己的事,你改一個東西也可能影響別人的系統(好比改動你的service),這都可能是風險
而且每個人都有一堆手上的案子在進行,系統做維護與更新不是做不到,是看公司的team有沒有那樣的空閒時間
在大家在現實環境下會把資源放在重點上的時候,就很難做到舊東西的改寫了
(你有看到戰場上正在守陣地打仗的士兵們同時忙著在改建工事的嗎? 特別是大敵已在眼前的時候)
而且以一個manager的角度,每年每季一個team都有一堆工作項目要往上報,
改寫系統除非有明顯的效能,否則很難讓高層認同是可以花費時間的工作項目,你寫太專業,高層也看不懂
老闆只覺得,東西好好的,你動它幹嘛? 沒事幹了嗎?
萬一改完造成其它team系統的問題,還可能被罵翻,這是很現實的問題

(有的並不是舊的做法錯,而是有新的做法,但有沒有需要為了一丁點好處去改呢? )



























































































