导语
经过多个日夜都在跟研发效率作斗争。常在反思,如何避免无效加班,如何才能快速提升个人研效,本人根据个人开发经验,抛砖引玉,为新人程序员提供一些参考。
关键代码
项目的关键代码一定要做好位置记录。好记性不如烂笔头,可以使用记事本记录代码相对位置(IDE通常提供这一功能)、类名、方法名等,下次想找可以快速定位位置。
负责模块的架构
主动了解所负责模块的架构。如果所做的工作大都围绕某一模块,应该趁做相关的需求的机会,了解对应的框架设计,做到知识点连点成线,连线成片。并对核心代码做好记录。
需求
拿到需求之后,一定要跟策划、产品、设计等关联需求同事对清楚细节。有可能出现歧义的地方,要再三确认,并且需要把补充内容同步到需求单中,避免出现甩锅以及反复返工。
技术方案
需求启动之前技术方案先行。想好需求怎么做之后再动手十分必要,常常能起到事半功倍的效果。如果不了解现有代码逻辑,可以找熟悉的同事了解,然后再调研技术方案。有了方案后,可以跟熟悉相关模块的同事对齐下疑惑之处。
commit代码
commit代码之前,应该仔细检查本次需求的代码的提交,确保自己能看懂每一行逻辑。给自己做code review能有效降低bug率,减少返工次数,同时避免出现编译错误,会导致版本构建失败,需要使用下个版本包的同事会疯狂抓狂甚至如果出现他紧急需要新包的时候会拉很多leader进群讨论的。新代码做了一些不易理解的特殊逻辑,可以再想想,是否能换成常规思维方式,甚至项目已有架构、编码模式来替代。如果确实得这么做,也应该写清楚注释,说明这么做的理由。
上线
需求上线之前再用用新做的功能。上线前,以用户视角多用用自己新开发的功能,能够有效避免大多数线上问题。如果开发阶段用的是开发服务器,当后台接口上线后,一定要用线上服务器看那看看效果。即使阻碍上线进度也比上线后出问题再发热修的代价要小得多。
离线日志
看情况给新需求的核心路径加上离线日志。如果新做的需求非常关键,但是流程很复杂,存在出现问题的可能,那么最好加上日志,日志最好能按照模块,给日志加上统一的前缀,能在用户反馈时,快速定位问题发生在哪一步。
知识盲区
如果我们遇到知识盲区怎么办。不要着急,遇到知识盲区是程序开发过程中遇到的事。应该使用一切手段解决问题,包括请教各类大模型老师,查找官方SDK,论坛查找资料等。这些方式适合零碎的知识点,如果有成片的知识点缺失,强烈建议看专业书籍。
1555

被折叠的 条评论
为什么被折叠?



