編輯導語：在互聯網的高速發展下，很多傳統企業的舊系統已經跟不上時代的發展，重構系統可以說是勢在必行。本篇文章作者分享了在舊系統重構路上的經驗與反思，一起來學習一下吧。

隨著互聯網技術的飛速發展，開發語言和技術架構的不斷創新。

有許多傳統企業的老系統需要推倒重來，迎合新時代的發展，向信息化、數字化和智能化轉型。

這幾年微服務架構和中臺架構的興起，有許多傳統企業所使用的系統還是十幾年前的單體架構，功能通常聚集在一個系統上，功能繁雜混亂，導致新功能開發上受到限制。

性能上也會遇到瓶頸，這些問題都將影響到業務的發展，所以重構是勢在必行。

有幸這幾年我參加過幾個舊系統的重構，有的項目從頭到尾跟進負責，有的項目是中途才加入，項目有大有小。

接下來通過幾篇文章來分享一下重構路上的經驗和反思，主要以內部系統的重構為主，希望對大家有所幫助。

重構，也就是重做。這對于產品研發團隊，甚至運營，各個系統的用戶來說簡直是噩夢，這相當于所有的東西都需要重頭開始。

所以在重構開始前我們需要弄清楚為什么需要重構？

一、為什么需要重構？

1）舊系統的開發語言或框架不再維護和更新，一些由底層技術或框架引起的問題無法修復，特別是影響到核心功能。

2）老板、高層領導和業務方有各種各樣的新需求，但因舊系統的技術受限而難以實現。

新業務或功能通過舊系統的技術和框架無法實現，或者開發起來難度較高，耗費時間較長。如果繼續在舊系統開發可能無法達到預期，并且投入的成本會較高。

3）系統遇到性能瓶頸，因為舊系統的底層技術和框架問題，難以再進行優化。

像電商系統，當做促銷活動時，如618、雙十一等活動，并發量較大，超出了平時的流量甚至翻倍，那就可能導致系統無法承載。

這時候只能通過增加服務器來臨時解決。要把問題從根源上解決除非能優化現有的代碼，不然就只能通過重構來解決。

4）舊系統的功能需求和交互體驗上不能滿足用戶的使用，甚至會導致用戶降低工作效率。

5）有些公司在剛成立，或者剛開始啟動一個新項目的時候，業務和產品缺乏體系化的規劃。

為了盡快投入使用，追求快速、簡單、高效的落地，經常在收到一個業務方需求的時候只是簡單判斷就開始設計并開發落地。

為了追求速度，沒有在前期做好充足的準備，導致產品缺少足夠的可擴展性，當用戶需求在未來升級迭代的時候，現有的底層設計就沒有辦法跟上業務的發展。

最終導致重構的出現。這也是許多小公司不斷做大后無法避免的，畢竟互聯網時代都是小步快跑，在一開始無法面面俱到。

總結

其實總結起來主要是舊系統的技術和框架阻礙了業務的發展，特別是影響到業務部門的銷售額、產能和工作效率等的因素。

所以這時候我們就需要通過重構，重新整理各個系統的功能和職責，用適合公司的新技術來搭建新的系統。

通過新的系統來滿足各用戶的需求，讓業務跑得更快，提升各個崗位的工作效率。

雖然我們已經知道重構是勢在必行，但也不能老板一拍板就立馬去干，我們需要做足充分的準備和整體的規劃，這樣重構之路才會走得更順暢。

那接下來就說說我們的準備工作。

二、開始準備工作

企業為什么需要對現有系統進行重構，老板聽完之后可能已經寵寵欲動，想立馬就開工。

讓大家能夠盡快使用，工作效率和業績都提升起來。

但這時候我們需要按住老板激昂的情緒，因為在開工前還有許多東西需要考慮清楚和準備，不能盲目開工。

1. 梳理需要重構的系統

首先我們需要明確重構的系統，梳理清楚到底有多少個系統需要進行重構，因為系統的多少將直接影響到整個重構項目需要的時間和人力。

所以我們要梳理清楚是少部分幾個系統，還是公司的整個業務線相關的系統都需要重構。

公司在不斷發展的同時，業務也在不斷拓展，有些新系統是最近才開發完成的，在開發語言和技術框架上可能已經用上了最新、最流行的東西，那這些系統就可以考慮不用再去重構。

但有可能在重構的過程中，這些系統同樣需要對接口、數據庫等改動，所以對應的開發人員也要有這個準備，去配合整個重構的項目。

2. 與用戶表達愿景

明確了需要重構的系統后我們就要與相關系統的用戶表達重構后的愿景，這是非常重要的一步，因為他們是重構后的受益者。

不管是可以給他們提高工作效率，還是提高他們的銷售額、提高他們的業績，都要給他們一個美好的愿景。

這樣做的目的是讓他們有一個共識，公司或部門將要做的事情，大家一起朝著同一個目標去努力，這樣他們才會在后續的工作中更愿意幫助我們，更好的開展后續的工作。

3. 找到系統干系人，梳理每個功能

需要重構的系統清晰了，與用戶也表達了愿景。

接下來就是梳理每個系統里面的功能，這時候再一一與不同功能的用戶溝通收集資料就順暢多了。

產品可以與開發、測試先將各個系統里面的功能都清晰羅列出來，可以通過excel或者思維導圖列出，然后找對應系統的用戶去統計整理哪些功能正在使用，哪些功能已經不用了。

這一步將是漫長的過程，要看系統包括的功能多少，還有涉及不同崗位的用戶有多少，對于每個功能都要有一個初步的了解。

有一點需要注意的是一些少用的功能，對于用戶來說他們不是不去用。

而是在特定的時候或場景才會使用，這些功能在重構的時候也是需要去完成，所以這些功能也不可缺少。

4. 排列優先級

把系統和功能點都明確下來后，我們就需要討論優先級的問題，還有再次明確哪些功能需要完成。

如果需要重構的系統和功能比較多的時候，在原型設計、開發和測試的工作量就會相應較多，所使用的時間也會較長，最后導致的就是系統遲遲不能上線使用。

為了重構后的新系統能夠盡快上線，我們需要對功能進行優先級排列，哪些功能可以延后開發，哪些功能可以砍掉或者放在后續版本迭代時完成的，我們把重要緊急的先完成。

這就要通過組織主要干系人進行討論，這時候可以繼續細化我們的excel或者思維導圖，一起對所列出的功能標記重要性和優先級。

對于一個比較大的系統進行重構的時候不同崗位的用戶都會想著把自己的功能能夠做到盡善盡美，但因為涉及的時間和人力比較多，就需要對系統的功能進行優先級劃分，這樣我們才能根據優先級來進行排期開發。雖然我們不能滿足所有用戶的需求，但我們在做每一步的時候都需要衡量不同崗位的需求，做出一個平衡，不能偏向于某一個崗位的用戶。

到這里我們可以總結出一份需要重構的系統和功能細分的文檔了，這時候我們就需要與用戶達成共識，一起去維護這份文檔，最好是能夠做成內部的共享文件，當有什么變動時大家都能知道，也能避免重構后用戶驗收時發現某個功能沒有了的問題。

5. 開發時間和人力的預估

在系統和功能點都明確下來后，我們就可以給開發一個初步的重構方案，讓他們可以評估出一個時間和需要的人力。因為涉及多個系統的重構，負責開發的人員有所不同，需要他們彼此之間協作開發，什么時候可以完成對應的功能，之后進行系統間的對接、聯調，這些都需要一定的開發時間，評估時需要一并加入。

對于舊系統的重構最好由原開發團隊成員來牽頭，因為里面的一些功能和流程由他們負責開發，他們比較熟悉里面的業務和流程，開發起來會更加順暢，能夠節省一定時間。

因為需求文檔、原型、UI界面等還沒輸出，所以這時候的評估都只是基于舊功能來進行。但我們可以通過評估給領導們一個大概時間，讓他們心里有個底，如果在項目進行中需要增加人員，可以快速進行內部的人員調整或者啟動招聘工作。

6. 明確目標，減少改動

在軟件開發的過程中，有變動是在所難免的，畢竟一開始不可能把所有東西都想得清楚，需要在項目不斷推進的過程中去優化、完善。

但我們在重構開始前就要明確大的方向，盡可能在項目啟動后避免大功能的改動，不然開發到一半或接近完成的功能被喊停，這將打擊許多人的信心。

如我們之前確定重構的功能，不能因為項目的時間緊迫而不經過討論就砍掉某個功能。因為這有可能對使用該功能的用戶無法開展工作，或者需要用其他方法去操作，這有可能不僅沒有提高效率，反而降低效率。

當我們對所列出的功能優先級列表有變動時，需要與對應用戶進行溝通，再深入分析該功能的作用，涉及的業務流程。是否有簡化的可能，能否有其他替代方案。

所以要提前訂立一個改動的機制和流程，下達到每個人員，當出現變動時需要怎么操作，通知到相關人員。

7. 制定必要流程

在項目啟動前需要制定一系列的流程，每一步到哪里需要進行些什么需要知會哪些人、哪個人負責、怎么進行匯報，這些流程的制定都是非常重要的。

如每天的早會、每周、每個月的定期匯報，這樣能讓全部人員都知道當前項目的進度，自己的責任，同事間遇到哪些問題需要幫忙，有什么難題大家可以一起配合解決的。

重構對于企業內部是一個較大的項目，特別涉及多個系統，會有不同的開發團隊、不同崗位的人員參與。

所以讓大家都清楚項目進度，這樣才能更好的朝著最終的目標努力。

雖然我們把許多東西都考慮清楚，但在項目進行的過程中肯定會出現許許多多大大小小的變卦。

最重要的還是需要大家達成共識，讓大家都能清楚自己的責任和需要配合的地方。

準備的工作說完了，下一篇將會分享一下技術相關的。

本文由@淳晨風 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash， 基于CC0協議。