总结与感悟

﹏ヽ暗。殇╰゛Y 2023-03-01 13:45 9阅读 0赞

#### 背景 ####

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

#### 过程 ####

*  **需求**

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.  思考：如何才能非常完备地把代码写好？