作者：靳澤一

入職轉(zhuǎn)轉(zhuǎn)一年多，大部分時(shí)間都在負(fù)責(zé)售后業(yè)務(wù)的前端開發(fā)，本文主要從前端視角，分享一下轉(zhuǎn)轉(zhuǎn)售后的業(yè)務(wù)和系統(tǒng)，本文目錄如下：

• 從業(yè)務(wù)出發(fā)
• 前端技術(shù)架構(gòu)
• 從業(yè)務(wù)到技術(shù)
• 寫在最后

從業(yè)務(wù)出發(fā)

作為電商公司，售后服務(wù)不僅僅是一個(gè)交易的結(jié)束，也是下一個(gè)交易的開始。做好售后服務(wù)，可以很好的提升用戶體驗(yàn)和口碑，提高用戶的滿意度。轉(zhuǎn)轉(zhuǎn)售后項(xiàng)目主要有兩部分：

• 用戶側(cè)售后頁面
• 客服側(cè)后臺(tái)系統(tǒng)

轉(zhuǎn)轉(zhuǎn)售后作為一個(gè)較為復(fù)雜的業(yè)務(wù)，主要包括從用戶申請(qǐng)售后到完成散貨的全部鏈路，下圖為一個(gè)簡單的售后流程示意圖：

售后業(yè)務(wù)的復(fù)雜除了業(yè)務(wù)流程之外，還有以下幾個(gè)方面的挑戰(zhàn)：

• 涉及多個(gè)運(yùn)行環(huán)境：包括轉(zhuǎn)轉(zhuǎn)、找靚機(jī)、采貨俠以及小程序和 H5 頁面
• 多個(gè)業(yè)務(wù)例如：3C、圖書、游戲、奢侈品、虛擬商品等
• 多種售后類型：維修、退貨退款、換貨等

面對(duì)復(fù)雜的業(yè)務(wù)時(shí)，如何適配多端環(huán)境，兼容多種業(yè)務(wù)場景、多種售后類型，并且更快更好的應(yīng)對(duì)業(yè)務(wù)變化便是我們?cè)谙到y(tǒng)開發(fā)時(shí)需要思考的問題。

前端技術(shù)架構(gòu)

先看一下轉(zhuǎn)轉(zhuǎn)售后系統(tǒng)的前端技術(shù)架構(gòu)圖：

轉(zhuǎn)轉(zhuǎn)具有比較完善的前端技術(shù)架構(gòu)，如上圖，售后系統(tǒng)的開發(fā)完全按照其系統(tǒng)架構(gòu)進(jìn)行開發(fā)，其中中包含了

• UI 協(xié)作：藍(lán)湖、可視化輔助平臺(tái)
• 技術(shù)棧：Vue（用戶端）、React（后臺(tái)）
• 工具庫&組件庫：zz-ui、zant-ui、多端適配器 native-adapter，call-app 喚端、zz-util 工具庫等
• 工程化：apollo 配置平臺(tái)、zz-cli 腳手架、umi-cli
• 開發(fā)調(diào)試：whistle 代理，zApi 接口管理平臺(tái)
• 監(jiān)控平臺(tái)：sentry 異常監(jiān)控、性能分析平臺(tái)、以及 lego 埋點(diǎn)
• ......

從業(yè)務(wù)到技術(shù)

日常的業(yè)務(wù)開發(fā)，我主要講一下兩個(gè)方面

• 用戶側(cè)頁面設(shè)計(jì)
• 后臺(tái)系統(tǒng)相關(guān)

用戶側(cè)頁面設(shè)計(jì)

售后場景的多樣性，導(dǎo)致在用戶側(cè)很多頁面雖然頁面相似，但不同客戶端、不同業(yè)務(wù)、不同狀態(tài)需要展示給用戶的信息都有差異。在需要用同一套頁面去兼容多端多業(yè)務(wù)場景時(shí)如果使用大量 if-else 做業(yè)務(wù)邏輯處理，又或者是針對(duì)每種場景都開發(fā)一套頁面都是非常麻煩的事。在面對(duì)如擴(kuò)品類、業(yè)務(wù)下線等業(yè)務(wù)變化時(shí)，對(duì)于項(xiàng)目的影響和改動(dòng)也會(huì)比較大，大大增加測試回歸成本。因此我們更多采用配置化的方式解決這個(gè)問題。

在用戶點(diǎn)擊進(jìn)入售后頁面時(shí)，我們需要根據(jù)不同業(yè)務(wù)在售后的不同狀態(tài)節(jié)點(diǎn)跳轉(zhuǎn)進(jìn)入不同的售后頁面。這里我們需要根據(jù)首先會(huì)進(jìn)入一個(gè)空白中轉(zhuǎn)頁面，在這個(gè)頁面調(diào)用接口查詢，根據(jù)接口返回鏈接進(jìn)入不同頁面，前端不需要做過多的判斷，并且在其他業(yè)務(wù)需要跳轉(zhuǎn)售后頁面時(shí)，只需要提供中轉(zhuǎn)頁面的鏈接即可。

對(duì)于售后類型選擇頁面，我們會(huì)在后臺(tái)針對(duì)商品不同品類、業(yè)務(wù)線、客戶端、申請(qǐng)時(shí)效等配置頁面需要展示的售后服務(wù)類型。并且關(guān)聯(lián)不同售后類型下的原因配置。

在售后申請(qǐng)頁面，對(duì)于不同的售后類型，售后業(yè)務(wù)，需要用戶填寫的信息以及表單的交互邏輯都有不同。頁面如下：

我們采用數(shù)據(jù)驅(qū)動(dòng)視圖的方式完成頁面邏輯和表單渲染，首先和后端定義表單的設(shè)計(jì)，根據(jù)不同場景在 ?Apollo 配置平臺(tái)配置多種售后申請(qǐng)表單，表單配置示例如下圖所示：

"formInfo": [
  {
    "tip": "",// 提示信息
    "title": "收貨狀態(tài)",// 表單名稱
    "placeholder": "",// placeholder信息
    "type": "",//組件類型（例如對(duì)于輸入框需要區(qū)分是普通輸入框還是textarea）
    "componentRef": "refname",// 組件ref值/表單key值（唯一）
    "componentName": "componentName",// 組件名（同一個(gè)表單可能會(huì)出現(xiàn)多個(gè)同名組件）
    "options": [
      {
        "id": "1",
        "name": "我已收到貨",
        "nonRequiredComponentNames": "unlock", // // 聯(lián)動(dòng)信息：選擇當(dāng)前選項(xiàng)之后需要隱藏的組件（配置componentRef）
        "isDefault": "", // 是否是默認(rèn)值
        "children": [], // 子組件
        "requiredFields": [// 聯(lián)動(dòng)組件ref以及option
          {
            "requiredRef": "reasonId",
            "requiredOptions": ""
          }
        ]
      }
    ],
    "rules": [   // 表單組件校驗(yàn)規(guī)則
      {
        "name": "isRequire",
        "value": "1",
        "message": "收貨狀態(tài)必填",
        "messageType": "alert"
      }
    ]
  }
]

配置信息中包含表單渲染需要的所有信息以及規(guī)則，另外用戶須知等一些文案展示信息也會(huì)一起配置。在前端項(xiàng)目中，對(duì)頁面進(jìn)行組件拆分，根據(jù)接口獲取的配置信息渲染頁面。代碼如下：

<div v-for=“(formItemInfo, index) in formInfo” :key=“index”>
  // 通用組件手
  <form-item-action-sheet
    v-show="!formItemInfo.needHide"
    :key="formItemInfo.componentRef"
    :ref="formItemInfo.componentRef"
    :formItemInfo="formItemInfo"
    @change="onActionSheetChange"
  />
</div>

在售后申請(qǐng)頁面，我們需要做好信息觸達(dá)，我們會(huì)在后臺(tái)配置用戶側(cè)信息展示的配置，使得不同業(yè)務(wù)、不同狀態(tài)的售后可以給用戶展示相應(yīng)的信息。

在配置平臺(tái)，可以根據(jù)業(yè)務(wù)類型配置用戶側(cè)展示的流水信息，售后節(jié)點(diǎn)信息、推送等。

最后，由于各種配置較多，為了方便使用，開發(fā)了配置校驗(yàn)工具，通過配置校驗(yàn)工具可以對(duì)上面所有的配置進(jìn)行校驗(yàn)，提高效率和配置的準(zhǔn)確性。

這種多種配置化相結(jié)合的方式，對(duì)于轉(zhuǎn)轉(zhuǎn)售后這種趨于成熟穩(wěn)定的售后流程而言，具有很多優(yōu)勢(shì)

一些簡單的頁面信息以及表單邏輯的修改，產(chǎn)品可以直接修改配置信息完成，不需要進(jìn)行開發(fā)并上線

擴(kuò)品類時(shí)，我們只需要新增個(gè)別組件并且按照相同的模式配置表單，由后端查詢返回即可，大大減少前端開發(fā)的工作量

后臺(tái)系統(tǒng)

售后后臺(tái)系統(tǒng)采用 React + Hooks + unstated-next 技術(shù)棧，全面擁抱 Function 組件寫法，林語堂說過："懶惰使人進(jìn)步”，為了更快更好的完成日常工作，有更多的時(shí)間“摸魚“。我們就需要提高開發(fā)效率，在盡量短的時(shí)間內(nèi)完成工作。

為了方便使用系統(tǒng)的售后人員工作，對(duì)于系統(tǒng)中的表格均采用如下方式展示信息

對(duì)于這種系統(tǒng)中很多這種重復(fù)的篩選表單+表格的形式，我們會(huì)進(jìn)行組件封裝，將售后系統(tǒng)中的組件按表單、表格、彈窗、視圖以及自定義 hook 等進(jìn)行封裝，

基于 useAntdTable 實(shí)現(xiàn)，在原有功能基礎(chǔ)上結(jié)合售后業(yè)務(wù)邏輯封裝自定義 Hook，對(duì)于接口輸入和輸出進(jìn)行格式化，對(duì)于分頁邏輯，篩選表單邏輯，刷新頁面等邏輯，實(shí)現(xiàn)售后系統(tǒng)中篩選表單的邏輯復(fù)用；使用時(shí)只需要傳入相應(yīng)的配置信息，并把返回的 table props 和 filter props 傳給對(duì)應(yīng)的 表格 和 表單 組件，達(dá)到表單頁面的配置化開發(fā)。

export default (requestApi, option = {}) => {
  const { title, filterConfig = [], wrapperParams = {}, getColumns, ...options } = option

  //  ......省略部分代碼

  const getTableData = useCallback(
    (params, formData) => {
      const { current, pageSize, sorter: s = {}, filters: f = {} } = params
      // 處理getTableData返回的表格的屬性和方法
      // 過濾掉篩選表單中的null、undefined空值，''和 0不會(huì)過濾
      const filterNullObj = objFilter(
        formData || {},
        (_, value) => value !== null && value !== undefined
      )

      //  ......省略部分代碼

      return requestApi({
        ...wrapperParams,
        ...p,
        ...filterNullObj
      }).then((res = {}) => ({
        total: +res.totalCount || 0,
        list: res.dataList || res.ticketDownloadTasks || []
      }))
    },
    [requestApi, wrapperParams]
  )

  const result = useAntdTable(getTableData, {
    defaultPageSize: 5,
    form,
    ...options
  })
  const { refresh } = result
  const { submit } = result.search
  const columns = useMemo(() getColumns && getColumns(refresh, wrapperParams), [
    wrapperParams,
    refresh,
    getColumns
  ])

  result.search = {
    ...result.search,
    // 返回篩選框的配置信息
    filterConfig: typeof filterConfig === 'function' ? filterConfig(submit) : filterConfig,
    form
  }
  return result
}

對(duì)于篩選表單封裝比較簡單，通過遍歷 filterConfig 配置信息并傳給 Form.Item，內(nèi)部封裝表單聯(lián)動(dòng)，搜索、重置等功能邏輯，使開發(fā)可以變成配置化。后續(xù)這種業(yè)務(wù)情景如果比較多且沒有復(fù)雜聯(lián)動(dòng)，會(huì)繼續(xù)優(yōu)化，采用內(nèi)置組件類型，通過后端驅(qū)動(dòng)篩選表單的方式。

對(duì)于售后工作人員來說，“「時(shí)間就是生命，效率就是金錢」”，效率是他們衡量售后系統(tǒng)優(yōu)良最重要的標(biāo)準(zhǔn)，除了表格上信息的高度集合之外，對(duì)于售后詳情頁面，也會(huì)盡可能多的將所需要的信息展示給工作人員， 并且增加一些自動(dòng)化設(shè)計(jì)，來減少售后人員操作，提高效率。

在售后詳情頁中，通過多個(gè) tab 展示更多的信息，在當(dāng)不同崗位的售后工程師通過不同入口進(jìn)入詳情時(shí)，會(huì)直接直接定位至對(duì)應(yīng)的 tab 下。另外還對(duì) tab 的操作方式進(jìn)行了修改，當(dāng)鼠標(biāo)懸浮在 tab 上時(shí)切換，點(diǎn)擊時(shí)會(huì)刷新當(dāng)前 tab 信息，方便工程師在詳情頁的頻繁操作時(shí)的效率。

對(duì)于售后收貨人員操作收貨本質(zhì)是一個(gè)比較同質(zhì)化流水線操作，但是輸入框的聚焦、選中、搜索、清空、按鈕點(diǎn)擊等人機(jī)交互會(huì)降低他們整體的審核效率。基于這問題內(nèi)置聚焦 + 自動(dòng)請(qǐng)求來簡化收貨人員操作。主要會(huì)有以下幾個(gè)訴求：

聚焦

• 進(jìn)入頁面聚焦
• 切回瀏覽器頁簽 - 聚焦選中
• 切換系統(tǒng)頁簽/重新滾動(dòng)到可視化區(qū)域時(shí)- 聚焦選中
• 請(qǐng)求數(shù)據(jù)/提交表單后 - 聚焦選中

請(qǐng)求模式

• 打標(biāo)模式 - 防抖 200ms 自動(dòng)請(qǐng)求或按下 Enter 自動(dòng)請(qǐng)求
• 輸入模式 - 本身不會(huì)自動(dòng)請(qǐng)求只有當(dāng)按下 Enter 鍵才請(qǐng)求

組件封裝如下：

const FastInput = React.forwardRef(({supportBatch, ...otherProps}, ref) => {
  const [mode, setMode] = useState('print') // print 打標(biāo)機(jī)模式  edit 手動(dòng)錄入模式
  //  ......省略部分代碼

  // 將當(dāng)前輸入框聚焦并選中
  const selectAll = usePersistFn(() {
    inputRef.current.focus({
      cursor: 'all'
    })
  })

  // 監(jiān)聽輸入框是否可見，不可見-> 可見則需要聚焦且選中文本
  const inViewPort = useInViewport(wrapRef)

  const { run: printUpdateForm, flush, cancel } = useDebounceFn(
    (value) => {
      otherProps.onSubmit ? otherProps.onSubmit(value) : otherProps.onChange(value)
       //  在每次出發(fā)提交方法之后，再次全選，減少用戶操作
      ;inputRef.current.focus({
        cursor: 'all'
      })
    },
    { wait: 200 }
  )

  // 手寫模式，按回車才更新表單
  const editUpdateForm = (value) => {
   //  同上，調(diào)用提交方法，并選中
  //  ......省略部分代碼
  }
  // 監(jiān)聽所在瀏覽器頁簽是否可見 -切換為所在頁簽自動(dòng)聚焦并選中
  useEffect(() {
    inputRef.current.focus()
    const revalidate = () {
      if (!isDocumentVisible()) return
      selectAll()
    }
    if (typeof window !== 'undefined' && window.addEventListener){
      window.addEventListener('visibilitychange', revalidate, false)
    }
    return () {
      window.removeEventListener('visibilitychange', revalidate, false)
    }
  }, [selectAll])

  // 監(jiān)聽所在輸入框時(shí)候位于可見區(qū)域，當(dāng)移動(dòng)到可見區(qū)域時(shí)，自動(dòng)聚焦并選中
  useUpdateEffect(() {
    if (inViewPort) selectAll()
  }, [inViewPort])

  // 只有打標(biāo)模式才通過防抖通知父元素
  const onChange = usePersistFn((e) => {
    //  ......省略部分代碼
    if (mode === 'print') {
      printUpdateForm(values)
    }
  })

  // 監(jiān)聽 Enter鍵- 打標(biāo)模式下當(dāng)前防抖立即調(diào)用；輸入模式下則直接通知父元素更新
  const onPressEnter = usePersistFn((e) => {
    if (mode === 'print') {
      flush()
    }
    if (mode === 'edit') {
      editUpdateForm(e.target.value)
    }
  })

  // 切換模式；取消當(dāng)前防抖
  const transform = (mode) => {
    if (mode === 'print') {
      cancel()
    }
    inputRef.current.focus()
    setMode(mode)
  }
  return (
    <span ref={wrapRef}>
      <CompInput
        ref={inputRef}
        {...otherProps}
        notallow={onPressEnter}
        value={value}
        notallow={onChange}
        suffix={
          // 輸入框后面的icon以及點(diǎn)擊切換mode
          //  ......省略部分代碼
        }
      />
    </span>
  )
})

寫在最后

最后，雖然目前轉(zhuǎn)轉(zhuǎn)售后流程比較完善和穩(wěn)定，但仍然存在一些業(yè)務(wù)痛點(diǎn)，需要我們持續(xù)思考、優(yōu)化：

售后作為電商公司的“護(hù)城河”，在售后業(yè)務(wù)中，滿意度是一個(gè)很重要的衡量指標(biāo)。如何提升滿意度也成了一個(gè)非常重要的問題。除了做好日常開發(fā)，保證項(xiàng)目質(zhì)量之外，我們還需要思考如何通過技術(shù)手段去提升用戶體驗(yàn)，分析用戶行為，尋找差評(píng)原因。

在涉及多個(gè)業(yè)務(wù)，多種售后類型之后，售后流程變得十分復(fù)雜，多個(gè)流程的耦合導(dǎo)致業(yè)務(wù)變動(dòng)時(shí)，測試回歸的工作很麻煩，因此，在系統(tǒng)設(shè)計(jì)和開發(fā)的時(shí)候，也需要考慮如何通過技術(shù)設(shè)計(jì)來減少測試成本。

如何提升后臺(tái)系統(tǒng)的操作效率 作為一個(gè)業(yè)務(wù)開發(fā)，我們需要衡量好業(yè)務(wù)開發(fā)與技術(shù)創(chuàng)新的關(guān)系，技術(shù)服務(wù)于業(yè)務(wù)，來創(chuàng)造價(jià)值，完全脫離業(yè)務(wù)的技術(shù)創(chuàng)新就是在“耍流氓”。完成基本業(yè)務(wù)開發(fā)的同時(shí)，我們需要思考如何通過技術(shù)手段解決業(yè)務(wù)痛點(diǎn)，來達(dá)到技術(shù)創(chuàng)新的目的。