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