項目遷移的思考

1 改造背景

在過去的一年裏，咱們作了兩次大的項目改造（項目有大概70個頁面）：

• 一次是由於因爲業務線快速發展，現有的項目從一開始的孵化慢慢演變成轉轉的基礎業務，除了要在小程序運行外，還要在app端運行，須要個h5版本，因而咱們依據原有的mpvue項目新改造了一個vue項目（mpvue說是能夠轉換成h5，可是若是頁面複雜的話根本無法轉換）。

• 另外一次也是由於業務發展愈來愈龐大，咱們和主程序及其餘業務線會有更多的業務融合，同時還有公共庫的複用及更新問題。咱們小程序項目是用mpvue寫的，而主程序和其餘業務線採用的是wepy。每次和其餘業務線有合做時候，咱們都是從新開發，今年因爲公司大方向要作流水，跟其餘業務線合做會愈來愈緊密，爲了避免讓技術棧成爲業務線合做的壁壘，咱們最終決定，將mpvue項目改形成wepy

2 改造心得

通過這兩次大的改造，本身也得出了一些心得，這裏跟你們分享一下：

2.1 在遷移、改造的時候，必定要把項目充分的拆分，越細越好

這塊是整個工程的核心，也是考驗項目負責人對整個項目的熟悉程度

若是哪塊不熟悉必定要找對應的負責人詢問清楚，再不濟本身去看代碼

由於後續全部的開發、項目跟進、測試都是依照這一步產出的「藍圖」爲依據的，作這一部分的時候要尤其耐心，這塊作的細後面的坑就少。

我拆分項目會按照幾大塊來作：

• 原有項目痛點思考

  在以前的項目中確定有一些東西設計的不合理，此次正好是個改正的機會，好比：

  1） ajax返回結果：咱們以前爲了方便不用每一個頁面都處理接口報錯的狀況，是直接返回data，可是有常常有狀況須要根據接口返回的code碼來判斷，因此此次返回的是{code:xxx, data: {...}}形式

  2）新項目引入typescript、採用webpack4

  3）新增了gotoPage.js：原來的小程序直接經過path跳轉，可是頁面多了以後，尤爲路徑攜帶的參數很很差管理，常常pm找我要個活動頁的連接，path好說，主要是參數不知道有哪些，還得現查代碼。因而咱們作了一個gotoPage.js，裏面給每個頁面都作了個命名，同時註釋標明瞭全部參數意義，調用的時候更簡單了，查詢的時候更方便了

  

// 過去
navigateTo({url: URL.setParam('/packageA/pages/activity/publish4RedpackageSuccess/main', {
    channel: 'xxx',
    shareUid: 'xxx',
    fromActiontype: 'xxx'
})})

// 改造後
gotoPage('activityPublish4RedpackageSuccess', {
    channel: 'xxx',
    shareUid: 'xxx',
    fromActiontype: 'xxx'
})
複製代碼

4）其餘改造點...

• 項目搭建

  項目負責人必定要把項目搭建完成，各類npm包，webpack配置等，這是最基礎工做，遷移必須完成

• 公共庫

  公共庫有不少文件能夠直接拷貝過來，最主要的仍是基礎能力的改造，尤爲新老項目中，一些基礎能力不通用的，都要進行改造，同時，老項目基礎庫中哪些須要引入引入公共包也都要羅列出來，好比：

  1）登陸：登陸前置、登陸後置

  2）ajax封裝：這塊是否是須要變動庫（如axios）來處理，接口請求是否須要強制登陸，各類狀態碼處理，以及返回的數據結構

  3）cookie：小程序cookie處理和h5項目cookie處理是不同的，cookie名字變動

  4）支付

  5）圖片上傳

  6）統計上報

  7）h5特有文件

  8）通用業務邏輯的處理

• 通用組件

  全部通用組件，要一一羅列

• 頁面

  頁面這塊主要是要整理哪些頁面已經下線（一般是活動頁面，若是已經下線，就不在本次改造、遷移範圍內，能夠直接減小工做量，下線頁面須要作一個下線提示）

  而後把本次須要遷移的頁面和作下線處理的頁面分別羅列出來

好了，這些都搞定以後，咱們能夠列出一個大的excel表格

表格裏把每一項都羅列清楚，根據原有項目代碼爲每一項估算一個時間

注意： 估算時間這塊，項目負責人要根據組內實際平均單日有效時長作評估。

好比：按一天早十晚七算，部分人早上會遲到一會，中午要午休一會，晚上完飯散個步等等，實際單日有效時長可能只有6小時

固然咱們組的有效時長要高於這個時間，負責人要根據本身組的實際狀況進行評估。（這也是反覆推敲後才能確認的）

敲定每一項的時間後，計算出一個總時長，這裏須要根據實際須要，要額外打必定的buffer時間（我這裏打了10%， 從67.4天最終定爲74天）

2.2 分工上必定要明確

根據上面的excel把每一個人負責的內容明確出來，（原來分方向負責人照舊）

但有一點，是公共部分的分工，必定要明確！！！

好比同一個公共能力或者公共組件，A、B、C三人都用到了，必定明確到底誰作，別小看這個，我第一次改造就吃了這個虧了，一開始你們只作本身那部分，公共部分都等着，最後拖延總體的時間。

人員分工完成以後，並非最終版，還要根據每一個人的投入時間進行二次修改

2.3 人員投入時間上要明確

人員投入上要明確，每一個人在什麼時間點才能投入進來，什麼時間點會請假等等

好比項目組有A、B、C、D、E五人：

• A當即能夠介入，月底請2天假
• B當即能夠介入，不請假
• C後天才能介入，下月初請3天假
• D5天后才能介入，月底請1天假
• E一週以後才能介入，不請假

而後根據每一個人的實際時間對上述表格「負責人」進行修正。

原則：儘可能保證你們在同一時間點結束項目開發。

2.4 對改造初稿進行評審

這別覺得其餘leader不熟悉本身的項目，就認爲這步是多餘的。

通過評審以後，leader們會給出不少建設性意見：

尤爲公共庫和組件庫這塊，哪些能力有，哪些能力須要改造，會溝通的很是清楚（由於公司業務比較龐大，因此有不少的公共庫），對於以前項目裏沒有的能力，若是公共庫支持的話，會很是節省時間，同時還知道這部分是誰負責的，接入時候遇到問題能夠直接找對應負責人。

在這個過程當中也能夠把本身的想法和你們溝通一下，你項目中的部分改進意見沒準也是其餘組須要的。

若是有條件必定拉着你們評審一下。

2.5 上線時間溝通

這一部分尤其重要，在完成上述步驟後，已經能夠大概估算出時間了（一般大項目能夠估算測試時間爲開發時間的一半）

拿咱們此次爲例：

74人/日開發量，37人/日測試量，FE 5人，QA 3人（本次是前端框架遷移，不涉及server端） 估算一下，開發須要18個工做日，QA須要15個工做日，算上週末，大概就是一個半月時間。

經過這個時間同領導和業務方進行溝通，看看這個時間是否可行，若是OK，那沒什麼說的，若是不OK，就要考慮加班了。

在加班也解決不了問題的時候，就得向領導求助了，須要其餘組的支援。

以咱們爲例，咱們最多隻有5周的時間，並且加班也搞不定（由於年末調休，每週要上六天班，再讓你們過來加一天班顯然不合適），因而找領導協調過來一個成員，支援咱們一週。

那麼新來的成員不瞭解業務，他能作什麼呢？

只能給他作業務邏輯相對簡單的頁面，好比：搜索推薦、搜索結果頁、我的主頁等，而後再去調整整個項目的人員分工

2.6 進度跟進

對於大型項目改造，天天要向成員詢問進度，稍不留神拖個幾天很常見

及時更新表格裏的「開發進度」，也讓本身內心有底

• 白色：表示還沒有開始

• 藍色：表示開發中

• 綠色：表示已經完成

測試也採用一樣的方式

2.7 測試介入方式

對於大型項目，能夠採用分批提測的方式。

這樣可讓QA資源最大化利用。

測試中天天要向QA獲取測試進度，獲知bug修改速度，中間有沒有遇到問題。

咱們就用這種方式最終項目耗時1個月零3天，提早2天上線。

2.8 爲何用excel，2個緣由：

• 最主要是：由於框架遷移是技術驅動，寫需求文檔是個功夫活，羅列測試點的時候尤爲的麻煩。

  這個表格列的很細緻，有哪些頁面、功能須要測試一目瞭然，能夠直接發給QA。他們在測試進度那一欄直接分工，同時天天也能夠經過標明不一樣顏色跟蹤進度。

• excel你們電腦都有，不用再專門安裝軟件

總之就是這個表格作完能夠幫你省不少事

OK，以上就是最近的一些思考，分享給你們，歡迎一塊兒交流