前言
本文主要記錄，剛剛步入架構師崗位4個月的我，重構項目的一些經歷。
項目重構的過程
重構項目這件事，最重要的其實是心態，只要心態良好，這事兒十有八九能干成。
因為，我們要面對困難，往往並不僅僅是代碼。比如，你在項目重構開始后，發現，重構項目組只剩你一個人。。。
01熟悉表結構
對於這一次重構的項目，我還是比較陌生的，因為我也是剛剛介入該項目，並且趕在了項目交付期，雖然做了一些功能，但由於團隊成員都很忙，我的工作也很急，所以我連數據庫的表結構都很陌生。所以，當項目重構啟動后，我的第一個任務就是熟悉表結構。
熟悉表結構，是我遇到的第一個難題，首先，經過調查，表結構的相關文檔已經過時了，近一半的表結構都沒有記錄，其次，開發人員經歷幾輪換血，很多重要的表，大家都不敢給出篤定的描述。
但重構還是要繼續，於是，我就在這樣的情況下，開始了一個陌生項目的重構之旅。
02從項目的Main函數打開突破口
當下的項目沒有業務專家的，這意味着，我必須成為業務專家，不然的話，項目就必然無法重建，如何成為業務專家？很簡單，重寫代碼；因為代碼是最好的系統說明書，從Main函數開始，一個功能一個功能的重寫。
每重寫一個頁面，我就對系統多了解一點，然后在拿着我掌握的信息，找現有的項目成員核對，一點一點，積少成多。
當然了，重寫項目頁面，必須要保證速度，如果速度不夠，那么代碼以外的問題會越來多。
如何保證速度？很簡單，首先把自己順手的框架拿出來，封裝好表格控件、圖表控件等常用；搭建好CS客戶端與服務的基礎溝通，做好ORM，剩下的就是把業務模塊一個一個的搬運過來。然后，邊移植功能，邊做文檔描述；因為當下移植的功能很可能是錯誤的，當下的表結構很可能是錯誤的，所以，文檔記錄非常重要。
03基礎功能與OA功能
通過堅持不懈的功能搬運，我終於完全掌握了系統中重要的表，然后，我開始閱讀歷史項目的合同，和尋找面對面與客戶溝通機會，將系統中無人使用的、非客戶要求的、我們自認為特色的冗余功能剔除。最后，我成功的將系統重新划分為基礎功能和OA功能兩大模塊。
04領域驅動
因為有多年的領域驅動開發與設計經驗，所以我深刻的知道，領域驅動在分析業務時是一把利劍，但在代碼實現時，是一把雙刃劍；因為，項目畢竟不可能永遠是我一個人開發，所以，我基於項目成員水平、學習意願、客戶需求修改頻率等等因素，采用了半領域驅動設計模式，重新更新框架，其目的在於更快速、更高效，雖然不能傷敵一千，但也避免了自損八百的風險。
05重設計表
重構的過程中，最痛苦的就是表歧義，比如班級類型表，實際存儲的是學生分類信息。。。因為，入手該項目時，我是相對陌生的，所以，每當遇到有表歧義的功能時，我必須在腦海中先搭建一個映射，反復的確認后才能下手編碼。如果歧義只有一兩張表，那還好，如果歧義表很多，那真的，很痛苦。這也是我決心重設計表的主要原因。當然了，優化表結構也很重要，不過，因為已經對業務進行了拆分，所以表結構優化已經是水到渠成的事了，已經不再是難題了。
06成員加入
至此，基建工作已經全部完成了，項目核心功能已經搭建完畢，項目重獲新生，雖然還有剩余基礎功能待擴展和部分OA功能待移植，但已經達到基礎展示的水平了，於是，新項目替代了舊項目，正式為新客戶服務，舊項目組成員也逐漸進入新項目組。
結語
----------------------------------------------------------
注：此文章為原創，任何形式的轉載都請聯系作者獲得授權並注明出處！
若您覺得這篇文章還不錯，請點擊下方的【推薦】，非常感謝！
https://www.cnblogs.com/kiba/p/13467704.html
