這兩天，看了《Thinking in Java》的兩章：異常和方法學，以及附錄B，有一點點小體會。

關於異常，一直都沒怎麼用，貌似就沒這個概念～～  555  或許還得構建的自己的一套異常系統，所以，一直總是想想而已，沒有真正的實踐起來～

方法學和附錄B，最想說的是：

1，讓系統跑起來

2，用程式碼證明或者反駁你的設計

這兩條相當的實用，可以奉為聖經！！！

1，再好的設計，如果系統執行不起來，也是白搭

2，很多時候總是紙上談兵，交流辯論必不可少，但，只有真正把想法實現為程式碼，才能知道正確與否！一位偉人說過：“沒有調查就沒有發言權”，說的就是這個道理！

結合最近的一個專案，對書中方法中提到的6個階段，也小有體會

階段0：制定計劃

階段1：做什麼？

階段2：如何構建？

階段3：構建系統核心

階段4：迭代用例

階段5：演化

Bruce把軟體開OOP的開發過程總結為以上幾個階段，由於我水平有限，對於這幾個階段，我更多的是一個迭代的過程：

階段1：做什麼？ 對於這個階段，我理解為需求分析，雖然我很努力的做需求，可是，總是覺得缺什麼，在開始編碼的時候可以發現，這時，我只能從編碼中回來理解需求。

階段2：如何構建？類設計。和需求一樣，我也很努力的根據需求進行分析，設計類。可是，或許這是我專案中最失敗的地方，真正編碼的時候，發現缺了好多好多的類。。。。

階段3：構建核心系統。我的理解為，構建系統的工作流程。現在的我，也是這麼開始執行。根據需求，先把系統的框架搭建出來，一步一步的滿足需求和細化。

階段4：迭代用例。這個我必須得這麼做，或許全部用例我都得“迭代”。

階段5：演化，我把這個理解為對程式碼重構。

階段3是我現在的根本，按照系統的框架不斷的進行重構，對我來說，或許是我現在最好的開發方法。

關於但願你測試：

Bruce說道，“如果寫不出測試，說明類的功能不明確”，非常同意。我確實是對類的職責劃分和協作，沒有明確的想法。

書中還說道，“首先構建測試系統”，這個雖然一直都想這麼做，可是，沒辦法，實在做不出來。

雖然如此，但是，這次的專案中，我還是加入單元測試，哪怕是在程式碼出來的時候加入。

以上是我的一點點體會，歡迎大家吐槽～～