怎樣的程式算好維護
很多程式設計師在接手別人的程式碼時，都會抱怨別人程式寫得很怪，很難維護
那到底怎樣的程式才算好維護呢?
我想很多批評的人在遇到這個問題，大概也很難回答得出來吧
這篇文章是想描述我認為怎樣的程式碼才算好維護
要改一個程式需要經過三個階段
解析、分解、再建構(那是卡通鋼之煉金術師的煉金術的三個階段XD)
理解、修改、驗證
當我得到一個修改程式的需求
我要先理解目前程式大概如何運作
接著我需要去改程式
改完後我需要驗證我的修改是否正確
好維護的程式應該是要能有利於這三個階段的運作
怎樣的程式碼好理解呢?
有的人會認為要有註解
那麼假如一個3000行的程式檔案，裡面有7成以上都是註解，各位會認為這肯定是個很好維護的程式嗎?
又或者程式碼一堆"xxxx年xx月xx日 某某人 為了甚麼原因改程式"，然後你也搞不清楚這註解是指哪段到哪段，以及是否還有效(也可能被別人改掉了)
有的人主張寫程式要讓程式碼會說話，看code就能很輕易理解這程式在做啥，而不需要寫太多註解
我是比較認同這樣的想法，但是要怎麼讓code本身就很容易被理解呢?
我認為要
1.簡短(我主張一般情況看300行的code會比看3000行的code容易多了)
2.邏輯與責任不要一堆綁在一起(如果一行程式包含著一大堆的邏輯，那也是不太好理解的)
3.統一的架構(如果一個系統有好幾種架構同時存在，那怎麼想都比只要理解一套寫法麻煩多了)
我自己可以透過物件導向把共通的程式邏輯抽出來、避免程式碼重複、也減少維護所需要看的code
至於修改這件事情，我想就維護性上來看，只要程式間的相依性別太高，不要隨便牽一髮就動全身，修改是不會太難的
(如果是客戶需求太過不可能而導致很難修改，那就不是程式好不好維護的問題了)
讓程式好驗證驗證
這也是要讓邏輯別一堆綁在一起，讓人能夠輕易地對修改的那塊進行驗證
三個階段都講完了，但其實重點還是在好理解的那三項
前兩項可以透過物件導向來實現(記住:但不是只要使用物件導向就好維護)
至於第三項統一的架構，我想就跟管理有關了
留言列表
