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

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

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

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

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

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

A01 軟體是一項工程，計算機是一門科學

有許多人在收集好客戶需求後，就文思泉湧地在很短時間內寫出符合所有功能的程式。直接把想法落實為程式碼的方式，具有最快的開發速度；邊測試邊修正的特性，也可以保證系統有相當的穩定度。但，這是理想的方法嗎？

在教育部的網路國語字典裡，工程的解釋為“有一定計畫的工作進程”，科學的解釋是“以一定對象為研究範圍，依據實驗與邏輯推理，求得統一、確實的客觀規律和真理”。很明顯地，前面的說法並不符合這樣的定義。

直接開發的人之所以會這麼做，主要是因為快速；反正程式的修改又不具任何代價，想怎麼改就怎麼改，想怎麼搬就怎麼搬。這種想法拿來套用在興建蘇花高的話應是這樣：先建下去再說，功能達到優先嘛！建到一半發現地基鬆軟時再補強或繞道？對生態的影響也等建好再來觀察？這很明顯不是理想的方法呀。

這是我不偏好XP方法的原因，如果所有功能都邊寫邊改，在較大的系統裡常會發生前後不一致的現象。曾經有個API定義是應入null的值時去刪除集合中的鍵值，但直接開發的同事在使用時傳入空字串，接手的我除錯了兩個多小時才發現是這裡錯。方法無限制地抽出與合併，沒經過詳細評估又未留下詳細註解，到最後會連設計者都不知道他曾經做過了什麼。

我看的書很少，但是上過Sun的OO-226課程後，發現OOAD的思維與人生道理有很多相互對應的地方，同時慢慢明白設計方法與軟體工程的對應關係。我的理論基礎不深，多年以來也都是以實作派的方式做事，不過在這兩年的經驗裡，我卻發現把理論對應到實作的方式。

以OOAD為起點，慢慢地推廣視野到軟體工程，同時領略到不少人生的常理，也順便瞭解到處理事情的原則。這樣的收穫怎不令人欣喜？

[X] 我的想法－－導引投影片 (12/00)

太多的文字若沒有引導會完全無法發揮效用，製作投影片的同時也整理了自己的思緒。
關於投影片的意見請反應在這裡。

現在的版本：V0.08　[ 按此下載 ]

[最近修改]
2009/06/10 － V0.00 新增內容 01-物的基本概念
2009/06/10 － V0.00 新增內容 02-事的基本概念
2009/06/13 － V0.01 新增內容 03-達成目標所需的一切
2009/06/13 － V0.01 新增內容 04-功能的收集與記錄
2009/06/18 － V0.02 新增內容 05-從底部建立的層次
2009/06/27 － V0.03 新增內容 06-軟體工廠的形成
2009/06/30 － V0.04 新增內容 07-需求的分析與設計
2009/07/04 － V0.05 新增內容 08-元件的完整結構
2009/07/10 － V0.06 新增內容 09-程式結構化的好處
2009/07/11 － V0.07 新增內容 10-元件結構一致的運用
2009/07/14 － V0.08 新增內容 11-測試與除錯的演進
2009/07/14 － V0.08 新增內容 12-其他方面的一些想法