這篇文章講的是程式碼的東西，不會寫程式的請直接跳過吧！
「當心，水深危險，不要溺斃於專有名詞之中！」
什麼是不恰當的程式？嗯～這很難回答，不如先來談談寫程式的經驗法則。
程式要模組化，要有架構，要預先做好規劃與設計，程式碼要結構化，要有段落，要寫註解。如果違反了這些經驗法則，就會是一段不恰當的程式碼了。我不能說程式的哪邊錯了，但它就是有些不好，可能比較難以進行後續的維護工作，也可能比較會『藏污納垢』。
我遇過最令人感到尷尬的『不恰當』，卻恰恰相反，它符合了上述大部分的經驗法則，所有人看到這段程式碼，都打從心底發出了讚嘆之聲：
「這到底是哪位神人的傑作？為什麼我就是想不到這種寫法！實在設計得太巧妙了，超有結構化、有彈性、有擴充性，但就是有一點點的．．．看不太懂為什麼它會work！」
最後『看不懂』那一句，並不是我故意加上去的伏筆，這句話通常是用來形容最精巧的設計的，就好像愛因斯坦的『相對論』剛發表時，所有物理界精英對這偉大理論的感覺：雖然找不到破綻，一時間卻也無法接受這個新理論。
事情是這樣子的，有客戶嫌我們家產品的影像解碼速度太慢，
「ㄟ，你們解碼的畫面會很慢耶！」
「有嗎？我看它跑得還蠻順暢的啊！」
客戶將競爭對手的產品靠過來，
「注意看喔！」作勢將手往鏡頭前揮動，「看到了沒，是不是有差？」
瞬間三條線掛到我們的臉上，連說話都有點結巴，
「呃～有～有啦！」
經過測試，終於找到效能的瓶頸，在於一段處理影像封包檔頭的程式碼。這段程式碼為了處理不對齊位元的情況，設計了一套精巧的資料結構與操作方法，來處理不對齊位元的資料流。好笑的是，每判讀一個欄位，不管這個欄位會不會用到，都要維護這個資料結構到最新的狀態。
影像解碼就是循序的去解讀每一個位元，不斷的重複同樣的動作，有Ｎ個位元就重複這個動作Ｎ次，「把維護資料結構這一連串複雜的動作，包在迴圈的最深處了！」這動作會重複Ｎ遍啊！
而實際的情況更糟糕，因為維護資料結構的程式碼，又做了一層迴圈，唉呀！迴圈中的迴圈，真是要命唷！難怪效能會這麼差。
經過一番折騰，大家對問題的成因已有所體會，但是卻沒有人敢去動這段程式碼，因為這段程式真的寫得太棒了，棒得讓人無法確定自己是否能夠完全的理解它執行時的所有細節，簡單的講，就是怕越改越多BUG啦！
真是令人尷尬，是誰在最需要效能的地方劃下這一刀，切開成兩個模組，失敗的手術刀成了『模組化』最糟糕的範例，有一種打自己一巴掌的感覺！
更多「程式設計」文章：
更多「物件導向」文章：
繼承是父子關係？才怪！ 物件導向初學者應該要知道的事情(四)
留言列表
