背景
记录在工作中需要分析和思考到的点。
过程
- 需求
- 如果需求不合理,就得委婉表达这个需求无法做。换一种实现方式。
- 如果需求要修改系统原有设计,就得表明需求无法做。换一种实现方式,因为重新设计一套系统,费时费力。
- 如果需求要动一些框架的代码,比如使用activiti做加签操作,则也是一个非常难的需求。即使不修改框架代码,也需要花费大量的时间理解到activiti是怎样工作的,才有可能写出来。
- 根据时间周期和项目已有设计,适当调整一下需求,不要非常教条,需求是怎样就一定要做成怎样,可以适当调整一下。
- 只要结果正确,过程合理,即使不是严格的实现,变通的解决方案,也是可行的。
- 如果系统原有设计已经是这样了,那么就应该思考,如何在已有设计的基础上,更好的实现需求。
- 每一个需求,都应该问问:为什么要做这个需求?
- 每一个需求,都需要理解这个需求的使用场景。
- 是否花费了足够时间去理解原型,并且与产品进行沟通?
- 做的功能设计是否及时与web client, ios, android沟通?
- 完成的功能需求,是否能够应对需求的改变?如何设计才能应对需求的改变呢?大胆的设计,不要拘泥于现有系统的设计,打破它。
- 如果需求有问题,需要积极组织会议讨论。
- 如果需求过于难,花费几天也没有找到思路,需要积极向上反馈。
- 系统版本兼容
- 写的代码逻辑,是扩展还是修改?会不会影响原有的逻辑过程?
- 功能逻辑的实现的影响范围有多大?
- 功能能够兼容原来的移动端逻辑吗?因为ios发布版本也是一个漫长的过程,完成功能需要考虑到,尽可能少修改ios的代码。
- 任务分配
- 知道有哪些具体的任务。每个任务实现细节是怎么样的。哪些是底层的通用功能设计?哪些是上层的变化需求?
- 对一个项目底层业务逻辑非常熟悉,那么就应该花费时间去做功能设计。比如工作流引擎业务相关的设计,把这些设计做成更加通用的功能,而把上层变化的需求分配给同事。
- 任务分配:自己需要做哪些?为什么自己要做这些?哪些是需要分配出去的?为什么要分配这些?
- 代码功底
- 能够批量插入数据库的就不要一条一条插入。
- 区分功能方法和业务方法。功能方法就需要设计得更加通用一些,谁都可以调用这样的功能方法。切记:功能方法不能耦合业务逻辑。
- 在代码的抽象层上。比如一个list写判断。这个list是null的时候应该怎么处理?size为1的时候又怎么处理?像这样的抽象层一般考虑两种情况空和非空。也就是说把size为1的情况写到多的情况中。
- 固有代码逻辑:找到需要截断的业务逻辑,采用return截断。
- 每一个接口都需要考虑:重复提交怎么办?事务怎么处理?并发怎么处理?日志记录了吗?是否需要使用分布式锁?是否需要使用分布式事务?
- 使用List的时候,如果能够确定容量大小,一开始就需要给定。
- 线上bug
- 立即看日志记录。寻找问题原因。
- 积极询问产生问题的全过程,看能否在测试环境复现。
- 定位问题,分析问题,找到问题原因,解决问题。一定是这样的步骤。
- 如果是涉及OOM之类的,先解决问题比如加大一下堆上内存。其次就是线上使用arthas工具分析,哪些对象创建了,未回收。
- 如果是栈溢出了,则加大栈的内存大小,先解决问题。其次,找到是调用了哪个方法导致这样的bug发生,分析为什么会发生。
小结
- 通过一次又一次的总结,力求做更好的功能设计,把代码写的更好。
- 思考:如何去沟通需求?分析需求?做更加好的需求功能设计?
- 思考:如何才能非常完备地把代码写好?