优秀的后端应该有哪些好的开发习惯？（完结）

工作快12年了，前后待过几家公司，碰到各种各样的同事，见识过各种各样的代码，优秀的、垃圾的、不堪入目的、看了想跑路的等等，所以这篇文章记录一下一个优秀的后端 Java 开发应该有哪些好的开发习惯。

希望能给各位工作党的球友一点点帮助，在校的学生党也可以提前感受一下。

拆分目录结构

受传统 MVC 模式的影响，以前的做法大多是几个固定的文件夹 controller、service、mapper、entity，然后无限制添加，到最后你就会发现一个 service 文件夹下面有几十上百个 Service 类，根本没法分清业务模块。

正确的做法是在写 service 上层新建一个 modules 文件夹，在 moudles 文件夹下根据不同业务建立不同的包，在这些包下面写具体的 service、controller、entity、enums 包或者继续拆分。

等以后开发版本迭代，如果某个包可以继续拆领域就继续往下拆，可以很清楚的一览项目业务模块。后续拆微服务也简单。

封装方法形参

当你的方法形参过多时请封装一个对象出来...... 下面是一个反面教材，谁特么教你这样写代码的！

public ResVo list(long customerId, String channelKey,
                   String androidId, String imei, String gaId,
                   String gcmPushToken, String instanceId) {}

写个对象出来：

public ResVo list(@RequestBody ArticlePostReq req, HttpServletResponse response) throws IOException {
}

为什么要这么写？

比如你这方法是用来查询的，万一以后加个查询条件是不是要修改方法？每次加个参数就要改方法参数列表，简直作死。封装个对象，以后无论加多少查询条件都只需要在对象里面加字段就行，而且关键是看起来代码也很舒服啊！

封装业务逻辑

如果你看过“屎山”你就会有深刻的感触，这特么一个方法能写几千行代码，还无任何规则可言......往往负责的人会说，这个业务太复杂，没有办法改善，实际上这都是懒的借口。不管业务再复杂，我们都能够用合理的设计、封装去提升代码可读性。下面贴两段高级开发（假装自己是高级开发）写的代码

@RequestMapping(path = "list")
public ResVo list(@RequestParam(value = "category", required = false) String category,
                                  @RequestParam(value = "tag", required = false) String tag,
                                  @RequestParam(name = "page") Long page,
                                  @RequestParam(name = "size", required = false) Long size) {
    if (StringUtils.isBlank(category) && StringUtils.isBlank(tag)) {
        return ResVo.fail(StatusEnum.ILLEGAL_ARGUMENTS_MIXED, "category|tag miss!");
    }
    size = Optional.ofNullable(size).orElse(PageParam.DEFAULT_PAGE_SIZE);
    size = Math.min(size, PageParam.DEFAULT_PAGE_SIZE);
    Long categ...

真诚点赞诚不我欺

优秀的后端应该有哪些好的开发习惯？（完结）

拆分目录结构

封装方法形参

封装业务逻辑

目录

划线评论