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）的处理。