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

大多數(shù)人認為，只有前端和后臺套vm的過程才算聯(lián)調，但是很多項目做下來的感受是：這個階段其實不會花費多少成本，大概占到10%，但是真正的痛苦一直會持續(xù)到項目發(fā)布。

從交付到上線，需要"聯(lián)調"的階段大概有：

1. 套vm

2. 后臺調試

3. 開發(fā)自測

4. 測試

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

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

目錄：

1、聯(lián)調成本到底出在哪里

2、從交互評審做起

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

4、Demo制作要留心

5、聯(lián)調階段把控需求變更

6、全文大綱

一、聯(lián)調成本到底出在哪里？

將我們所碰到的問題整理一下，統(tǒng)計出一般項目的聯(lián)調成本。

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

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

二、 從交互評審做起

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

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

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

1. 表單元素是否觸發(fā)校驗
   • 普通校驗：必填、長度、正則
   • 聯(lián)合
   • 異步

校驗問題的不確定，會導致demo功能的缺失，會影響并增加開發(fā)自測或測試階段的聯(lián)調成本，異步校驗的缺失可能在開發(fā)調試階段就會被發(fā)現(xiàn)，并找前端補充該功能。

2. 頁面鏈接的打開方式
   • 內部刷新url
   • 瀏覽器新開頁面

鏈接雖然是個小問題，但是大多數(shù)交互和前端都是不會注意的，一般都要等到開發(fā)調試階段甚至測試階段才會發(fā)現(xiàn)，所以舉手之勞，就回免去后面零零碎碎的聯(lián)調成本。

3. 頁面間操作（以下操作可組合出現(xiàn)）
   • 新打開tab
   • 關閉當前頁面
   • 切換到原頁面并刷新

這個問題幾乎所有交互都會忽略，但是會在功能預演或測試時提出，有些較明顯的也要開發(fā)調試階段才會被發(fā)現(xiàn)，所以非常有必要在交互評審時就明確該事項，減少聯(lián)調成本

4. 打開對話框
   • 對話框初始化前（頁面初始化時）
     • 對對話框里面的控件進行初始化：表格、日歷、聯(lián)動選擇等組件
   • 對話框初始化動作
     • 對不能在之前初始化的控件進行初始化：kissyEditor
     • 判斷對話框是否已經存在，存在的話不必再次初始化
   • 對話框打開時動作
     • 刪除錯誤提示
     • 清空數(shù)據
     • 回顯數(shù)據
     • 更新內容
   • 確認后的動作
     • 異步提交表單
       • 提交前的校驗
       • 增加提交數(shù)據
       • 提交后的回調
     • 更新數(shù)據
   • 對話框關閉時動作
     • 關閉對話框

   打開對話框動作，往往是交互同學比較喜歡的分支操作方式，但是交互稿往往很簡單，只確定了在什么情況下打開對話框，對話框里有什么東西這些基本的東西。但是前端同學在制作是會涉及很多細節(jié)問題，這些問題的不確認或缺失會對聯(lián)調造成很大改造成本，比如數(shù)據回顯、情況等問題會在開發(fā)調試甚至測試階段才會被發(fā)現(xiàn)和返工修改。

5. 信息提示框
   • 簡單提示框（只有確認按鈕）
     • 確認后的回調
   • 確認提示框（有確定、取消按鈕）
     • 確認后的回調

   確認后肯定會有回調，但是回調什么東西，是很容易忽略的事情，交互、前端、開發(fā)的看法若不能統(tǒng)一的話，很容易在開發(fā)調試階段引起意外成本。

6. 異步操作（ajax請求）
   • 收集提交數(shù)據
   • 回調
     • 刷新表格
     • 刷新dom
     • 信息提示

收集要提交的數(shù)據，往往會在開發(fā)調試階段帶來很多零碎的意外成本，所以在交互評審或者制定前后端方案時最好確定下來，避免后期修改。

Ajax的回調都要做一些什么事情，也是交互同學最容易忽略的事情，往往解釋的很簡單，這里提供了一些維度，希望前端同學與交互同學確認。

7. 提交表單
   • 提交前校驗
   • 提交方式
     • 異步提交
       • 收集提交數(shù)據
       • 回調
         • 刷新表格
         • 刷新dom
         • 信息提示
     • 同步刷新至成功或失敗頁面
     • 確認后的動作
       • 關閉當前頁
       • 打開新頁面
       • 切換至源頁面并刷新

   提交前的校驗很容易被忽略，直到開發(fā)調試或自測是測會被發(fā)現(xiàn)，因為如果某些值不校驗，提交到后臺會報錯，這個時候開發(fā)就回要你改動的，但是這些事宜往往在交互評審時就確認掉比較好。

   同步提交到狀態(tài)頁面后的確認操作也容易被忽略，這個問題可能會隱藏到測試階段，也是比較有風險的，但是這些問題在交互評審時都是很容易確認的。

8. 其他邏輯處理
   • 要寫出詳細的處理步驟
   • 其他交互邏輯有必要詳細列出交互步驟

 

標簽： 前端 ��

版權申明：本站文章部分自網絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。