看！这代码像不像一坨屎！
一、介绍
这么长时间以来，我们一直在介绍各种框架的使用案例包括源码分析，其实都是为了提升我们的综合技能，但是很少关注代码质量的治理。
其实在实际的开发过程中，对于一个开发人员来说，投入时间最多、挑战最大的往往不是新技术的学习，而是历史代码的治理！
为什么我这么说呢？下面我给大家简单的介绍一下，我曾经接手的几个印象特别特别深刻的项目代码！
二、案例分享
2.1、某平台入库查询代码
首先不可否认，这样写查询非常简单，但是对于维护的人，简直苦不堪言！
单纯从技术上来说，这条SQL在实际查询的时候非常慢，大约需要 2-3 秒的时间，还不算service层的逻辑判断，随着数据量的越来越大，查询只会更慢，继而造成用户体验非常差。
其次从业务层面来说，由于这个查询很多地方都在用，因此当某个页面上需要加点信息的时候，你这个时候，还不能直接在这个sql上改东西，还必须一一的熟悉每个字段的含义，然后进行调整测试！
在这个项目里，像这样的代码，大约有 90%，都是这种风格！
如果领导突然让你把它改成单表查询，我相信你会直接翻桌子！我记得我当时直接没理他～～
还有下面的这个查询方法！
首先不说别的，就这个代码啊，给人的第一感觉很不好阅读！
可读性很差，里面居然连数据库实体类都不封装一下，直接用Map来接受对象，都懒成什么样呢！
这个map里面到底有哪些字段呢，包括字段的含义，我基本无从得知，然后我得一行一行的阅读代码。
上面给出的都是一些读数据方面！
下面我再给大家介绍一下写数据方面的。
这个方法，大概有200多行，主要的逻辑是负责新增或者编辑某个申请计划。
首先劈开业务上面的问题，单纯就这个方法，它就有个致命的漏洞，那就是事务问题，这个方法里面有很多写数据的操作，但是方法上没有加整体事务注解！
这就意味着，如果下面某个方法执行报错，上面的写数据操作不会回滚的！
就这个方法，里面至少写了10张表的数据！
当我第一次处理里面的 bug 的时候，我当时的心情，真的想喷写这个方法的人，可惜他们都走了～～
而且这个工程，像这样的方法，还非常非常的多，大约有80%！
2.2、某平台报表查询
先来看一下，下面这个查询方法！
这个查询方法是用存储过程写的，里面大概有1000多行！
如果要是刚入行的同学，真不是我唬你，估计有可能会被这个给吓到！
通过这样的方式来查询报表，大概有几十个，如果中途需要调整查询结果，会非常痛苦！
直到现在，我还不知道 是哪个 dba 写出这样的 sql，相比常规的查询操作，确实高出一个逼格，弄的我们大家都不敢随便碰！
除了他本人能维护，我想没第二个人敢改这个！
2.3、微服务 api 包互相依赖
在现今的开发过程中，只要搞开发，基本绕不开微服务的话题！
微服务虽好，但是也要用的恰当才行！
在实际的微服务开发中，我们常常这样来划分层次，以订单微服务为例！
order
|- api（所属目录：src/main/java）
| |- request(请求实体包)
| |- response(返回实体包)
| |- enums(字典枚举包)
| |- api (服务暴露接口包)
|
|- provider（所属目录：src/main/java）
| |- constant(常量类包)
| |- entity(数据表字段映射实体类包)
| |- dao(数据操作类包)
| |- service(服务操作类包)
| |- api(服务暴露实现类包)
|
|- provider（所属目录：src/main/resouces）
| |- mapper(存储数据操作配置文件)
| |- application.properties（全局配置文件）
| |- application-dev.properties（开发环境配置文件）
将order分层两个jar，一个是api包，另一个是provider包
api包：主要存放服务接口的暴露，包括请求实体类和返回实体类，比较纯粹provider包：主要用于服务接口的实现，包括一些逻辑处理，类似我们传统web工程，是一个真正的服务处理工程
其中provider包依赖于api包，api包主要用于对外开放服务接口！
但是，有的同学会这么干！
在启动order服务或者stock的时候，工程会报jar包冲突，工程存在循环依赖的问题！
原因也很简单，order-api包依赖stock-api，然后stock-api又依赖order-api，导致order-api依赖order-api，最后就变成了循环依赖！
正确的做法应该是由provider工程来依赖，而不是api包来依赖！
api层的jar包，不依赖任何其他的业务微服务jar包，只是单纯的提供服务接口的暴露，类似一个纯接口调用包，千万别理解错了哦！
三、小结
在实际的开发过程中，对于代码的治理，我们和团队的其他成员，一定要事先一起制定好开发规范和标准，尽量避免无效的代码、可读性差的代码、甚至维护起来麻烦的代码在里面存活！这样整个团队的开发效率才会大大的增加！自己维护起来也更加顺手！
尤其是上面第2.2部分介绍的，严禁在项目中搞那种非常复杂的查询方式，这样会直接导致很多第一次接手的人根本无法维护，假如写这个脚本的人突然走了，突然后期的任务正好也分给你，那就真的很困难了！
在实际的规范定义中，我们应该尽可能的遵守一下几点！
- 模块层次清晰
- 对各模块功能，进行解耦，避免耦合在一起
- 面向接口编程
- 尽量少用继承，继承会导致关系错中复杂，容易出问题
- 尽可能单表查询，能不链表就别链表，当一个表如果要被分库分表的时候，之前的链表逻辑，基本都要改
- 每个数据实体类必须与数据库中的表字段一一对应，禁止加无关的字段进去，否则不利于后期代码优化、重构
一切的目标，其实很简单，尽可能的让一个实习生都能上手开发，而不是搞那种非常复杂的编程方案！
< END >