代码开发/review中注意事项

在代码开发中，或者codereview中，我们经常能看到各种问题，如何能全面考虑、减少依赖考虑因素。为了这个目的，把工作中的经验整理如下：

代码规范：

• 核心功能代码注释是否完整、逻辑是否清晰。
• 自定义的sql是否放到selfxml中。
• 自定义的selfxml中不应该重写原生BaseResultMap。
• 接口的返回是否符合规范：
  • 写操作一般都POST请求。多参数一般是application/json数据方式[文件是multipart/form-data]
  • 读操作一般是GET请求。
  • 返回值是否都封装成统一规范格式。
  • 返回code是否在规范的范围内
• 是否存在一个方法大代码块的情况（需要拆分成小模块，方便复用和维护）。
• try…catch是否还存在错误信息直接打印而不log记录的情况。
• 业务调整或升级，作废的代码是否注释作废提醒。

备注： 
1：使用的mybatis的DAO层，区分了反射生产的xxxXml和自定义sql存放的xxxSelfXml
2：一般接口的返回值都是定义成：
public class JsonResult<T> {
	private int code;	//返回code 可以用枚举更好
	private String message;	//返回消息
	private T data; //返回数据
}

在code的设定上，可细可粗。具体把握根据具体业务而来。前期建议不要过细，会增加后续调整难度。一般来说以下几种足够，具体说明可以放到message中即可：

static int OK = 200;	//成功
static int NO_LOGIN = -401; //未登录
static int EXCEPTION = 500;	//异常
static int PARAM_MISS = 1001;	//参数缺失
static int PARAM_ILLEGAL = 1002; //参数非法/格式不正确/验证不通过等
static int DATA_UNFIND = 1101; //未找到数据/查询无信息/某某数据不存在
static int ACCESS_NO = 1201; //没有权限
static int OPERATE_CANNOT = 1301; //不能操作/不能修改（因为某种限制或状态，不能进行操作或修改）
static int SERVICE_FAILURE = 1401; //调用依赖服务失败（调用别的项目服务时失败）

服务调用：

• 是否正确评估调用的服务核心程度，调用服务的失败是否要影响自己业务的进行。
• 核心的调用服务，是否添加了日志记录，方便后续排除问题时使用。
• 某个方法中调用外部服务，这个方法的事务性是否对于外部服务有影响。
• 正确评估调用外部服务的实时性要求程度。是否可以异步消息方式处理。
  • 异步时，是否考虑失败情况如何处理，是否存在补救措施。

备注： 
1：发现本地方法的事务还没有提交，所调用的外部服务中就要从数据库查询，导致数据问题。

安全性：

• 存在SQL注入。
• XSS（跨站脚本漏洞）。
• CSRF（跨站请求伪造）。
• 恶意代码执行（文件包含漏洞/文件上传验证不充分）。
• 整型自动拆箱/装箱问题
• 数据安全性
  • 隐私数据是否明文存储了
  • 是否存在越权的漏洞（可以查看不是自己的某些详情页面|可以对不是我的数据进行操作）。
  • 是否是弱密码

查询性能：

• 列表查询是否考虑到业务增加，数据量增加的情况。
• 字段属性是否值得添加索引（尽量能确定唯一性的）。
• 表的索引是否太多，是否可以调整组合索引。
• 是否考虑到主从同步延迟对于业务功能的影响。
• 是否考虑到事务的特性。

需求评估：

• 业务功能涉及调整时，对于涉及调整的旧功能、以及影响范围是否充足了解。
• 业务功能涉及调整时，是否存在新老版本共存的情况。
• 对于需求，是否在脑海中形成了大致完整的架构设计、开发难度程度、耗时多少等等。
• 对于需求的背景和本质是否了解？在成本收益上是否值得？是可以换种实现方式，来到达现有的功能最小调整满足需求？