总结与感悟

背景

记录在工作中需要分析和思考到的点。

过程

• 需求

1. 如果需求不合理，就得委婉表达这个需求无法做。换一种实现方式。
2. 如果需求要修改系统原有设计，就得表明需求无法做。换一种实现方式，因为重新设计一套系统，费时费力。
3. 如果需求要动一些框架的代码，比如使用activiti做加签操作，则也是一个非常难的需求。即使不修改框架代码，也需要花费大量的时间理解到activiti是怎样工作的，才有可能写出来。
4. 根据时间周期和项目已有设计，适当调整一下需求，不要非常教条，需求是怎样就一定要做成怎样，可以适当调整一下。
5. 只要结果正确，过程合理，即使不是严格的实现，变通的解决方案，也是可行的。
6. 如果系统原有设计已经是这样了，那么就应该思考，如何在已有设计的基础上，更好的实现需求。
7. 每一个需求，都应该问问：为什么要做这个需求？
8. 每一个需求，都需要理解这个需求的使用场景。
9. 是否花费了足够时间去理解原型，并且与产品进行沟通？
10. 做的功能设计是否及时与web client, ios, android沟通?
11. 完成的功能需求，是否能够应对需求的改变？如何设计才能应对需求的改变呢？大胆的设计，不要拘泥于现有系统的设计，打破它。
12. 如果需求有问题，需要积极组织会议讨论。
13. 如果需求过于难，花费几天也没有找到思路，需要积极向上反馈。

• 系统版本兼容

1. 写的代码逻辑，是扩展还是修改？会不会影响原有的逻辑过程？
2. 功能逻辑的实现的影响范围有多大？
3. 功能能够兼容原来的移动端逻辑吗？因为ios发布版本也是一个漫长的过程，完成功能需要考虑到，尽可能少修改ios的代码。

• 任务分配

1. 知道有哪些具体的任务。每个任务实现细节是怎么样的。哪些是底层的通用功能设计？哪些是上层的变化需求？
2. 对一个项目底层业务逻辑非常熟悉，那么就应该花费时间去做功能设计。比如工作流引擎业务相关的设计，把这些设计做成更加通用的功能，而把上层变化的需求分配给同事。
3. 任务分配：自己需要做哪些？为什么自己要做这些？哪些是需要分配出去的？为什么要分配这些？

• 代码功底

1. 能够批量插入数据库的就不要一条一条插入。
2. 区分功能方法和业务方法。功能方法就需要设计得更加通用一些，谁都可以调用这样的功能方法。切记：功能方法不能耦合业务逻辑。
3. 在代码的抽象层上。比如一个list写判断。这个list是null的时候应该怎么处理？size为1的时候又怎么处理？像这样的抽象层一般考虑两种情况空和非空。也就是说把size为1的情况写到多的情况中。
4. 固有代码逻辑：找到需要截断的业务逻辑，采用return截断。
5. 每一个接口都需要考虑：重复提交怎么办？事务怎么处理？并发怎么处理？日志记录了吗？是否需要使用分布式锁？是否需要使用分布式事务？
6. 使用List的时候，如果能够确定容量大小，一开始就需要给定。

• 线上bug

1. 立即看日志记录。寻找问题原因。
2. 积极询问产生问题的全过程，看能否在测试环境复现。
3. 定位问题，分析问题，找到问题原因，解决问题。一定是这样的步骤。
4. 如果是涉及OOM之类的，先解决问题比如加大一下堆上内存。其次就是线上使用arthas工具分析，哪些对象创建了，未回收。
5. 如果是栈溢出了，则加大栈的内存大小，先解决问题。其次，找到是调用了哪个方法导致这样的bug发生，分析为什么会发生。

小结

1. 通过一次又一次的总结，力求做更好的功能设计，把代码写的更好。
2. 思考：如何去沟通需求？分析需求？做更加好的需求功能设计？
3. 思考：如何才能非常完备地把代码写好？