1. 問題總結

未釋出型別的職位詳情中，會將職位資訊快取到瀏覽器。
資料快取和獲取都需要特殊金額轉化，經測試發現，處理的不對等導致職位詳情中薪資的錯誤展示，屬歷史遺留問題。

而HR端前端程式碼對於薪資的轉化處理有兩種

1. 轉化得到正確精度的數值（新增職位）
2. 使用前臺的模板讓精度錯誤的資料顯示正常（職位詳情、職位快取和獲取）

在本期實現新功能“職位編輯”時，應該參考新增職位的薪資處理，而開發並沒有意識。
而遺留問題有提醒到開發要對查詢進行單向薪資處理，但是對於提交的職位沒有做對等處理。

由於在編輯態的薪資展示正常，只有提交職位資訊再重新整理以後才能暴露問題，所以最終也沒被測試人員注意。

2. 更具體的分析

2.1 前端的資料模型的定義和使用

後臺的金額資料都是以元儲存，比如月薪3萬儲存在後臺 的數值是30000。

前臺定義了通用的資料模型，有兩個方法parse和dispose。如下為前端的薪資模型簡陋結構

{
    salaryMax: {value: 0, unit: 'K'},
}

如果後臺返回的數值為 {salaryMax:30000}，前臺拿到數值以後，呼叫parse得到結果 {salaryMax:30}，然後用於介面30K的正常顯示。

在編輯態，如果在輸入框中修改了最大薪資為50，那麼提交給後臺的時候需要將 {salaryMax: 50} 進行dispose，得到{salaryMax: 50000}。

2.2 前臺做的特殊處理

在上面的模型中，salaryDetail.salaryMax的單位配置成了K。而在實際專案中，我們通常會選擇薪資型別為年薪(salaryType=1)或者月薪(salaryType=2)。使用習慣上，年薪通常以W計，月薪通常以K計。那麼在程式碼層面上急需要做對等的特殊處理：

{
  salaryDetail: {
    salaryType: 1, // 1 年薪；2 月薪
    month: 0,
    salaryMax: {value: 0, unit: 'K'},
    salaryMin: {value: 0, unit: 'K'},
  }
}

1. 獲取的職位資訊中

如果薪資為年薪，除了使用parse處理數值以後，還需要將數值除以10。比如200萬的年薪，後臺返回了200000，我們的模型定義的單位是K，那麼經過parse以後，數值變成了200。為了符合萬的展示需要，還需要將200/10，得到20。

2. 提交給後臺的資訊中

我們可以將20修改為任意數值比如30，提交給後臺的時候，會呼叫dispose，得到30000，但因為使用的是K的轉化標準，還需要3000*10，最終傳遞300000給後臺。

2.3 業務邏輯的處理的四種情況

2.3.1 新增職位

特點：單向/只做提交

提交職位的時候，判定如果薪資型別為年薪，進行dispose+乘以10的組合操作。

2.3.2 檢視職位詳情

特點：單向/只做獲取

獲取到職位資訊的時候，判定如果薪資型別為年薪

• 理論上，應該進行parse+除以10的操作
• 實際上，但是採用了使用錯誤的精度，但是在介面中通過特殊處理來展示

實際上的技術實現為：computed中有個形如salaryDetailDisplay的屬性，會返回要顯示的薪資範圍的字元，它會用到salaryType是否等於1決定如何拼裝展示在介面的數值和單位

2.3.3 職位快取

特點：雙向/快取和獲取快取

因為只是快取資料，只需要快取和獲取快取的時候採用一致的標準即可。即要麼快取的時候和獲取的時候都不處理，要麼都做處理。

2.3.4 職位編輯

特點：雙向/查詢和儲存

為了介面能正常展示，對於薪資型別為粘性的型別，必須：
（1）查詢職位資訊後進行parse+除以10的處理
（2）在儲存職位的時候進行dispose+乘以10的處理

2.4 問題的技術性分析

對整個HR端的薪資處理的整理情況不夠了解，沒有意識到要按照2.3.4的方式進行處理。

對歷史遺留問題的解決中也僅僅注意到了2.3.4中的（1）的處理，而忽略了2.3.4中（2）的處理。