最近重構了id服務，順便來寫個總結。重構的原因無非是兩種：
1. 新增需求不方便，可能會對原有的服務造成不確定的影響
2. 提公升效能
我們現在的服務開始設計的時候並沒有考慮很多，當初只是簡單的想生成唯一的訂單號就行了，所以並沒有進行很好的設計。後來又增加了退款單號，這個也很簡單，請求裡加個cmd，服務裡用if判斷下就行了。然後就又增加了賬戶號、賬戶流水號、銀行流水號等，這個時候就不能再簡單的用if...else...來處理了，這些請求耦合在一起導致新增需求很麻煩，且容易影響其他的功能。重構就是乙個明智的選擇。
經過兩天的考慮我決定採用策略模式+**模式+單例模式來改造這個服務，關係如下：
簡單介紹下：先定義介面基類iprotocoltask，然後為每種型別的請求建立乙個繼承自iprotocoltask的子類，當系統啟動時每個任務類和乙個cmd關聯並註冊進ccommontaskmanager類中。請求到達時根據呼叫gettask(cmd)返回iprotocoltask*，然後多型呼叫excute()。新增功能時只需繼承iprotocoltask類，在excute()虛函式中實現自己的業務，和乙個cmd關聯註冊進ccommontaskmanager即可。最後的單例模式可以讓每個請求到達時無需建立新的物件，節約系統資源。
用壓測指令碼測試後，qps是之前效能的兩倍。
機房重構總結
萬事開頭難，也不知道是哪位大師說的，這次機房的重構讓我深刻的體會到了這句話的含義。剛剛接觸分層，對分層也不理解，照著三層登陸的例項敲乙個登陸出來，然後看著網上的包圖，就想著加乙個抽象工廠，簡直無從下手，不斷的看書，也請教前人。到最後看抽象工廠的設計模式都不用看目錄，直接翻開了。無從下手，不知所措，這...
個人重構總結
從暑假到現在弄了好幾個月終於完成了。最主要的收穫是對物件導向思想的理解。尤其是封裝，我們封裝了連線資料庫的方法 封裝了臨時表轉換成泛型集合的方法。還有就是分層的思想，讓我們的 更靈活，更安全，真正達到高內聚 低耦合。分層思想應該是這個專案讓我們印象最深刻的。從剛開始分三層敲登入，後來把實體層分出來使...
機房重構總結
機房重構這個專案已經完成了，是時候總結一下這段時間的感受。其實按照軟體的生命週期來講，應該是可行性分析 專案開發計畫 需求分析 概要設計 詳細設計 編碼 測試 維護這個流程的。之前已經做過第一遍機房收費系統了，所以有些步驟就省略了，這次先是自己設計的資料庫，然後就開始編碼，之後開始測試，最後找 驗收...