從17年末到18年初花了差不多三周的時間，將項目中最重要的模塊之一--國際化資源管理，進行了徹底的重構。在掉了無數頭髮加了好多個晚上的班之後，終於改變了先前一個service解決所有邏輯的臃腫情況，代碼的可讀性，擴展性，模塊功能的擴展性以及可用性等性能獲得了很大的提升。我在這次重構中有著許許多多的思 ...
從17年末到18年初花了差不多三周的時間，將項目中最重要的模塊之一--國際化資源管理，進行了徹底的重構。在掉了無數頭髮加了好多個晚上的班之後，終於改變了先前一個service解決所有邏輯的臃腫情況，代碼的可讀性，擴展性，模塊功能的擴展性以及可用性等性能獲得了很大的提升。我在這次重構中有著許許多多的思考和嘗試， 對於一個工作經驗僅有一年的人來說是一個不小的挑戰。最終項目完成並上線之後，自己對於工作結果還挺滿意的，從中也收穫了很多很多，不寫點總結就有點對不起自己過去三周的辛勞了。
先說說背景。在國際化管理的模塊，資源被分為多個類型，每個類型有特定的管理方式。每一類型下的單個對象（即頁面上展示出的一條記錄），底下會包括一個或多個文件名，每一個文件名其實對應著多個文件，即單一文件名下有多個語言文件，這些文件可以理解為文件名在某種語言下的資源，例如文件A.json，底下有中文的A.json，英文的A.json等等。所有的A.json語言不同，但是共用同一套key，即相同的Key對應不同的語言的翻譯，組成了不同的語言文件。一個對象的code-文件名-語言，定位出一個唯一的文件。資源管理，以單個文件為維度。
在重構之前，有過一次業務擴展，在json文件的管理方式之外增加了excel管理。excel按資源類型劃分文件，又按code劃分sheet，再一個一個文件排列成行，列的維度對應各個語言。
原先的代碼都是串列執行，一個一個的workbook創建，每個類型一個方法，流執行，最後將所有的workbook一個一個的寫到文件里去，再壓縮成zip，最後前端下載。數據量大時文件的生成速度偏慢，頁面需要等待較長時間，用戶體驗很差。導入也一樣，一個一個文件，一個個sheet，一行行地解析，解析後重新生成全部的json文件並上傳到文件伺服器，造成了極大的性能問題。除了性能問題之外，所有的代碼都在一個service中，閱讀，維護起來極為困難。幾千行的service包含了導出以及導入時的excel解析等所有邏輯。一個小小的需求改動會引發大量的代碼修改，而且難於測試，經常出現改了東邊錯了西邊的情況。
要是這樣也還罷了，因為在繁忙的日常版本迭代開發和維護工作中很難抽出時間和精力去重構這一塊，勉強能用就先湊合著。當新需求來的時候我徹底傻眼了，新需求要求校對團隊和翻譯團隊導出時，excel的格式加以區別，並且導入時的處理邏輯也不一樣。同時將全局中相同的中文去重（因為翻譯按字收費，這樣能節約不少開支）。原先的代碼對於兩種導出所生成的excel格式一樣所以代碼寫在了一起，導致新版本中這些代碼幾乎不能復用。不重構的話再有新需求來，只會加大修改的時間成本和人力成本，長此以往容易造成我的抑鬱。這其中也是有一點巧合，最近正好在看設計模式和一本著名的書叫《重構》。以前上學的時候也看過設計模式，當時覺得極為抽象，不知所云，看完就忘。如今帶著困惑再去翻閱，有一種茅塞頓開的敞亮。很多設計模式對於代碼的抽象正是項目中所需要的。於是下定決心對模塊進行完整的重構。
首先做的事是資源入庫，每一個文件的每一個key為一條記錄，全部轉移到資料庫表中進行管理，於是不同的業務場景只需要使用不同的sql查找出記錄，再對找出的資源對象的集合進行整理，封裝，業務導出形式的擴展變得簡單。
再聊聊重構中用到的設計模式，或者說我以為我用到了的設計模式以及我的理解。
生成器模式：將複雜對象的構造與表現分離，構建過程可以創建不同的表示。
生成器模式在Mybatis中被大量使用，使得代碼表現得極為簡潔，多個對象的構造被一個導演對象封裝後，調用方只需要一行代碼即可完成，閱讀起來結構極為清晰。
在項目中，每一個sheet的內容構造是相對一致，可以抽象的。翻譯導出和校對導出分別實現了各自的構建器Builder，定義了一個param用於封裝所獲取的資源對象的集合以及sheet和excel樣式等等信息，構建器新建，傳入資源集合，資源的重整理，資源寫入sheet，在service中只顯示為一行代碼，new Builder(param).init().createCells()。極大的減小了service的體積，將具體的實現轉移到構建器中去
工廠模式：所有的類由同一個工廠來生成，將所有的類解耦，並且封裝了實現，分離了對象的構造方和使用方，構造過程擴展不需要去修改使用方的代碼。
傳入導出的類型，excel構建器統一在工廠中生成，多種構建器Builder均繼承自同一基類ExcelBuilder，在service中無需關心所獲取的具體對象，使用父類抽象即可完成調用，若builder再擴展出第三中，也無需修改service中的代碼，只需要修改工廠中的構建過程即可。
策略模式：定義一系列的演算法(策略)，這些策略所完成的工作相同，只是提供了不同的實現。
實際上不論是校對導出還是翻譯導出，都可以抽象為對於數據集的不同操作形式。基於這樣的一點啟發，我才將文件資源入庫，將資源管理轉為對資源對象的管理，在不同的builder中提供不同的實現。
