最近一段时间，都在做一个业务，因为自己梳理需求，没有梳理到位，现在需要重构这部分业务。
在和技术经理一起工作过程中，我发现他的很多解决问题的思路我需要学习：
11.12日反思：
- 遇到哪个字段和其他规则不一样的，和产品等相关人员确认，确认后理解了立即开发，逻辑95%是对的。
- 被抓到某个具体业务字段区别是什么，我说不出来
- 业务需求别人是第一次就理解
- 单元测试必须要写，如果刚开始就写单元测试，就会发现很多问题，以测试驱动开发。
- 技术经理，问我什么是同一次的概念，直接问我疑问点在哪，然后让找产品确认，他听完就知道了，没有逻辑的同一次的概念，也存在仪器回传时候没有按照一高一低回传(在做的过程中遇到实现疑点就去问)
- 技术经理在写代码时，遇到问题，具体的实现细节，会再次和产品确认，讨论，讨论完后，能够立马完成，今天必须完成，加班也要完成
- 技术经理做事情，很有条理，首先把需求分几步来完成，每一步是做什么的，分的很细。
- 写代码要有条理性，每个方法尽量不要超过IDEA一个屏幕能看到的位置，每个方法做各自的事情，不要混合在一块，像一坨屎一样。
- 定义接口参数明确，尽量不要用一个对象传入很多参数，业务需要几个参数定义几个，避免不同接口入参冗余在一起。
- 在梳理业务时，需要考虑异步的场景，多线程实现方式，保证程序执行效率。
11.14日反思：
- 今天看同事的代码风格，比较清晰，他在写每个方法之前是非常清晰的，这是我值得学习的，我的问题就出现在这里，理解不清楚。
- 在开发之前，所有的问题都考虑到了，等写代码时，存粹的实现就可以了，所以我发现他开发效率很高，每天晨会汇报时，做天做了什么，今天做了什么。
11.13日反思：
-
多向技术经理学习，学习他处理问题的思路，程序设计思路；大问题拆解小问题，一个个有条理地解决。
-
越是业务复杂的场景，越需要写单元测试，一个个测试，部分测试没问题，整体程序也不会出现大问题。
11.05日反思：
-
在理解需求时，需要更细致一些，而不是开发完了提测才发现问题，多思考发现问题
-
多测试，代码实现时尽量精简，思路清晰
-
程序计算时考虑多台机器同时计算问题，需要清楚锁等待时间的场景
10.29日反思：
-
自己在梳理需求考虑的太少，想当然做出来的东西是错的，有时模棱两可的就开始做了，做了很多无用功。
-
改善自己的工作模式(周末写篇总结和反思，在需求梳理和开发方面
10.22日反思：
-
在开发时候，对需求没有理解透彻，数据流向没搞清楚，造成问题不断在测试修复，造成自己工作效率比较低。
-
工作方式需要改变，充分理解需求之后再开发，避免这样的问题再出现，吸取教训。
10.15日反思：
-
在代码重构过程中，以往做好的细节点漏掉了，自测不充分，所以出现bug重新打开的问题，以后写单元测试
-
在开发前，需求理清楚再做效率会高些，比如生成器，现在实现和最开始说的其实需求差别挺大的，学着深挖业务实际场景，多用旧系统。
-
多考虑模块之间的衔接、交互部分，不单单自己负责的一小部分。
