2月20日真是令人難忘的一天。我們從無到有、從郁悶到興奮，在此期間，大家都圍著白板陷入癡狂，而且我們最終真的設計出來一點東西，可以開始往前走了，這感覺令人著迷。
不過我們確實還是走了很多彎路，在這里還是有很多經驗教訓值得總結：
舉出足夠典型的樣例，根據例子來歸納設計。這其實正是測試先行的一種做法，當我們設計能力并不足以一眼看穿最佳的設計方法時，通過不斷的歸納來逼近最佳的（或至少是可行的）設計是最有效的方法。例如，XophiiX的第一個設計，雖然并不能解決所有問題，但至少也是一個能夠解決問題的設計（不要懷疑，這是真的），它比那種純粹的空中樓閣好多了。
先從最粗略的系統流程開始考慮。這里說的流程并不一定指的是數據流圖，還可能是狀態遷移、用例圖等等，反正就是最粗略的東西，只要能夠理解需求就能夠說出來的東西。例如，我畫的那個流程圖，大家起碼都了解設計的重點和難點在哪里。
采用隱喻（metaphor）的方法可以形象的找到問題的切入點。我不知道原理到底是什么，但是當我們找到一個可以類比的實際系統之后，我們的思路就開闊和活躍了許多，甚至類的職責都可以通過類比來確定。例如，我們把收集詞元信息比作“作坊”，然后再想象作坊內部運作模式，驚奇地發現思路一下就通了。
盡量在一開始就降低類之間的耦合。在設計之初降低耦合往往只是舉手之勞，但是如果最開始沒有理會這樣的問題，那么到以后再試圖解耦合則可能會造成極大的代價。例如，如果作坊一開始就需要專門為一個客戶服務，那么如果我們需要加入更多用戶就必須改動作坊的內部實現，而且測試的時候也需要假定作坊的客戶是穩定的，實在是不爽。其實為了使類擁有“易測試性”，解耦合是非常必要的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/