聯調我不怕！(一)

（適用範圍：涉及前後端共同產出的項目。文章有些長，但若認真閱讀，應該會有所收穫。）

大多數人認爲，只有前端和後臺套vm的過程纔算聯調，但是很多項目做下來的感受是：這個階段其實不會花費多少成本，大概佔到10%，但是真正的痛苦一直會持續到項目發佈。

從交付到上線，需要"聯調"的階段大概有：

1. 套vm

2. 後臺調試

3. 開發自測

4. 測試

可以說貫穿在demo交付之後的整個流程中。期間有來自各方面的修改、調整，這些帶來了大部分聯調的工作量。

比如，交互功能不明確或demo邏輯錯誤等問題，會在後臺調試過程中一一暴露，帶來修改的工作量。Demo的細節功能（如校驗）做的不到位，會在開發自測甚至測試階段纔會暴露，引起修改。各頁面之間的跳轉邏輯問題，也會在開發自測的時候暴露出來。表單回顯問題的不重視，甚至在後臺調試階段給前端帶來結果邏輯上的重構成本。

目錄：

1、聯調成本到底出在哪裏

2、從交互評審做起

3、前端方案要從多方面進行評估

4、Demo製作要留心

5、聯調階段把控需求變更

6、全文大綱

一、聯調成本到底出在哪裏？

將我們所碰到的問題整理一下，統計出一般項目的聯調成本。

常規成本
1. 指導開發套vm
2. 有需要的情況下，根據真實字段修改demo和數據
意外成本
1. From liD
  1. 需求修改
  2. 需求增加
2. From 交互
  1. 頁面交互漏洞，開發階段發現其不能滿足需求
  2. 交互人員變更導致交互方式變更
  3. 交互優化之前方案導致的變更
3. Form 前端
  1. 前端bug
  2. Demo功能缺失
  3. 前端邏輯漏洞
  4. 前臺數據解析問題
4. From 開發
  1. 後臺數據問題
  2. 前後臺約定有變化
  3. 技術方案變動
    1. 必要性變更最初的分析有問題否則實現不了
    2. 之前的方案後臺難度大，部分工作讓前端分擔
    3. 本身需求有變動
    4. 交互方案有問題不足以滿足需求

所以，聯調成本不能光靠"讓前端書寫vm"這樣的簡單方式處理，應該從項目的各個階段入手，增強對需求和交互稿的理解與把關，從而降低後期聯調的成本。

二、從交互評審做起

前端必須重視交互評審，一個經驗豐富的前端開發，會在這個環節上對交互稿詳細審查和質疑，並提出改進意見。做好這些工作，可以弱化後期聯調中修正工作，降低聯調時間成本和風險。

那麼從那些維度來做交互評審呢？以下這些不僅可以作爲前端的參考，還可以讓交互同學借鑑，把交互稿細化，做的更加專業。

1、對頁面上每一個可以點擊的元素，做交互記錄

表單元素是否觸發校驗
- 普通校驗：必填、長度、正則
- 聯合
- 異步
校驗問題的不確定，會導致demo功能的缺失，會影響並增加開發自測或測試階段的聯調成本，異步校驗的缺失可能在開發調試階段就會被發現，並找前端補充該功能。
頁面鏈接的打開方式
- 內部刷新url
- 瀏覽器新開頁面
鏈接雖然是個小問題，但是大多數交互和前端都是不會注意的，一般都要等到開發調試階段甚至測試階段纔會發現，所以舉手之勞，就回免去後面零零碎碎的聯調成本。
頁面間操作（以下操作可組合出現）
- 新打開tab
- 關閉當前頁面
- 切換到原頁面並刷新
這個問題幾乎所有交互都會忽略，但是會在功能預演或測試時提出，有些較明顯的也要開發調試階段纔會被發現，所以非常有必要在交互評審時就明確該事項，減少聯調成本
打開對話框
- 對話框初始化前（頁面初始化時）
  - 對對話框裏面的控件進行初始化：表格、日曆、聯動選擇等組件
- 對話框初始化動作
  - 對不能在之前初始化的控件進行初始化：kissyEditor
  - 判斷對話框是否已經存在，存在的話不必再次初始化
- 對話框打開時動作
  - 刪除錯誤提示
  - 清空數據
  - 回顯數據
  - 更新內容
- 確認後的動作
  - 異步提交表單
    - 提交前的校驗
    - 增加提交數據
    - 提交後的回調
  - 更新數據
- 對話框關閉時動作
  - 關閉對話框
  打開對話框動作，往往是交互同學比較喜歡的分支操作方式，但是交互稿往往很簡單，只確定了在什麼情況下打開對話框，對話框裏有什麼東西這些基本的東西。但是前端同學在製作是會涉及很多細節問題，這些問題的不確認或缺失會對聯調造成很大改造成本，比如數據回顯、情況等問題會在開發調試甚至測試階段纔會被發現和返工修改。
信息提示框
- 簡單提示框（只有確認按鈕）
  - 確認後的回調
- 確認提示框（有確定、取消按鈕）
  - 確認後的回調
  確認後肯定會有回調，但是回調什麼東西，是很容易忽略的事情，交互、前端、開發的看法若不能統一的話，很容易在開發調試階段引起意外成本。
異步操作（ajax請求）
- 收集提交數據
- 回調
  - 刷新表格
  - 刷新dom
  - 信息提示
收集要提交的數據，往往會在開發調試階段帶來很多零碎的意外成本，所以在交互評審或者制定前後端方案時最好確定下來，避免後期修改。

Ajax的回調都要做一些什麼事情，也是交互同學最容易忽略的事情，往往解釋的很簡單，這裏提供了一些維度，希望前端同學與交互同學確認。
提交表單
- 提交前校驗
- 提交方式
  - 異步提交
    - 收集提交數據
    - 回調
      - 刷新表格
      - 刷新dom
      - 信息提示
  - 同步刷新至成功或失敗頁面
  - 確認後的動作
    - 關閉當前頁
    - 打開新頁面
    - 切換至源頁面並刷新
  提交前的校驗很容易被忽略，直到開發調試或自測是測會被發現，因爲如果某些值不校驗，提交到後臺會報錯，這個時候開發就回要你改動的，但是這些事宜往往在交互評審時就確認掉比較好。
  
  同步提交到狀態頁面後的確認操作也容易被忽略，這個問題可能會隱藏到測試階段，也是比較有風險的，但是這些問題在交互評審時都是很容易確認的。
其他邏輯處理
- 要寫出詳細的處理步驟
- 其他交互邏輯有必要詳細列出交互步驟

2、對系統頁面之間的跳轉邏輯做詳細記錄

1. 訪問來源
2. 主頁面間
3. 主頁面與狀態頁面間
這個問題很容易被忽略，交互只在乎主頁面的交互，但是不重視頁面間的跳轉邏輯，當邏輯比較複雜時，問題就會比較突出，甚至在測試階段纔會發現主要問題。以下的例子比較典型，頁面間的邏輯由於入口不同而稍有不同

一個例子，聚划算項目：

3、交互邏輯評估
1. 流程是否可以走通
2. 異常流程是否都可以覆蓋
3. 處理方式是否通用
4. 方案細節是否清晰
  - 流程中每次點擊的去向
  - 流程中每次點擊觸發的邏輯
我們發現，交互同學由於時間較緊或需求變動頻繁，有時候參加評審的交互稿所體現的流程會不準確，流程走不通或已成流程不能覆蓋，這種情況下若直接開發前端邏輯的話，勢必會出現漏洞，導致聯調的時候需要修正，增加必然出現的意外成本。

其中一個例子是：商品項目的商品信息填寫頁面的sku配置功能



這個功能較複雜，修改表單內容會聯動修改下面表格裏面的數據。做之前，交互同學也只是這樣簡單的描述功能的。然而進入聯調階段後，發現直接聯動修改會把用戶手動在表格裏填寫的東西重置掉，而且有些有保護的數據是不能修改的，這樣就導致在開發自測階段的前端邏輯修改。但是回頭想一想，這個問題如果交互同學多思考一下，可能就會發現並提前解決。

還有一個例子：選品項目選品查詢頁面

這個頁面的初選通過和終選通過都需要確定一下買手是誰，但是在批量通過的操作上考慮的不全面，選擇的買手可能會覆蓋正確的數據，若不做數據覆蓋，只是將沒有買手的設置買手，就會產生選擇的結果與實際產生的結果不一致的疑惑，所以到底應不應該支持批量操作，需要仔細考量，並制定出詳細的交互方案。

4、交互成本評估
1. 交互方案是否利於技術方案的重複使用
2. 交互流程是否可以複用
3. 能否優先用現有組件實現
4. 交互實現成本與交互效果的比例是否合理
5. 交互是否可以簡化
  - 儘量減少ajax
  - 儘量減少用彈出框處理主要業務流程
交互方案的成本問題，前端需要重視，現在交互同學對成本往往評估不足，所以需要我們把關。主要的交互流程一定要保證新開頁面，這樣利於流程的重用。

一個例子是：商品重構項目的商品查詢頁面。

由於重構後的商品信息可以不用填的很全，這樣導致一些基於商品的操作需要做商品信息是否全面性的校驗（比如申請認證等一系列商品操作）。這個需求從交互的角度，爲了提高用戶體驗，交互主張把這個校驗做在入口頁面上（比如查詢頁面），即點擊後檢測商品信息全面性，若信息不全則彈出對話框提示。但是這個交互方案非常不利於技術方案的重用，因爲這個檢測對於商品操作來說是必須的，屬於主流程，所以最佳的方案是把這個檢測放在具體的商品操作頁面上（比如申請認證的頁面），只有商品信息符合要求，纔會進行操作，否則跳轉到錯誤頁面。這樣任何頁面只要有這個操作，不用複製檢測商品信息的代碼，可以重用檢測邏輯。

總結：交互評審是降低聯調成本的第一關，相信從以上維度出發，把握好這20%問題，能夠降低80%的聯調成本。