R16 程式碼的MVC

系統上的MVC設計被很廣泛地接受，將功能所需的資料、流程與顯示分開存放，在絕大多數的狀況下可以僅異動或更換其中一塊而保持另外兩塊不受影響。將資料與程式依特性放置在不同的元件中能夠有這樣的好處，那麼在元件的黑盒子裡如果運用這個想法會不會有同樣的好處呢？

這兩年來我維護了許多其他同事所寫的元件，那些程式全部都是依個人風格所寫，由於開發時我沒有參與，接手時也沒有足夠的說明與文件，因此我相當清楚維護的瓶頸在哪些地方。問過一位喜歡看設計書籍的同事，他說沒看過有人像我這樣推動程式碼內容依MVC擺放的論點，因此我也沒有足夠證據證明它的好處，只能說之前的團隊在換不同成員處理一個元件時真的極易上手。

曾經與公司一位經理說過，我的設計方式可以具有變動彈性、方便維護、容易除錯的特點，但由於要定義架構元件的明確層次與複雜化程式內部的擺放，會使得開發需要的人力再多出一倍左右。那位經理反問我，要怎麼去說服上面同意給兩倍的人力來做出功能完全相同的產出？重心如果放在“那個階段可以產出什麼”的話，我完全無法說服任何人。

別人程式的難懂在於達成功能的所有流程與動作是什麼？使用到的變數放在哪裡？還有不知道某個區塊的程式到底想達成什麼功能？看過一些文章教人如何去抽絲剝繭、循序漸進地去看懂其他高手的程式碼，曾經歷此道的我可以斷然地說那是徒勞無功的。想法轉換為程式的變化如果沒有任何說明，就像一個小型的謎題一樣；你能想像在一個上百萬行的專案程式碼裡，有多少大大小小的“謎題”存在嗎？

猜燈謎時不見得每個參與者都能猜出答案，有的人花很長時間絞盡腦汁還是想不出來。但是卻有一個簡單的方法可讓所有人立即明白答案與原因──那就是讓出謎的人直接將答案告訴每一個人。