1. 问题总结
未发布类型的职位详情中，会将职位信息缓存到浏览器。
数据缓存和获取都需要特殊金额转化，经测试发现，处理的不对等导致职位详情中薪资的错误展示，属历史遗留问题。
而HR端前端代码对于薪资的转化处理有两种
- 转化得到正确精度的数值（新增职位）
- 使用前台的模板让精度错误的数据显示正常（职位详情、职位缓存和获取）
在本期实现新功能“职位编辑”时，应该参考新增职位的薪资处理，而开发并没有意识。
而遗留问题有提醒到开发要对查询进行单向薪资处理，但是对于提交的职位没有做对等处理。
由于在编辑态的薪资展示正常，只有提交职位信息再刷新以后才能暴露问题，所以最终也没被测试人员注意。
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'},
}
}
- 获取的职位信息中
如果薪资为年薪，除了使用parse处理数值以后，还需要将数值除以10。比如200万的年薪，后台返回了200000，我们的模型定义的单位是K，那么经过parse以后，数值变成了200。为了符合万的展示需要，还需要将200/10，得到20。
- 提交给后台的信息中
我们可以将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）的处理。
