TomWang的部落格

很多人認為程式該寫註解未來才好維護
否則過幾個月都看不懂那程式在做啥

我認為註解寫太多其實會是問題
因為你要看的文字也多
甚至如果程式變動次數多了，會看到一堆幾年幾月幾日，哪個開發者寫的程式做了甚麼事情
也搞不太清楚哪段註解是講那段程式，那也是個麻煩

我寫程式不太喜歡寫註解，不是單純的懶
而是因為不需要所以不寫
我用物件導向讓程式可以看method的名稱就知道在做啥，而不需要去慢慢看邏輯，也不需要太多註解做說明
通常最多在method前面說明做甚麼，還有參數的說明。但是method內"通常"不會寫註解(因為不需要)
就算我過一兩年後再看要修問題，我也有信心快速了解
我那種寫法 如果有做單元測試的話會更好(不過我沒嚴謹到那種程度啦)

很多管理者對於軟體開發是因為我不想花時間，所以不要做
我有一次去一間算知名的中型公司面試
他們有用瀑布式與scrum
瀑布式卻不寫SA文件，理由是需求常常變動，寫文件太花時間
那麼問題來啦...SA文件真的沒用嗎？？
不寫SA文件不是因為SA文件沒有用，而是不想花時間改
問題根源是甚麼?
1.需求變
2.文件變動所花時間多

這樣產生的結果是甚麼?
1.未來PG不會曉得這程式該有甚麼樣的行為
2.客戶要求改東西也搞不清楚是該收錢的需求變更呢?還是不該收錢的bug呢

解決方法應該是甚麼?
1.避免變動
2.文件格式去掉沒有用的部分

我對很多管理者做法不滿的一個原因在於:
他們不會去思考如何讓一件事情變得不需要那麼麻煩
而是覺得一件事情很麻煩就直接不做，而又希望能繼續得到有做這件事情的好處
(那我可以嫌麻煩所以不花時間去工作，但薪水照給嗎？)

我是讓寫註解事情變得不需要而不做，而不是不想花時間而不做，最後承受對應的代價
我認為這才是軟體開發該有的作法