编码规范(一)

生命在凋谢,一如白蛾扑火般惨烈。命运又轮回,化作破茧成蝶的喜悦! ——白子

后端Java开发规范

  • 接口定义
    • 常见问题
      • 返回格式不统一
        • 格式不统一
      • 不考虑失败的情况
        • void 返回值
      • 出现和业务无关的输入参数
      • 出现复杂的输入参数
        • 传参为Json格式
      • 没有返回应该返回的数据
      • 定义ResultBean
        • code
        • message
        • result
        • data
  • Controller 规范
    • 所有函数返回统一的ResultBean、PageResultBean
    • ResultBean/PageResultBean是controller专用的,不允许往后传
    • Controller 做参数格式的转换,不允许把Json,Map对象转到Service去,不允许Service返回Json,Map
    • 参数中一般情况下不允许出现Request,Response
    • 不需要打日志
      • 日志在AOP里面会打印,大部分日志在Services这层打印
    • AOP代码,主要就是打印日志和捕获异常,异常要区分已知异常和未知异常,其中未知的异常时我们重点关注的,可以做一些邮件通知啥的
    • 返回统一的一个ResultBean
      • 统一格式
      • 应用AOP
      • 为了包装异常信息
  • 日志规范
    • 日志的基本要求:
      • 能找到那个机器
      • 能找到次步用户做什么操作
    • 找到机器
      • 针对第一点在 nginx 中设置
        add_header X-Slave $upstream_addr
    • 找到对应的用户
      • 使用filter将用户的信息,放到数据filter中,使用的事 log4j 日志
      • filter中得到用户信息,并放入MDC,记住filter后要清理掉(因为Tomcat线程池线程重用的原因)
    • 对于开发人员的日志有3点要求
      • 修改(包括新增)操作必须打印日志
        • 大部分问题都是修改导致的,数据修改必须有据可查
      • 条件分支必须打印条件值,重要参数必须打印
        • 尤其是分支条件的参数,打印后就不用分析和猜测那个分支了,
      • 数据量大的时候需要打印数据量
        • 前后打印日志和最后的数据量,主要用于分析性能,能从日志中查询了多少数据用多久
      • 建议
        • 尽量不依赖debug,多依赖日志
        • 代码开发测试完成之后,不要着急提交,先跑一边看看日志时候看得懂
  • 异常处理
    • 对于觉得大多部分场景,不允许捕获异常,不要乱加空判断。
    • 只有明显不需要关心的异常,如关闭资源的时候的IO异常,可以捕获然后什么都不干。
    • 其他情况不允许捕获异常,都抛出去,到Controller处理。
    • 空判断大部分时候不需要,你如果写了空判断,你就必须测试为空和不为空两种场景,要么就不要写空判断。
      • 强调,有些空判断是需要的,如:参数是用户输入的情况下
    • 总结:
      • 开发组长定义好异常,异常继承 RuntimeException
      • 不允许开发人员捕获异常,(异常上对开发人员这点要求,异常都抛出到Controller上用AOP处理)
      • 后台异常一定要有通知机制,要第一时间知道异常
      • 少加空判断,加了空判断就要测试为空的场景
  • 参数校验和国际化规范
    • 业务代码里面不要出现和业务无关的东西,如 local,MessageSource
    • 主要还是使用工具类ThreadLocal进行操作
  • 工具类规范
    • 定义自己的工具类,尽量不要在业务代码中里面直接调用第三方的工具类
      • 不同的人会使用不同的第三方工具库,会比较乱
      • 将来万一要修改工具类实现逻辑会很痛苦
    • 最好的建议就是自己使用工具类,进行简单自定义需求的逻辑封装,最终达到的效果就是最底层的实现改变,上层调用的工具类方法不用改变
    • 使用父类、接口
      • 就是当我们写完工具类的时候,对于参数我们是否可以泛化,将参数泛化到父类,
      • 思路是抽象的思想,主要是修改参数类型,方法就是往上找父类/接口,一直找到顶为止,记得修改参数名
    • 使用重载编写衍生函数组
      • 多想一步,根据参数变化编写各种类型的入参函数,需要保证函数主要代码只有一份
      • 对于代码中关键参数可以抽象出来,对于针对参数的多种类型可以衍生
    • 物理独立存放
      • 习惯将和业务无关的代码存放到独立的工程或者目录,
  • 函数编写规范
    • 不要出现和业务无关的参数
    • 避免使用Map,Json这些复杂的数据对象作为参数和结果
    • 有明确的输入和输出方法名
    • 把可能变化的地方封装成函数
      • 编写函数的总体指导思想是抽象和封装,你要把代码的逻辑抽象出来封装成为一个函数,以应对将来可能的变化。
      • 以后代码逻辑有变更的时候,单独修改和测试这个函数即可。
    • 编写能测试的函数
      • 不要出现乱七八糟的参数
      • 你要把函数写小一点
      • 你要有单独测试每个函数的习惯
    • 一句话:使用简单参数,不要出现和业务无关的参数,把可能变化的地方都写出独立的函数,力求每一个函数都可以单独测试。


文章作者: Asxing
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 Asxing !
评论
  目录