【编码心得】编写接口时的coding思路

---

前言

相信每位程序员都有自己的编码习惯，我也不例外，今天就是随笔畅谈下我平时写代码的习惯
（不喜勿喷—哈哈）

---

提示：以下是本篇文章正文内容，下面案例可供参考

自己平时的编写习惯

1.分层规范

2.代码编写规范

1.sql脚本尽量不使用数据库内置函数，如时间处理，数值处理，隐式转换等，
会造成索引失效，内置函数本身也会消耗数据库性能

2.避免循环查询数据库，循环第三方接口

3.两表join字段必须加索引，并且类型相同

4.不同应用或者不同中间件中属性名称保持统一

5.方法名，接口名，字段名，常量名的定义要准确，不要使用1234或abcd

6.方法体不宜过长，抽取负责同一步骤的代码，如装配请求，返回参数，调用第三方接口等

7.包装类判断相等用equal，不要用==，容易忽略的情况如Integer，Bigdecimal

8.测试代码如mock数据等，或者仍待确认的业务逻辑commit时必须打TODO标签，需求投产前确认项目中TODO已经全部处理

9.每次提交要有明确意义的commit message，告知本次提交的内容

3.主要按照写一个method的思路进行展开

a.创建一个常量值，接受方法名

例子：String methodName = “getTheOrderDetailByOrderId”；

b.日志打印入参信息

例子：Logger.info(Order.class,methodName,inputParams,“查询订单详情，入参：”)

c.创建接收返回值的参数

例子：Map<String ,String> result = new HashMap();

d.直接写上方法的返回值

例子：return result；

e.进行入参的常规校验

例子：StringUtils的isEmpty，isNotBlank

f.进行入参的业务上的定制化校验

例子：各个网站的密码的设置规则不一致

g.try catch，包裹住业务代码

这种是懒人写法，很影响性能，但是很简单，不过不推荐这样写

h.根据业务需求处理对应的异常

catch住自己处理，还是往上层抛，看业务需求

i.日志打印出参信息

例子：Logger.info(Order.class,methodName,inputParams,“查询订单详情，出参：”)

总结

请记住，读代码的时间比写代码的时间多得多。多花时间理清思路，往往更能节省开发时间，注释、细致的解释以及一些示例往往具有不可估量的价值。

我是杰叔叔，一名沪漂的码农，下期再会！