网站建设基础教程人教版,做网站怎么赚流量,百度网站考核期,WordPress二维码动态图片JAVA代码规范审查 1. 添加必要的注释 所有的类都必须添加创建者和创建日期#xff0c;以及简单的注释描述 方法内部的复杂业务逻辑或者算法#xff0c;需要添加清楚的注释 一般情况下#xff0c;注释描述类、方法、变量的作用 任何需要提醒的警告或TODO#xff0c;也要注…JAVA代码规范审查 1. 添加必要的注释 所有的类都必须添加创建者和创建日期以及简单的注释描述 方法内部的复杂业务逻辑或者算法需要添加清楚的注释 一般情况下注释描述类、方法、变量的作用 任何需要提醒的警告或TODO也要注释清楚 如果是注释一行代码的就用//;如果注释代码块或者接口方法的有多行/* **/ 一块代码逻辑如果你站在一个陌生人的角度去看,第一遍看不懂的话,就需要添加注释了
/*** author 田螺* date 2023/04/22 5:20 PM* desc 田螺的实现类捡田螺、卖田螺 更多干货关注公众号捡田螺的小男孩*/
public class TianLuoClass {/*** 这是卖田螺的两法它将两个田螺的价格整数相加并返回结果。* * param x 第一个整数* param y 第二个整数* return 两个整数的和*/public int sellTianLuo(int x, int y) {return x y;}
}
2.日志打印规范 日志级别选择不对。常见的日志级别有error、warn、info、debug四种不要反手就是info哈 日志没打印出调用方法的入参和响应结果尤其是跨系统调用的时候。 业务日志没包含关键参数,如userId,bizSeq等等,不方便问题排查 如果日志包含关键信息比如手机号、身份证等需要脱敏处理 一些不符合预期的情况如一些未知异常数据库的数据异常等又或者不符合业务预期的特殊场景都需要打印相关的日志
3. 命名规范 类和接口应该使用首字母大写的驼峰命名法 方法和变量应该使用小写的驼峰命名法 常量应该使用全大写字母和下划线 开发者是不是选择易于理解的名称给变量、类和方法进行命名
4.参数校验
我们代码评审的时候要注意参数是否都做了校验如userId非空检查、金额范围检查、userName长度校验等等。一般我们在处理业务逻辑的时候要遵循先检查、后处理的原则。
5. 判空处理 获取对象或列表的属性时都要判空处理。要不然很多时候会出现空指针异常。
6. 异常处理规范 不要捕获通用的Exception异常而应该尽可能捕获特定的异常 在捕获异常时应该记录异常信息以便于调试 内部异常要确认最终的处理方式避免未知异常当作失败处理。 在finally块中释放资源或者使用try-with-resource 不要使用e.printStackTrace(),而是使用log打印。 catch了异常要打印出具体的exception否则无法更好定位问题 捕获异常与抛出异常必须是完全匹配或者捕获异常是抛异常的父类 捕获到的异常不能忽略它要打印相对应的日志 注意异常对你的代码层次结构的侵染早发现早处理 自定义封装异常不要丢弃原始异常的信息Throwable cause 注意异常匹配的顺序优先捕获具体的异常 对外提供APi时要提供对应的错误码 系统内部应该抛出有业务含义的自定义异常而不是直接抛出RuntimeException或者直接抛出Exception\Throwable。
7. 模块化可扩展性
代码编写设计是否满足模块化接口是否具有可扩展性
8. 并发控制规范 在使用并发集合时应该注意它们的线程安全性和并发性能,如ConcurrentHashMap是线性安全的,HashMap就是非线性安全的 乐观锁,悲观锁防止数据库并发.乐观锁一般用版本号version控制,悲观锁一般用select …for update 如果是单实例的多线程并发处理,一般通过Java锁机制,比如sychronized ,reentrantlock 如果是同一集群的多线程并发处理,可以用Redis分布式锁或者走zookeeper 如果是跨集群的多线程并发处理,则考虑数据库实现的分布式锁。 在使用分布式锁的时候,要注意有哪些坑,比如redis一些经典的坑.
9. 单元测试规范 测试类的命名,一般以测试的类Test,如:CalculatorTest. 测试方法的命名,一般以test开头 测试的方法,如testAdd. 单测行覆盖率一般要求大于75%. 单测一般要求包含主流程用例、参数边界值等校验用例 单测一般也要求包含中间件访问超时、返回空、等异常的用例,比如访问数据库或者Redis异常. 单测用例要求包含并发、防重、幂等等用例.
10. 代码格式规范 缩进使用四个空格 代码块使用花括号分隔 每行不超过80个字符 每个方法应该按照特定的顺序排列例如类变量、实例变量、构造函数、公共方法、私有方法等。
11. 接口兼容性
重点关注是否考虑到了接口的兼容性
12. 程序逻辑是否清晰,主次是否够分明
程序逻辑是否清晰。可以划分主次抽一下小函数。
13. 安全规范 输入校验应该始终对任何来自外部的输入数据进行校验以确保它们符合预期并且不会对系统造成伤害。校验应该包括检查数据的类型、大小和格式。 防范SQL注入攻击:在使用SQL查询时应该始终使用参数化查询或预处理语句以防止SQL注入攻击。 防范跨站脚本攻击XSS: 在Web应用程序中应该始终对输入的HTML、JavaScript和CSS进行校验并转义特殊字符以防止XSS攻击。 避免敏感信息泄露: 敏感信息如密码、密钥、会话ID等应该在传输和存储时进行加密以防止被未经授权的人访问。同时应该避免在日志、调试信息或错误消息中泄露敏感信息。 防范跨站请求伪造CSRF: 应该为所有敏感操作如更改密码、删除数据等添加CSRF令牌以防止未经授权的人员执行这些操作。 防范安全漏洞: 应该使用安全性高的算法和协议如HTTPS、TLS来保护敏感数据的传输和存储并定期对系统进行漏洞扫描和安全性审计。
14. 事务控制规范 一般推荐使用编程式事务而不是一个注解 Transactional的声明式事务。因为 Transactional有很多场景可能导致事务不生效。 事务范围要明确数据库操作必须在事务作用范围内如果是非数据库操作尽量不要包含在事务内。 不要在事务内进行远程调用可能导致数据不一致比如本地成功了但是远程方法失败了这时候需要用分布式事务解决方案 事务中避免处理太多数据一些查询相关的操作尽量放到事务之外避免大事务问题
15. 幂等处理规范
幂等表示一次和多次请求某一个资源应该具有同样的副作用或者说多次请求所产生的影响与一次请求执行的影响效果相同。
关注接口是否考虑幂等。比如开户接口多次请求过来的时候需要先查一下该客户是否已经开过户如果已经开户成功直接返回开户成功的报文。如果还没开户就先开户再返回开户成功的报文。这就是幂等处理。
一般情况有这几种幂等处理方案 selectinsert主键/唯一索引冲突 直接insert 主键/唯一索引冲突 状态机幂等 抽取防重表 token令牌 悲观锁 乐观锁 分布式锁
幂等要求有个唯一标记比如数据库防重表的一个业务唯一键。同时强调多次请求和一次请求所产生影响是一样的。
16. 中间件注意事项 数据库redis
如果用数据库、Redis、RocketMq等的中间件时我们需要关注这些中间件的一些注意事项哈。
比如数据库 关注数据库连接池参数设置、超时参数设置是否合理 避免循环调用数据库操作 如果不分页查询SQL时如果条数不明确是否加了limit限制限制 数据库的返回是否判空处理 数据库慢SQL是否有监控 表结构更新是否做兼容存量表数据是否涉及兼容问题考虑 索引添加是否合理 是否连表过多等等
比如Redis: Redis的key使用是否规范 Redis 异常捕获以及处理逻辑是否合理 Redis连接池、超时参数设置是否合理 Redis 是否使用了有坑的那些命令如hgetall、smember 是否可能会存在缓存穿透、缓存雪奔、缓存击穿等问题。
17. 注意代码坏味道问题 大量重复代码抽公用方法设计模式 方法参数过多可封装成一个DTO对象 方法过长抽小函数 判断条件太多优化if...else 不处理没用的代码没用的import 避免过度设计
18. 远程调用 不要把超时当作失败处理: 远程调用可能会失败比如网络中断、超时等等。开发者需要注意远程调用返回的错误码除非是明确的失败如果仅仅是超时等问题不能当作失败处理而是应该发起查询确认是否成功再做处理。 异常处理远程调用可能会抛出异常例如由于服务端错误或请求格式不正确等。因此开发人员需要确保能够捕获和处理这些异常以避免系统崩溃或数据丢失。 网络安全由于远程调用涉及网络通信因此开发人员需要考虑网络安全的问题例如数据加密、认证、访问控制等。尽可能使用安全的协议例如HTTPS 或 SSL/TLS。 服务质量远程调用可能会影响系统的性能和可用性。因此开发人员需要确保服务的质量例如避免过度使用远程调用、优化数据传输、实现负载均衡等。 版本兼容由于远程调用涉及不同的进程或计算机之间的通信因此开发人员需要注意服务端和客户端之间的版本兼容性。尽可能使用相同的接口和数据格式避免出现不兼容的情况。 尽量避免for循环远程调用: 尽量避免for循环远程调用而应该考虑实现了批量功能的接口。
