如何优雅的编写业务代码

编码规范

Controller规范

Controller层负责调度作用，统一返回的结果集，Result或者String模板资源。

• Controller做参数格式的转换，不允许把json，map这类对象传到services去，也不允许services返回json、map。map，json这种格式灵活，但是可读性差（ 编码一时爽，重构火葬场）。如果放业务数据，每次阅读起来都十分困难，需要从头到尾看完才知道里面有什么，是什么格式。定义一个bean看着工作量多了，但代码清晰多了。
• 参数不允许出现Request，Response 这些对象，和json/map一样，主要是可读性差的问题。一般情况下不允许出现这些参数，除非要操作流。
• 不需要打印日志，日志在Services这层打印。

Service规范

service层负责核心的业务逻辑层，每个函数的参数一定要明确，不建议传入json、map这样的参数，目的是看到这个函数以及参数就知道它是干什么的，提升可读性。不要出现和业务无关的参数。

日志

• 修改、删除等操作，最好打印日志，供线上排查问题（大部分问题都是修改导致的。数据修改必须有据可查。）。
• 条件分支必须打印条件值，重要参数必须打印（尤其是分支条件的参数，打印后就不用分析和猜测走那个分支了，很重要！ ）。
• 代码开发测试完成之后不要急着提交，先跑一遍看看日志是否看得懂。

注释

注释：函数参数一定要注释用意，函数中重要变量也需要加注释。

换行：代码段中功能语义之间最好加换行，增加可读性。

下面是一个排序函数的不建议示范：

/**
 * 冒泡排序 <<!! 不建议示范 >>
 * @param arr
 * @return
 */
public int[] sort(int[] arr){
    for (int i = 0; i < arr.length; i++) {
        boolean flag = false;
        //依次比较，将较小的数进行交换
        for (int j = 0; j < arr.length-i-1; j++) {
            if (arr[j]>arr[j+1]){
                int temp = arr[j];
                arr[j] = arr[j+1];
                arr[j+1] = temp;
                flag = true;
            }
        }
        if (!flag){
            break;
        }
    }
    return arr;
}

建议示范：

/**
 * 冒泡排序 << 建议示范 >>
 * @param arr
 * @return
 */
public int[] sort(int[] arr){
    for (int i = 0; i < arr.length; i++) {
        // 数据交换确认标记
        boolean flag = false;

        // 依次比较，将较小的数进行交换
        for (int j = 0; j < arr.length-i-1; j++) {
            if (arr[j]>arr[j+1]){
                int temp = arr[j];
                arr[j] = arr[j+1];
                arr[j+1] = temp;
                flag = true;  // 表示有数据交换
            }
        }

        // 没有数据交换，提前退出
        if (!flag){
            break;
        }
    }
    return arr;
}

其中，建议示范中主要有几点：

• 重要变量注释
• 注释符号后面加空格，增加可读性
• 语义分段，在合适的位置加换行，增加可读性

工具类

一个项目不可能没有工具类，工具类的初衷是良好的，代码重用，但到了后面工具类越来越乱，有可能同样的工具类就有好几个，看的眼花缭乱，还有不少重复。所以建议：

• 就是要定义自己的工具类，尽量不要在业务代码里面直接调用第三方的工具类。这也是解耦的一种体现。
• 在准备添加工具类时，先看下现有工具类中是否存在同类型的，如果存在，有限扩展工具类。

数据库

库名、表名、字段名：小写，下划线风格，不超过32个字符，必须见名知意，禁止拼音英文混用。

数据表、数据字段必须加入中文注释（数据库文档更新不及时，N年后谁知道这个r1,r2,r3字段是干嘛的）

表设计：

• 表必须有主键，例如自增主键
• 单表列数目必须小于30
• 禁止使用外键，如果有外键完整性约束，需要应用程序控制

字段设计：

• 必须把字段定义为NOT NULL并且提供默认值
• 禁止存储大文件或者大照片

索引设计：

• 单表索引建议控制在5个以内
• 单索引字段数不允许超过5个（字段超过5个时，实际已经起不到有效过滤数据的作用了）
• 禁止在更新十分频繁、区分度不高的属性上建立索引 （区分度不搞是指，例如性别这类字段就不用建立索引了）

SQL 规范：

• 禁止使用SELECT *，只获取必要的字段，需要显示说明列属性
• 禁止使用INSERT INTO t_xxx VALUES(xxx)，必须显示指定插入的列属性
• 禁止在WHERE条件的属性上使用函数或者表达式（会导致全盘扫描，有索引也会失效）
• 禁止大表使用JOIN查询，禁止大表使用子查询（会产生临时表，消耗较多内存与CPU，极大影响数据库性能）

Git提交

提交前，先更新，避免出现冲突问题额外花更多的时间解决冲突。

提交时，注释一定要写清楚，不要写不明确的备注（如优化、完善等内容）。

如何应对需求变更

先看个程序员的段子娱乐一下 ：

客户被绑，蒙眼，惊问：“想干什么?”
对方不语，鞭笞之，客户求饶：“别打，要钱?”
又一鞭，“十万够不?”
又一鞭，“一百万?”
又一鞭。客户崩溃：“你们TMD到底要啥?”
“要什么?我帮你做项目，写代码的时候也很想知道你TMD到底想要啥!”

有没有可能存在明确的、不再改动的需求呢？其实很难的。 现在我们属（lei）于（si）敏捷开发模式，文档大量简化（几乎没有），于是需求没有考虑清楚就开始开发，需求是边开发边变动。 敏捷开发模式间接变成了加班开发模式。

如何应对？

⭐ 最起码的要求，把代码写到最简单。改1行简单代码和改10行复杂代码，工作量是不一样的！测试一个20行的函数和测试一个3、5行的函数工作量是不一样的！

⭐ 把可能变化的封装成函数。

⭐ 先做确定的需求。多个功能中先做不会变的功能，一个功能中先做不会变的部分，兵法中叫攻其必救之地。

⭐ 解耦。解耦是编程里面重要的思想，解耦的关键在于：多引入“第三者”，不要直接发生关系。

⭐ 主动思考。就像下棋一样，主动思考，多走一步，不要被动接受看到的需求，要对需求的将来变化做好心中有数。

配图：挪威，罗弗敦群岛

作者： Zealon
崇尚简单，一切简单自然的事物都是美好的。