服务端,编码开发过程中,我们是不是会经常会遇到一些低级的BUG,曾经的错误迭代出现,许许多多的BUG从而导致了服务端的编码质量不高。今天,我重新梳理下之前项目的一些经验,做个分享和总结。
从简洁的代码开始
具有良好的代码规范
需要团队定义一整套规范,包括注释,包名,类名,字段名,代码结构等等,从而保证代码清晰,良好的格式。
保证注释的合理性和正确性
保证注释的合理性和正确性,这个也是很重要的。经常,我们不去注意注释,从而导致了重要复杂业务注释不全,或者注释没有及时更新,给后来的人挖坑。个人觉得,添加注释的过程,就是业务代码梳理的过程。
做好自测,很重要
单元测试
- 在编码阶段,我们就需要完成单元测试,保证提测前,做好单元测试,即在交付测试环境之前过完一轮。这样,可以非常有效减少在测试过程中出现BUG的概率。
- 单元测试的用例应该包括:功能可用性、功能正确性、等价值、边界值。
- QA的测试用例,bug反馈,可以整理到单元测试中。
- 通过检查工具,保证单元测试的覆盖率,例如Jacoco。
服务端错误手册
根据项目的情况,整理服务端错误手册,手册在手,天下我有的情怀。
考虑代码复用
尽量少去造轮子,重复的代码,考虑是否可以抽离,是否可以组件化。
代码审核,必须保证
我们团队正常会做三重审核机制。
- 代码交叉评审:开发好的代码,给服务端其他人评审。
- 经理代码评审
- 代码例会评审:不定期的开展例会,将自己开发的功能,进行分享和讲解,服务端的同学一方面对其他人的功能有所了解,同时走查他的代码,审核是否有问题。一个重要的好处就是,及时发现潜在问题。
服务端评审点
审核点,我整理了下大概有重要的包括几个部分。
- 代码规范。
- 有效性检验:是否考虑边界值、合法数据等。
- 功能逻辑:功能是否偏差等。
- 性能问题:是否存在性能问题,例如SQL慢查询。
- 安全问题:是否存在SQL注入,是否存在XSS攻击,是否鉴权等。
- 接口是否可用:可以使用postman,dhc等工具模拟请求,进行测试。