程式碼大掃除
在開發系統過程中，理想的開發流程是先有文件，再來coding，但事與願違，很多時候在coding時才發現當初設計有許多地方考慮不周，當下就直接在code上調整，或有些實作方式還不確定，須要用 code 實驗，寫完 code 立刻跑看看，這邊改一點，那邊跑一下，立刻看到跑出 code 效果的感覺真是爽呀。
不過爽完之後，總是要開始面對實驗不成功的多餘 code的問題，我們工程師對於自己曾經辛苦思索過的產物多少會有一份感情，雖然已知道留下這些 code 也沒甚麼用，但那怕有一天會用得上，因此有的人會 remark 起來，寫個簡單註解。有的甚至就把方法放著，反正只要沒人call 這個方法就ok了。
系統的誕生過程是如此，維護過程更不用說，遇到一個 bug，好不容易找到出錯點，唉呀~當初的人怎麼寫得那麼複雜，看都看不懂，自己重寫比較快，於是就將原來的方法remark掉再寫個新的。
不過爽完之後，總是要開始面對實驗不成功的多餘 code的問題，我們工程師對於自己曾經辛苦思索過的產物多少會有一份感情，雖然已知道留下這些 code 也沒甚麼用，但那怕有一天會用得上，因此有的人會 remark 起來，寫個簡單註解。有的甚至就把方法放著，反正只要沒人call 這個方法就ok了。
系統的誕生過程是如此，維護過程更不用說，遇到一個 bug，好不容易找到出錯點，唉呀~當初的人怎麼寫得那麼複雜，看都看不懂，自己重寫比較快，於是就將原來的方法remark掉再寫個新的。
這種”remark code”一多，整份程式碼都充斥著大量remark，維護工程師看了就很不舒服，有甚至當初為何remark掉也沒寫，害後面看不順眼的工程師也不敢隨意砍，也許那段remark code是當初做實驗的、也許是客戶需求的反反覆覆所留下的，也許….。
回頭看捨不得砍掉程式碼的情結問題，現在程式碼都已用cvs控管，如果日後真的想找回當初寫的這段程式碼，只要commit cvs 當下有做好註解，後面要找回來不是大問題。所以這種實驗失敗的程式，理應當下就要清理掉。除了程式片斷，也有很多是沒在用的變數也應該清一清，留下來的垃圾越少，可維護性就會越高。
所以當開發系統try&error 一段時間後，請記得最後在release之前，重新review一下程式碼，除了清理垃圾外，也應該review 一下每支程式，在需要的地方補上註解。讓最後release 的程式碼的每個變數，每個方法都是確實有用的。
很貴的程式碼混淆器都有混入垃圾程式碼的功能，讓偷窺的人雖然看到反組譯程式碼，但要在參雜大量垃圾的程式碼中理出個頭緒就很難了，我們常取笑某些系統已經過「人工碼混」，如果這些垃圾程式碼、方法、變數、remark不拿掉，後面維護的人也同樣會取笑我們已經程式碼混淆完畢了。
沒有留言:
張貼留言