文章目录

  1. 1. 从简洁的代码开始
    1. 1.1. 具有良好的代码规范
    2. 1.2. 保证注释的合理性和正确性
  2. 2. 做好自测,很重要
    1. 2.1. 单元测试
    2. 2.2. 服务端错误手册
  3. 3. 考虑代码复用
  4. 4. 代码审核,必须保证
  5. 5. 服务端评审点

服务端,编码开发过程中,我们是不是会经常会遇到一些低级的BUG,曾经的错误迭代出现,许许多多的BUG从而导致了服务端的编码质量不高。今天,我重新梳理下之前项目的一些经验,做个分享和总结。

从简洁的代码开始

具有良好的代码规范

需要团队定义一整套规范,包括注释,包名,类名,字段名,代码结构等等,从而保证代码清晰,良好的格式。

保证注释的合理性和正确性

保证注释的合理性和正确性,这个也是很重要的。经常,我们不去注意注释,从而导致了重要复杂业务注释不全,或者注释没有及时更新,给后来的人挖坑。个人觉得,添加注释的过程,就是业务代码梳理的过程。

做好自测,很重要

单元测试

  • 在编码阶段,我们就需要完成单元测试,保证提测前,做好单元测试,即在交付测试环境之前过完一轮。这样,可以非常有效减少在测试过程中出现BUG的概率。
  • 单元测试的用例应该包括:功能可用性、功能正确性、等价值、边界值。
  • QA的测试用例,bug反馈,可以整理到单元测试中。
  • 通过检查工具,保证单元测试的覆盖率,例如Jacoco。

服务端错误手册

根据项目的情况,整理服务端错误手册,手册在手,天下我有的情怀。

考虑代码复用

尽量少去造轮子,重复的代码,考虑是否可以抽离,是否可以组件化。

代码审核,必须保证

我们团队正常会做三重审核机制。

  • 代码交叉评审:开发好的代码,给服务端其他人评审。
  • 经理代码评审
  • 代码例会评审:不定期的开展例会,将自己开发的功能,进行分享和讲解,服务端的同学一方面对其他人的功能有所了解,同时走查他的代码,审核是否有问题。一个重要的好处就是,及时发现潜在问题。

服务端评审点

审核点,我整理了下大概有重要的包括几个部分。

  • 代码规范。
  • 有效性检验:是否考虑边界值、合法数据等。
  • 功能逻辑:功能是否偏差等。
  • 性能问题:是否存在性能问题,例如SQL慢查询。
  • 安全问题:是否存在SQL注入,是否存在XSS攻击,是否鉴权等。
  • 接口是否可用:可以使用postman,dhc等工具模拟请求,进行测试。
(完)

微信公众号

文章目录

  1. 1. 从简洁的代码开始
    1. 1.1. 具有良好的代码规范
    2. 1.2. 保证注释的合理性和正确性
  2. 2. 做好自测,很重要
    1. 2.1. 单元测试
    2. 2.2. 服务端错误手册
  3. 3. 考虑代码复用
  4. 4. 代码审核,必须保证
  5. 5. 服务端评审点