專案遷移的思考

轉轉_陳龍發表於2019-03-07

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，裡面給每一個頁面都做了個命名，同時註釋標明瞭所有引數意義，呼叫的時候更簡單了，查詢的時候更方便了

    image

// 過去
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表格

image

image

image

表格裡把每一項都羅列清楚，根據原有專案程式碼為每一項估算一個時間

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

比如：按一天早十晚七算，部分人早上會遲到一會，中午要午休一會，晚上完飯散個步等等，實際單日有效時長可能只有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 進度跟進

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

及時更新表格裡的“開發進度”，也讓自己心裡有底

image

  • 白色：表示尚未開始

  • 藍色：表示開發中

  • 綠色：表示已經完成

測試也採用同樣的方式

2.7 測試介入方式

對於大型專案，可以採用分批提測的方式。

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

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

我們就用這種方式最終專案耗時1個月零3天，提前2天上線。

2.8 為什麼用excel，2個原因：

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

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

  • excel大家電腦都有，不用再專門安裝軟體

總之就是這個表格做完可以幫你省很多事

OK，以上就是最近的一些思考，分享給大家，歡迎一起交流

相關文章