看！这代码像不像一坨屎！

迷南。 2022-10-12 01:53 171阅读 0赞

每天早上七点三十，准时推送干货

### 一、介绍 ###

这么长时间以来，我们一直在介绍各种框架的使用案例包括源码分析，其实都是为了提升我们的综合技能，但是很少关注代码质量的治理。

其实在实际的开发过程中，对于一个开发人员来说，投入时间最多、挑战最大的往往不是新技术的学习，而是历史代码的治理！

为什么我这么说呢？下面我给大家简单的介绍一下，我曾经接手的几个印象特别特别深刻的项目代码！

### 二、案例分享 ###

#### 2.1、某平台入库查询代码 ####

![e8d4914196931fe7f11853b059f5338c.png][]

首先不可否认，这样写查询非常简单，但是对于维护的人，简直苦不堪言！

单纯从技术上来说，这条`SQL`在实际查询的时候非常慢，大约需要 2-3 秒的时间，还不算`service`层的逻辑判断，随着数据量的越来越大，查询只会更慢，继而造成用户体验非常差。

其次从业务层面来说，由于这个查询很多地方都在用，因此当某个页面上需要加点信息的时候，你这个时候，还不能直接在这个`sql`上改东西，还必须一一的熟悉每个字段的含义，然后进行调整测试！

在这个项目里，像这样的代码，大约有 90%，都是这种风格！

如果领导突然让你把它改成单表查询，我相信你会直接翻桌子！我记得我当时直接没理他～～

还有下面的这个查询方法！

![f7729dce5ae1e3cacdcbe678e4aba351.png][]

首先不说别的，就这个代码啊，给人的第一感觉很不好阅读！

可读性很差，里面居然连数据库实体类都不封装一下，直接用`Map`来接受对象，都懒成什么样呢！

这个`map`里面到底有哪些字段呢，包括字段的含义，我基本无从得知，然后我得一行一行的阅读代码。

上面给出的都是一些读数据方面！

下面我再给大家介绍一下写数据方面的。

![669351df70cb0f36fd07027c69a36eda.png][]

这个方法，大概有200多行，主要的逻辑是负责新增或者编辑某个申请计划。

首先劈开业务上面的问题，单纯就这个方法，它就有个致命的漏洞，那就是事务问题，这个方法里面有很多写数据的操作，但是方法上没有加整体事务注解！

这就意味着，如果下面某个方法执行报错，上面的写数据操作不会回滚的！

就这个方法，里面至少写了10张表的数据！

当我第一次处理里面的 bug 的时候，我当时的心情，真的想喷写这个方法的人，可惜他们都走了～～

而且这个工程，像这样的方法，还非常非常的多，大约有80%！

#### 2.2、某平台报表查询 ####

先来看一下，下面这个查询方法！

![f69d6f9b9990f7e5f50b48cb76301015.png][]

这个查询方法是用存储过程写的，里面大概有1000多行！

![92f2cb06002349c59c3ddf40efb969da.png][]

如果要是刚入行的同学，真不是我唬你，估计有可能会被这个给吓到！

通过这样的方式来查询报表，大概有几十个，如果中途需要调整查询结果，会非常痛苦！

直到现在，我还不知道 是哪个 dba 写出这样的 sql，相比常规的查询操作，确实高出一个逼格，弄的我们大家都不敢随便碰！

除了他本人能维护，我想没第二个人敢改这个！

#### 2.3、微服务 api 包互相依赖 ####

在现今的开发过程中，只要搞开发，基本绕不开微服务的话题！

微服务虽好，但是也要用的恰当才行！

在实际的微服务开发中，我们常常这样来划分层次，以订单微服务为例！

将`order`分层两个`jar`，一个是`api`包，另一个是`provider`包

*  `api`包：主要存放服务接口的暴露，包括请求实体类和返回实体类，比较纯粹
 *  `provider`包：主要用于服务接口的实现，包括一些逻辑处理，类似我们传统`web`工程，是一个真正的服务处理工程

其中`provider`包依赖于`api`包，`api`包主要用于对外开放服务接口！

![8859360872951c0ddd38e0a3328f3893.png][]

但是，有的同学会这么干！

![043d1f4e7b0033e3a09274579f38267b.png][]

在启动`order`服务或者`stock`的时候，工程会报`jar`包冲突，工程存在循环依赖的问题！

原因也很简单，`order-api`包依赖`stock-api`，然后`stock-api`又依赖`order-api`，导致`order-api`依赖`order-api`，最后就变成了循环依赖！

正确的做法应该是由`provider`工程来依赖，而不是`api`包来依赖！

![53805a5e5f1c63a013b3c1b203fb48d5.png][]

`api`层的`jar`包，不依赖任何其他的业务微服务`jar`包，只是单纯的提供服务接口的暴露，类似一个纯接口调用包，千万别理解错了哦！

### 三、小结 ###

在实际的开发过程中，对于代码的治理，我们和团队的其他成员，一定要事先一起制定好开发规范和标准，尽量避免无效的代码、可读性差的代码、甚至维护起来麻烦的代码在里面存活！这样整个团队的开发效率才会大大的增加！自己维护起来也更加顺手！

尤其是上面第2.2部分介绍的，严禁在项目中搞那种非常复杂的查询方式，这样会直接导致很多第一次接手的人根本无法维护，假如写这个脚本的人突然走了，突然后期的任务正好也分给你，那就真的很困难了！

在实际的规范定义中，我们应该尽可能的遵守一下几点！

*  模块层次清晰
 *  对各模块功能，进行解耦，避免耦合在一起
 *  面向接口编程
 *  尽量少用继承，继承会导致关系错中复杂，容易出问题
 *  尽可能单表查询，能不链表就别链表，当一个表如果要被分库分表的时候，之前的链表逻辑，基本都要改
 *  每个数据实体类必须与数据库中的表字段一一对应，禁止加无关的字段进去，否则不利于后期代码优化、重构

一切的目标，其实很简单，尽可能的让一个实习生都能上手开发，而不是搞那种非常复杂的编程方案！

< END >

告诉大家一个好消息，Java极客技术读者交流群（摸鱼为主），时隔 2 年后再次开放了，感兴趣的朋友，可以在公号回复：**999**

![ea797934d483dd6ec0090a58929e38c2.png][]

**喜欢就****分享**

**认同就****点赞**

**支持就****在看**

**一键四连，你的offer也四连**![35fcb36ddba743b67731bef4822a397b.gif][]

[e8d4914196931fe7f11853b059f5338c.png]: /images/20221005/6b946faa1e3c41cdac652ed7e8e485f6.png
[f7729dce5ae1e3cacdcbe678e4aba351.png]: /images/20221005/c766a4cc75024495a9c640de8353e85e.png
[669351df70cb0f36fd07027c69a36eda.png]: /images/20221005/f90152f6dc0f44698849e442aa1fc5f1.png
[f69d6f9b9990f7e5f50b48cb76301015.png]: /images/20221005/04ba7f9915f349018af4ba99c2c006c8.png
[92f2cb06002349c59c3ddf40efb969da.png]: /images/20221005/38e736b9435a43aa83cb5542b5e9e630.png
[8859360872951c0ddd38e0a3328f3893.png]: /images/20221005/d90f4067004048dd8b978b789221b793.png
[043d1f4e7b0033e3a09274579f38267b.png]: /images/20221005/295f14390b9d44b8a60d44c0b1b047fa.png
[53805a5e5f1c63a013b3c1b203fb48d5.png]: /images/20221005/7270674c36a849caab1d784613ff310d.png
[ea797934d483dd6ec0090a58929e38c2.png]: /images/20221005/9822d94642be41a49595192f8a6955e2.png
[35fcb36ddba743b67731bef4822a397b.gif]: /images/20221005/5e7e60ac865e4cd6808184ff24b79f72.png