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

Posted 微笑很纯洁

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了看!这代码像不像一坨屎!相关的知识,希望对你有一定的参考价值。

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

一、介绍

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

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

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

二、案例分享

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 >

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

喜欢就分享

认同就点赞

支持就在看

一键四连,你的offer也四连

以上是关于看!这代码像不像一坨屎!的主要内容,如果未能解决你的问题,请参考以下文章

如何避免自己写的代码成为别人眼中的一坨屎 (摘自微信公众号,顶级程序员)

function造方法向纽约扔一坨屎

stm32正点原子和普中或是野火哪个好?

缠成一坨的耳机线,这机器人两下就能解开

如何写优雅的代码

禅者初心