（適用范圍：涉及前后端共同產(chǎn)出的項(xiàng)目。文章有些長(zhǎng)，但若認(rèn)真閱讀，應(yīng)該會(huì)有所收獲。）

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

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

1. 套vm

2. 后臺(tái)調(diào)試

3. 開發(fā)自測(cè)

4. 測(cè)試

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

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

目錄：

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

2、從交互評(píng)審做起

3、前端方案要從多方面進(jìn)行評(píng)估

4、Demo制作要留心

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

6、全文大綱

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

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

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

所以，聯(lián)調(diào)成本不能光靠"讓前端書寫vm"這樣的簡(jiǎn)單方式處理，應(yīng)該從項(xiàng)目的各個(gè)階段入手，增強(qiáng)對(duì)需求和交互稿的理解與把關(guān)，從而降低后期聯(lián)調(diào)的成本。

二、 從交互評(píng)審做起

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

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

1、對(duì)頁面上每一個(gè)可以點(diǎn)擊的元素，做交互記錄

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

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

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

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

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

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

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

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

5. 信息提示框
   • 簡(jiǎn)單提示框（只有確認(rèn)按鈕）
     • 確認(rèn)后的回調(diào)
   • 確認(rèn)提示框（有確定、取消按鈕）
     • 確認(rèn)后的回調(diào)

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

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

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

Ajax的回調(diào)都要做一些什么事情，也是交互同學(xué)最容易忽略的事情，往往解釋的很簡(jiǎn)單，這里提供了一些維度，希望前端同學(xué)與交互同學(xué)確認(rèn)。

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

   提交前的校驗(yàn)很容易被忽略，直到開發(fā)調(diào)試或自測(cè)是測(cè)會(huì)被發(fā)現(xiàn)，因?yàn)槿绻�某些值不校�?yàn)，提交到后臺(tái)會(huì)報(bào)錯(cuò)，這個(gè)時(shí)候開發(fā)就回要你改動(dòng)的，但是這些事宜往往在交互評(píng)審時(shí)就確認(rèn)掉比較好。

   同步提交到狀態(tài)頁面后的確認(rèn)操作也容易被忽略，這個(gè)問題可能會(huì)隱藏到測(cè)試階段，也是比較有風(fēng)險(xiǎn)的，但是這些問題在交互評(píng)審時(shí)都是很容易確認(rèn)的。

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

 

標(biāo)簽： 前端 ��

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