《敏捷軟件開發》讀書筆記（4）
氣象站系統的實踐
-
開始，先分析需求、用例，確定計劃。根據具體的需求和非功能性的需求，選取開發語言，準備開始軟件設計。
-
軟件設計，考慮優先解除對界面的依賴，用OBSERVER模式，創建一個ADAPTER作爲觀察者，收到數據後去刷新界面。
-
再考慮如何解除對傳感器修改的依賴，因爲Schedule主要是要耦合不同傳感器的觸發週期，那就單獨把觸發週期抽象一個觸發器，由傳感器實現，告訴Schedule在某個時間喚醒自己即可，這樣Schdule就只完成了一件工作，符合SRP原則。
-
考慮如何創建一套獨立的API，和現有系統隔離，利用BRIDGE模式把硬件API從現有系統提取出來，把實現和抽象分離。
-
分離這些對象的實現後，創建對象的代碼非常繁雜，再利用FACTORY模式把創建過程封裝起來，進一步隔離實現類，把相關的實現類放在一起處理。
-
進一步把平臺實現類的創建過程封裝到工廠類中，只需要替換一行代碼，就可以切換到另一個平臺。
-
接下來拆分包，對軟件的幾個部分分別進行發佈和分發，把UI從Station解耦出來，由主程序分別初始化。
-
進一步解除UI和具體實現的依賴，把添加監聽的部分，抽象出接口類，讓UI依賴接口，系統實現接口，進一步解除耦合。
-
在監控之餘實現數據持久化和相關策略計算邏輯，還是利用OBSERVER，監聽變化和時鐘，並且將通用算法分離出去。
-
進一步解除策略和具體持久化實現的耦合，利用PROXY模式，在PROXY裏調用持久化，把具體策略封裝到另外的類中去調用，使其滿足SRP。
-
再利用FACTORY把具體的創建對象封裝起來，而如何解決持久化層需要依賴策略層的問題？這裏用了一個靜態引用來存儲工廠類的實現實例。（疑問，由app層，把機制的抽象傳進去，不就可以了？）
-
考慮要不要再次利用工廠解除算法策略和代理類之間的依賴？需求認爲到這裏就足夠了。
ETS框架實踐
項目過程回顧
在開始就單獨創建框架是失敗的，試圖拋棄真實需求創建一個可重用的框架，是無法滿足需求的。作者捨棄了原有的方案，改爲了在開發框架的同時，並行開發4個需求，如果在過程中發現相似的部分，只有應用於超過4個需求的代碼，才允許出現在框架中。（平臺化也是這個思路，只有超過幾個業務同時使用的代碼，纔可作爲平臺層來構建）最終框架的複用能力，在後期提供了強大的開發效率，並且設計沒有被打破，經受住了需求的劇烈變化。
框架設計
-
利用TEMPLETE METHOD模式，把評分的遍歷邏輯放到了基類，評分核心差異交給子類處理。
-
利用STATE模式，設計畫圖界面的命令區和繪圖區的交互，接收鼠標和命令區按鈕點擊事件，轉換爲事件和設置狀態的動作。
-
最後創建了一個TASKMASTER框架，用來管理諸多的任務實現，每個任務都是一個小的FSM完成一組操作。
整個ETS是很大的一個系統，其中用到的策略，做的取捨，都值得在日常工作中學習。
全本總結
- 架構是由需求驅動，在設計的過程中的一切權衡，都是因爲需求導致。
- 依賴抽象總是好的，分離邏輯和調用、分離算法和控制，就形成了各種各樣的模式。
- 敏捷再敏捷，結尾的小故事和小品，真實的呈現了敏捷開發和交付的實踐方式，頻繁和需求交流，並且大家都關注與最核心的部分。