2月20日真是令人難忘的一天。我們從無到有、從鬱悶到興奮，在此期間，大家都圍著白板陷入痴狂，而且我們最終真的設計出來一點東西，可以開始往前走了，這感覺令人著迷。
不過我們確實還是走了很多彎路，在這裡還是有很多經驗教訓值得總結：
舉出足夠典型的樣例，根據例子來歸納設計。這其實正是測試先行的一種做法，當我們設計能力並不足以一眼看穿最佳的設計方法時，通過不斷的歸納來逼近最佳的（或至少是可行的）設計是最有效的方法。例如，xophiix的第乙個設計，雖然並不能解決所有問題，但至少也是乙個能夠解決問題的設計（不要懷疑，這是真的），它比那種純粹的空中樓閣好多了。
先從最粗略的系統流程開始考慮。這裡說的流程並不一定指的是資料流圖，還可能是狀態遷移、用例圖等等，反正就是最粗略的東西，只要能夠理解需求就能夠說出來的東西。例如，我畫的那個流程圖，大家起碼都了解設計的重點和難點在**。
採用隱喻（metaphor）的方法可以形象的找到問題的切入點。我不知道原理到底是什麼，但是當我們找到乙個可以模擬的實際系統之後，我們的思路就開闊和活躍了許多，甚至類的職責都可以通過模擬來確定。例如，我們把收集詞元資訊比作「作坊」，然後再想象作坊內部運作模式，驚奇地發現思路一下就通了。
盡量在一開始就降低類之間的耦合。在設計之初降低耦合往往只是舉手之勞，但是如果最開始沒有理會這樣的問題，那麼到以後再試**耦合則可能會造成極大的代價。例如，如果作坊一開始就需要專門為乙個客戶服務，那麼如果我們需要加入更多使用者就必須改動作坊的內部實現，而且測試的時候也需要假定作坊的客戶是穩定的，實在是不爽。其實為了使類擁有「易測試性」，解耦合是非常必要的。
我們通過今天的開發過程意識到自身設計能力的缺失，我們離「設計師」還有很長很長一段路要走，不過通過總結這些經驗教訓，我們起碼還是在前進。嗯，大家加油！
儘管今天確實得到了乙個看上去不錯的設計，但是誰都吃不準什麼時候會開始第一次重構。能根據設計寫出優質的**才是檢驗設計合理性的方法，寫**的工作就放在明天吧，今天到此為止。
[1] robert c. martin，敏捷軟體開發：原則、模式與實踐，清華大學出版社，2003.9
軟體開發中的理想與現實（引子）
軟體開發實在不應該是乙個令人厭惡的工作，而更應該像一種藝術家的創作，充滿新意和樂趣。可是，我看過不少軟體開發者卻一直在寫另自己都厭惡的 做連自己都不敢正視的測試，最後在專案完成時長嘆一口氣，將自己的成果束之高閣 不敢再碰。造成這種窘境的根源在 是誰讓開發人員做出連自己都感到厭惡的東西？答案是多樣的，...
軟體開發中的理想與現實（十三） 新的培訓即將開始
2月25日是非常值得紀念的，我們花了乙個星期實現了乙個最小的系統。雖然一切的設計還都非常原始，很明顯有不少值得改進的地方，但我們確實已經實現程式的框架，並能夠生成一些小東西了。這真的很令人振奮！大家都從測試先行和迭代開發中嘗到了甜頭，每日會議也不會那麼拘束了，每天都會感覺有所收穫。這種感覺令人著迷，...
軟體開發中的理想與現實（三） 用重構來清掃戰場
2月17日的早晨非常寒冷，就算躲在被子裡也可以清楚地感覺到，不過到實驗室就不會覺得冷了 嗯，有空調就是好啊 所以，我很早就來了。重新檢查大家的 我有種想重寫的衝動 呵呵 不過這正合我意，因為今天的工作就是清掃戰場，做清掃的人當然是大家。首先我把需要修改的內容列一下 在算prime的時候沒有採用最優化...