看《Thinking in Java》的一點點總結
這兩天,看了《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說道,“如果寫不出測試,說明類的功能不明確”,非常同意。我確實是對類的職責劃分和協作,沒有明確的想法。
書中還說道,“首先構建測試系統”,這個雖然一直都想這麼做,可是,沒辦法,實在做不出來。
雖然如此,但是,這次的專案中,我還是加入單元測試,哪怕是在程式碼出來的時候加入。
以上是我的一點點體會,歡迎大家吐槽~~