前話
這裏主要是想記錄一下自己的想法，以及一些設計思想，然後在實際開發過程中，是否會遇到一些自己所想不到的事情，以及怎麼的解決過程。事實上，寫這種文章，遠比寫技術性的文章難多了，個人感覺還很難寫好。這裏寫也僅是自己的觀點，一種想法和思考，不代表完全正確，共勉而已。
一、開發背景
兩款ARPG遊戲，一款相對簡單一些，偏掛機的ARPG遊戲，另外一款是比較類似傳統的ARPG頁遊。跟傳統的項目換皮再上線還是有比較的的區別的。
1. 確定戰鬥系統的機制是一致的，其他細節的功能會有所區別
2. 已有AS3的回合制以及ARPG項目和相關開發經驗
3. 多頁遊積累的相關工具以及流程
4. H5的arpg demo已經實現了基本的角色、地圖和基礎簡單的戰鬥系統（前期做的技術預研）
5. 幾乎要重新開發全部客戶端Html5的代碼（基於TypeScript，但可移植部分之前AS3代碼）
6. 服務端相對好點，上個頁遊也是用Java寫的，所以服務端可以進行比較好的遷移。
二、兩項目之間複用代碼的設計思考
由於幾乎是同時開發兩個類似項目，又沒有一個比較接近項目進行換皮。再者項目開發進度也緊，人力也有限。爲了最大限度提高開發項目效率，節省資源。對兩個項目進行整合，儘量複用代碼，最好也最快的解決方案。下面是一些考慮執行的方案。
基礎通用設計
最基礎的，和具體的業務邏輯沒有關係的代碼和設計放到這裏，不用考慮和糾結的。基礎也大量移植原有AS3的代碼，在穩定性和實用性都有一定的保障。
非代碼類
1. 保持代碼結構一致（代碼包名等等）
2. 保持遊戲資源目錄結構一致（ui、場景、角色、物品等等）
3. 保持動畫格式、ui編輯、動作編輯器等工具保持一致
4. 保持各種目錄結構、ftp、持續集成服務器一致
5. 其他開發流程，相關規則保持一致
6. 項目配置、編譯參數、編譯工具(Egret Wing IntelliJ IDEA)
7. 通訊協議、策劃數據儘量採取類似或者通用的方案
具體的版本管理圖:
代碼庫
1. 自研基礎代碼庫（通用類、工具類、mvc框架類……）主要移植和編寫基礎代碼，跟具體的遊戲類型沒有關係的通用邏輯代碼。
2. 第三方代碼庫（Json，MsgPack等等……）
3. 遊戲引擎包（場景、地圖、角色體系……）這裏算是指定是開發遊戲用的，但是這裏還是根據可以做到不跟具體遊戲類型。保留通用的遊戲機制的代碼庫。
4. 戰鬥系統。戰鬥系統是引用前面3條的代碼庫，這裏做得只能是arpg的戰鬥系統。這裏會處理兩個項目通用的戰鬥邏輯。以及面向接口開發，部分具體的實現是在不同的項目裏開發的。
項目代碼設計
1. 通過基礎庫和core庫的分離設計，項目集中在寫自己的項目，core庫不能引用具體的項目代碼
2. UI佈局和邏輯分開。每個項目UI佈局肯定不一樣，但是部分邏輯是通用的，所以重點是這方面的設計。提取出公共的UI接口，然後項目分別實現。根據項目類型來不處理某些接口（單個項目獨有），如圖：
會有專門存放接口的包名(其實應該放在core裏，然後實現類放在具體的項目)，UI結構示意圖
UI的接口和實現
另外一種情況，就是UI功能變化比較大的時候如何處理呢？假如有一半一樣一半不一樣
這裏可以採用共享LoginView基類了，在這裏處理公共邏輯，具體的子類處理不同的UI邏輯。如果要更多的
重用，就得把基類的粒度做得更加細一些，當然做太多其實反而是浪費精力，應該根據項目具體的情況來決定使用什麼的設計技術。
3. 功能模塊之間採用事件派發，這樣只需要處理事件，不具體處理項目，可以做到邏輯共享了。 這裏分幾種事件機制：core事件、cmd事件、mvc事件，項目獨有事件。做了細緻的分離，根據不同的功能使用不同的事件，提高開發和運行效率。
非技術方面
1. 兩個項目都會指定負責人，希望項目進度和管理能夠及時跟進
2. 兩個項目的開發人員會交叉開發，類似和相同的功能模塊，儘量同一個人開發，節省人力資源
比如揹包、登錄、創角、聊天等一些功能。
3. core庫只能有1，2個人才能維護，其他人只有使用權，沒有修改和提交權。不同項目還會開分支，同步到主幹之後，還需要兩邊項目都調通。
4. 策劃層會也會盡量溝通，除去玩法之外的一些功能模塊，也會互相探討，儘量做到至少是在數據結構上可以保持一致。比如技能、地圖、角色設置等一些通用的設置
三、實踐
剛開始基本上是按照前面的設計來進行的。掛機類aprg（見現在到處跑的傳奇世界H5類型）先進行開發了半個月，所以這半個月首先是開發一些最基礎和最通用的功能，同時也是完善角色場景以及戰鬥體系。
先做基礎功能主要也是爲了第二個項目也能夠使用這些開發好的模塊。
半月後同時進行第二個項目，剛開始其實還是蠻順利，大部分也按照開始的設計來進行。只是後來因爲項目原因，工作量也大，開始出現了一些問題了。比如因爲項目趕，有部分功能沒考慮設計，使用了簡單粗暴的移植法。雖然快速做好了，但是有bug的時候，就必須在兩個之間進行修復了。
另外就是core庫的戰鬥系統設計得不夠嚴謹，會修改得比較多，一不小心就會造成另外的項目跑不起來了。
所以在一些系統穩定前，總會踩下這些坑，得小心翼翼了。
人員的不足，不是每個模塊都能按照之前設計那樣，兩個類似的模塊同一個人維護，所以有時難免要維護或者移植別人開發的模塊。
後面也是有陸續根據項目的具體情況調整一些方案，以及陸續補充core庫的代碼。
四、後記
其實這blog的內容一個多月前就開始了，結果直到現在纔算是勉強寫好。雙開的結果就是連寫blog的時間都沒有，一天至少是當1天半來使用，寫這個文章的熱情也淡下來了。好在之前也寫得差不多了，現在也沒做太大的修改，有些設計和想法還是挺好的，在實踐中也得到驗證。總體有這種想法和設計，對於團隊後面的工作展開還是有很大幫助的。
最後團隊這種高壓下，進步也是挺大的。同時也看到了團隊強大的應變能力以及開發能力。
雙開的很多的，發現真的很難用一些言語來描述，跟換皮做項目是兩回事。不過總體還算順利，雖然有些坑，不過也後續中慢慢填補上來，尤其是招到了足夠的人手後，很多問題都得以解決了。