开发过程中的一点收获

开发过程中的一点收获

代码兼容

1. 关于兼容性的考虑，新功能上线后，服务器逐步重启，此时各个服务器上部署的并不是同一套代码，是否会对业务产生影响？
   此时有两种解决办法：
   最简单的当然是能够避免在有流量时进行发布。（这点要结合业务特性，ToC的系统明显做不到这点。）
   第二种则是：通过开关把控，代码部署后，所有服务器都部署完毕，通过切流开关，进行白名单验证。（缺点：技术成本高，并且需要具有生产环境验证账号（如果确定测试环境测试全面，这步也可以省略））

代码CR

1. 每一层，都应该有对应层的领域模型（DTO），保证对应的领域模型业务逻辑清晰。并且VO尽量不重复使用。
2. 在具体的业务逻辑中，按照处理流程进行方法拆分，拒绝一大坨逻辑放在一个方法中处理，保证代码的可服用性，以及代码的可读性。
3. 方法上的注解，完整且清晰
4. 涉及到同一种类型的不同字段，应该使用枚举操作。

业务代码收获

1. 背景：用户在页面中输入支行名称进行模糊查询，页面中反显模糊查询的支行名称列表。
2. 问题：由于是夸网关进行查询，四大行返回的支行页面数量很大，上万条信息，在解析过程中会导致网关超时。
3. 解决方法：从用户思维出发，并不需要将所有支行信息全部返回，可以只返回部分数据，比如1000条，此时用户并不会一条一条的去找支行的名字。
4. 目的：返回模糊查询结果是为了：使用户不用输入完整的支行名称，就能够选择到对应支行。并且，在用户选不到时，促进用户输入更多的字符支行名称
5. 业务角度分析：在匹配数据量多时，用户并不会一条一条看，而系统返回模糊匹配结果，也是为了促进用户继续输入更精确的名称，当返回数据量小时，从中进行选择。