TomWang的部落格

最近跟也是寫程式的朋友吃飯聊天
其中講了幾件事情
1.公司不給員工教育訓練是正常的，要訓練的話請新鮮人不就好了，還比較便宜
2.物件導向的程式，在維護上很難懂，因為要看很多class，而不是只看一個地方
3.尤其是維護他人寫的程式更麻煩，他認為程式一定要寫註解才能看懂

我自己用物件導向寫程式，我蠻少寫註解
但我仍有信心在未來即使很久沒碰，一樣可以輕易看懂
我寫的程式能否讓別人輕易看懂呢，這並非不可能
只是這需要一般認為公司最不需要做的教育訓練

為什麼我有信心可以很快看懂
因為我寫程式會有一套規範(即使只是自己個人定義的)
看method名稱就能大概猜到在做啥
覺得有問題時在看method內的程式碼，這樣我需要看的程式碼就會變得比較少，進而讓我說我可以輕易看懂

但如果要讓別人也能輕易看懂
那他得了解我的規範與風格
這種規範與風格其實是可以預先定義好的
如果團隊有一套開發的規範，且大家都能依循著開發，那就能夠讓大家都容易維護別人寫的程式
而且也不用寫太多註解
(我認為註解寫太多，其實反而難維護與理解，尤其當程式變動過很多次以後)

要怎麼建立規範呢？
那就需要透過時常的教育訓練與技術的討論
讓大家對於問題的解決方式能夠有所共識

比如：
說跨網站腳本攻擊好了，解決方式就可能有好幾種
有的人可能再存資料庫前就做特殊字元的替換
也有在撈資料後做替換
就算用一些tag語法在view做處理，其實也有很多種方式可以使用

當一個系統很多人在寫時，難道應該要一人一套做法嗎???
良好的方式應該是要做處理時可以詢問與討論這問題該怎麼處理
透過做適當的教育訓練來建立規範，這樣維護別人的程式時才不用去想像別人的處理邏輯

我說的教育訓練還是針對問題的解決
有些真的很基本的事情，那不算為了建立規範而採用的教育訓練，例如：
傳值和傳參考是甚麼
get和post的差異
怎麼分前端處理和後端處理

這種已經牽涉到機制了，沒甚麼建立規範的需要(又不可能同樣的程式碼在這間公司是傳值，在另一間公司是傳參考值)，這種事情如果說資深的就不需要教了，那我覺得還挺合理的
有些比較進階的東西，例如怎麼使用物件導向，我認為就有教育的需要

當一個團隊有很多經驗豐富的開發者時，他們對於同樣的問題會有不同的意見與解決方法
如果不做統合，那會讓彼此合作發生問題，很容易同樣問題卻多少人就多少套寫法

但台灣老闆就是喜歡
1.盡量只找有經驗的程式設計師
2.認為不該搞教育訓練
時間久了就開始感覺系統好像很難維護，都是之前的開發者搞爛的，但其實這是可以透過管理與教育訓練來解決的

最後簡單表達我想說的:
1.物件導向其實真的很好用
2.註解其實不需要寫太多

只要...老闆做一般台灣老闆不太會做的事情XD