記一次項目重構

前言

本文主要記錄，剛剛步入架構師崗位4個月的我，重構項目的一些經歷。

項目重構的過程

重構項目這件事，最重要的實際上是心態，只要心態良好，這事兒十有八九能幹成。

由於，咱們要面對困難，每每並不只僅是代碼。好比，你在項目重構開始後，發現，重構項目組只剩你一我的。。。

01熟悉表結構

對於這一次重構的項目，我仍是比較陌生的，由於我也是剛剛介入該項目，而且趕在了項目交付期，雖然作了一些功能，但因爲團隊成員都很忙，個人工做也很急，因此我連數據庫的表結構都很陌生。因此，當項目重構啓動後，個人第一個任務就是熟悉表結構。

熟悉表結構，是我遇到的第一個難題，首先，通過調查，表結構的相關文檔已通過時了，近一半的表結構都沒有記錄，其次，開發人員經歷幾輪換血，不少重要的表，你們都不敢給出篤定的描述。

但重構仍是要繼續，因而，我就在這樣的狀況下，開始了一個陌生項目的重構之旅。

02從項目的Main函數打開突破口

當下的項目沒有業務專家的，這意味着，我必須成爲業務專家，否則的話，項目就必然沒法重建，如何成爲業務專家？很簡單，重寫代碼；由於代碼是最好的系統說明書，從Main函數開始，一個功能一個功能的重寫。

每重寫一個頁面，我就對系統多瞭解一點，而後在拿着我掌握的信息，找現有的項目成員覈對，一點一點，聚沙成塔。

固然了，重寫項目頁面，必需要保證速度，若是速度不夠，那麼代碼之外的問題會越來多。

如何保證速度？很簡單，首先把本身順手的框架拿出來，封裝好表格控件、圖表控件等經常使用；搭建好CS客戶端與服務的基礎溝通，作好ORM，剩下的就是把業務模塊一個一個的搬運過來。而後，邊移植功能，邊作文檔描述；由於當下移植的功能極可能是錯誤的，當下的表結構極可能是錯誤的，因此，文檔記錄很是重要。

03基礎功能與OA功能

經過堅持不懈的功能搬運，我終於徹底掌握了系統中重要的表，而後，我開始閱讀歷史項目的合同，和尋找面對面與客戶溝通機會，將系統中無人使用的、非客戶要求的、咱們自認爲特點的冗餘功能剔除。最後，我成功的將系統從新劃分爲基礎功能和OA功能兩大模塊。

04領域驅動

由於有多年的領域驅動開發與設計經驗，因此我深入的知道，領域驅動在分析業務時是一把利劍，但在代碼實現時，是一把雙刃劍；由於，項目畢竟不可能永遠是我一我的開發，因此，我基於項目成員水平、學習意願、客戶需求修改頻率等等因素，採用了半領域驅動設計模式，從新更新框架，其目的在於更快速、更高效，雖然不能傷敵一千，但也避免了自損八百的風險。

05重設計表

重構的過程當中，最痛苦的就是表歧義，好比班級類型表，實際存儲的是學生分類信息。。。由於，入手該項目時，我是相對陌生的，因此，每當遇到有表歧義的功能時，我必須在腦海中先搭建一個映射，反覆的確認後才能下手編碼。若是歧義只有一兩張表，那還好，若是歧義表不少，那真的，很痛苦。這也是我決心重設計表的主要緣由。固然了，優化表結構也很重要，不過，由於已經對業務進行了拆分，因此表結構優化已是水到渠成的事了，已經再也不是難題了。

06成員加入

至此，基建工做已經所有完成了，項目核心功能已經搭建完畢，項目重獲新生，雖然還有剩餘基礎功能待擴展和部分OA功能待移植，但已經達到基礎展現的水平了，因而，新項目替代了舊項目，正式爲新客戶服務，舊項目組成員也逐漸進入新項目組。

結語

一我的的重構項目和團隊重構項目是徹底不一樣的，一我的重構項目是否成功，和我的平時的積累密切相關，必須作到全程代碼無開發，從ORM到UI控件乃至外部硬件設備協議封裝都必須能搬運，若是有一項未積累到，須要查資料寫Demo測試，那不只進度沒法保證、自身狀態也會被打亂，屆時，外部因素一旦介入，可否成功重建就是個未知數了。

----------------------------------------------------------

注：此文章爲原創，任何形式的轉載都請聯繫做者得到受權並註明出處！
若您以爲這篇文章還不錯，請點擊下方的【推薦】，很是感謝！

http://www.javashuo.com/article/p-zoershgx-mz.html