用户无法应聘不分岗位
用户、招聘经理无法申请指定的两个岗位，领导提示数据表字段值过长。
处理过程
先找运维要了Form表的建表语句后，没有发现和测试环境的区别，大致感觉问题出现在字符串长度为50的限制。但是检查了页面上岗位的基本信息后（岗位名称、职责），目测没有问题。因为框架没有封装全局异常捕获，elk也没有看到异常日志，于是选择的方案是先通过正常日志观察执行流程、对比数据库表单数据，最后在本地造指定数据测试。
观察日志结合查表单，发现表单没有新增成功，于是参考BuildForm()的代码，构建用户各种信息和岗位信息，本地造单元测试，能复现问题。花了大量时间查用户信息，组装了岗位数据后，准备通过部分注释代码的方式找到是哪些属性值有问题。将单元测试给老板后，老板推测出某个字段有问题。最后是将大量字符串字段的长度都增加到255.
耗时：3个小时，预计1个小时。
分析
思路有待改进，在对表建表语句找字段、阅读代码找出错点、拿生产数据造单元测试表单三个点中，先对比建表语句是对的，因为生产环境和测试环境的数据库没有完全保证一致。其他的问题就比较多了。
问题
- 在阅读代码找出错点和拿生产数据造测试表单的两种思路选择上，不够细致。还是靠经验认为配合日志阅读代码比较快，实际情况是一步步找日志，一步步对代码，效率太低，想办法一次跳一大步，然后往回夹。那样预计能省半个小时。
- 拿生产数据造单元测试表单时，去查了用户的所有相关属性值。没必要，在看日志和Form表单数据时，用户最近能申请岗位成功，并且问题里已经指出了“是这两个岗位的数据有问题”。所以没必要花大量时间设置用户的属性，而是关注在“招聘岗位”上。
- 不敢使用盲猜的方式。造好了包含一堆属性的表单，本地测试复现问题了，由于以前的老板否定了盲猜的方式处理问题，就用了一块块属性注释的方式走单元测试。以往老板否定的方法不代表使用的方法有问题，前面第一步分析表结构的时候就确定了问题范围在varchar(50)的那些字段里，没必要还等同的分块。就算用分块，也应该在第一步表结构分析结果的范围内来做，不然第一步花的时间作用不大。
- 导岗位数据，直接在生产查对应表的记录，导出excel，一次复制多个字段
- 一开始还想复制完整的岗位信息到测试环境。太耗时，也基本没用
- Spring Boot的异常封装信息比.net framework 完整，.net framework只是提示大致的异常描述和出问题的方法，不会描述具体的错误。 可以本地起一个Spring Boot 项目，参考原来的代码实现CRUD，方便诊断问题，并且更省时。
值得肯定的地方
- 思路大致没错，但是解决问题的不同思路的优先级，要参考具体场景来调整。
- 在结合访问日志和代码的情况下，准确定位到了错误的代码行，虽然手上没有异常信息
总结
- 老项目没有统一异常处理、给的异常信息也比较抽象，的确没有较快效率的方式诊断问题。
- 数据表设计要稍微好一点，现在硬盘很便宜，不要再出现varchar(10) varchar(25) varchar(50) 之类的设计。
- 要尝试使用效率更高的方式诊断老项目，不要局限于老项目自身的技术。
- 生产环境日志已经切换，不要再用老ELK了。
改进措施
- 多解决方案相互使用处理结果。解决问题时，某个思路可能没有解决问题，但是该思路的输出结果可以供其他思路参考，而不是不同思路之间相互隔离，那样不能体现解决方案共赢的优点。
- 造最少的数据。造数据表单时，尽量结合现有的数据库数据、日志、其他诊断结果，造少一些的数据，节省时间。
- 少一点将生产数据导入到测试环境数据库。因为导入麻烦，效果不一定有单元测试的模拟数据好
- 使用Spring Boot 建一个项目，模拟老 .net 项目的业务，或者用golang，能显著提升效率，尤其是现在这个场景的。并且 Spring Boot 项目好像已经有了。不要切换数据库
- 在老 .net 项目中使用filter实现全局异常处理，捕获后记录日志，然后继续抛出。
实施计划
- 原来已经有一个项目连接sqlserver 了，但是是spring boot，太慢了。看能不能用golang 来做。
- 上周的实施计划还没实施。缓一下。
