A02 心裡的想法應該被記錄下來

2006下半年很榮幸地接下維護一項十多個人開發的系統。那個系統的domain是我不怎麼熟悉的，而且所有程式碼沒有任何一行是我撰寫的。於是接下來的對話，很常在我與他人之間出現：

“這個子系統（模組）總共有哪些功能嗎？”“我可以給你一些，但不保證是全部。”
“這個功能的操作劇本是什麼呢？”“大概是這樣，這樣再這樣。”
“當初為什麼會選用這個架構呢？”“不知耶，不是我決定的。”
“這個操作劇本的流程對應的程式是哪些？”“我忘記了，查一下程式再告訴你。”
“這行程式是為什麼放在這裡？”“我完全想不起來，你可以自己查嗎？”
“我如果修正這段程式，要測哪些才能確認沒有side effect？”“你反覆用references倒查回去到最外層，測你搜尋到的全部。”
“這個模組為什麼完全沒有說明文件？”“所有想法都產出在程式裡呀，而且我保證是經過驗證的。”

如以上對話可見，在沒有設計文件與程式註解的環境裡，面對著內裡錯蹤複雜的黑箱系統，維護人員必須拿出名偵探般的實力，隨手捏起一個線頭後得慢慢抽絲繭地倒推至根源。這可不是件好玩的事，因為程式裡的呼叫有如迷宮般亂串，絕大多數時候你所找到的答案並不是真相。

於軟體工程的理論，直接寫下功能所花的時間比例若為一，以有彈性的產品作良好設計大約要花三倍的時間，儘可能作完整的測試並再撰寫適當的文件要再花三倍的時間。如果一開始沒有做好，我覺得重構設計並再實作差不多要六倍的時間，在沒有任何提示的情況下反推原來的設計概念可能要十倍的時間，而且還不保證內容涵蓋度能達到百分之百。

我們可以看出，逆向反推原來的設計概念必曠日費時又事倍功半。既然如此，設計人員就應該順向將心裡的想法詳實地記錄下來，如此方為正確的傳承之道。