- 不要 git 多余文件,不要带有测试代码,无用代码
- 明确需求,明确接口入参和结果,前端要考虑用户体验
- 思考解决方案
- 以第一个需求为例: jcredit 建表,生成代码,接入前端,可从前端输入并存入缓存和数据库中 credit 写接口,传入 code,type,token,用传参 code + type 读取缓存或数据库,得到匹配 token,比对传入 token 返回true false,不要简单问题复杂化
- String 对象不可变,需要对字符串进行重复修改的时候,String的开销很大,不考虑线程安全的情况优先使用 StringBuilder
- ---阿里规范【推荐】循环体内,字符串的连接方式,使用StringBuilder的append方法进行扩展。 说明:下例中,反编译出的字节码文件显示每次循环都会new出一个StringBuilder对象,然后进行append操作,最后通过toString方法返回String对象,造成内存资源浪费。 反例: String str = "start"; for (int i = 0; i < 100; i++) { str = str + "hello"; }
- 空值处理,空值判断前置,尽量避免代码执行无效
- 有关 NPE,建议防御式编程,方法可以返回 null,不强求返回空集合或空数组,但是返回 null 的时候一定要再注释明确什么情况会出现 null
- if 判断的时候用正逻辑,isEmpty(),== null,易于阅读
- 单元测试统一,不要放置测试接口到生产环境,基本的测试情况要多考虑
- 明确 controller service dao 层次
- 校验操作,优先在 controller 层写,service 层可能会给其他 controller 用
- redis 的 key 要清晰,明确项目,服务
-
eg:
new StringBuilder("creditManage:query:auth:").append(businessType).append(":").append(businessCode).toString();
-
- sql 中有关类型的字段描述不建议写数字,再实际代码中容易出现魔法值,建议写清楚的命名
- 打印日志不要太频繁,要遵循一定格式
- eg:
log.info("### serviceName methodName description result:{}", result);
- 入参出参一定要打印
- catch 时打印 e,最终堆栈信息
- 哪里会出错一定要log写清楚,对外根据需求可以统一报有错就完事
- log写清楚 "### 服务名 方法名 描述 结果"
- eg:
- String 的 equals 用 org.apache.commons.lang 的 StringUtils.equals();List 判断是否为空用 isEmpty()
- 注意有些参数写配置文件
- 注意注意注意业务需求,不要太纠结表null 问题
- again,无用代码删除,接入外部的模块也要保证代码规范
Q.E.D.
Comments | 0 条评论