专栏首页纯洁的微笑看!这代码像不像一坨屎!

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

一、介绍

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

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

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

二、案例分享

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 >

本文分享自微信公众号 - 纯洁的微笑(keeppuresmile),作者:鸭血粉丝

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-07-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 掏了一把祖传代码,屎山!

    凑近了一看,在不净的框架中,乱码般的语句在运转,像生了麻风病的蛞蝓一样在喷吐,粘稠的水在流动,而穿着格子衫的人群则在焰柱旁围成了一个半圆,这就是码农的仪式。他们...

    程序员小浩
  • 为了不让代码看起来像一坨* 我在工作中反复用了这个

    大多数时候我都是写一些业务代码,可能一堆CRUD就能解决问题,但是这样的工作对技术人的提升并不多,如何让自己从业务中解脱出来找到写代码的乐趣呢,我做过一些尝试,...

    用户2781897
  • 如何写出优秀的代码

    写了太多屎一样的代码,终于不臭了!更多精彩文章请关注公众号『Pythonnote』或者『全栈技术精选』

    小闫同学啊
  • 别忘了你的知识产权

    昨晚微信终于给我开通了原创和评论的内测功能,所以今天写篇文章来测试下看看,如果你有幸看到了这篇文章,那么恭喜你!你将有希望抢到「猫哥学前班」有史以来的第一个官方...

    猫哥学前班
  • 噢,你的代码像一坨翔。然后呢?

    陶文,ThoughtWorks毕业生,从事过软件开发,敏捷咨询,项目管理,测试研发,运维平台等多个领域的工作。曾任滴滴出行平台技术部首席架构师,现从事滴滴的平台...

    张逸
  • 自己动手写一个PHP组件

    许杨淼淼
  • 那些牛叉无比的评审风格

    我们可以见到许多有意思的编程风格,又没有精神为之一振的感觉,仿佛里面的例子就在自己身上,或者离自己很近。其实,对于文档、代码的评审,也是有诸多风格可言的,我这里...

    MavenTalker
  • 项目中Dao,Service,Controller,Util,Model是什么意思,为什么划分?

    对的,这种感受是绝对不会错的。而我们要做的就是把这团毛线,变成像瑞士军刀一样的清晰。

    Rookie
  • 看看人家那后端API接口写得,那叫一个牛逼,再看看我的,像坨屎!

    在移动互联网,分布式、微服务盛行的今天,现在项目绝大部分都采用的微服务框架,前后端分离方式,(题外话:前后端的工作职责越来越明确,现在的前端都称之为大前端,技术...

    架构师修炼
  • 我最喜欢的Mybatis 3.5新特性!超实用!

    Mybatis 3.5 发布有段时间了,终于支持了 Optional ,这么实用的特性,竟然还没人安利……于是本文出现了。

    用户1516716
  • Mybatis 3.5新特性——Optional支持

    Mybatis 3.5 发布有段时间了,终于支持了 Optional ,这么实用的特性,竟然还没人安利……于是本文出现了。

    wuweixiang
  • 程序员请改掉影响你升职加薪的36个坏习惯!

    IT行业的科技公司们一直苦苦追寻传说中以一当十的超级程序员,最新的研究表明确实存在这样一小撮效率奇高的“程序金刚”,但是一位普通程序猿如何能够蜕变成代码金刚呢?

    Java后端技术
  • 这36个坏习惯,影响着程序员是否能升职加薪!

    IT行业的科技公司们一直苦苦追寻传说中以一当十的超级程序员,最新的研究表明确实存在这样一小撮效率奇高的“程序金刚”,但是一位普通程序猿如何能够蜕变成代码金刚呢?

    用户5224393
  • 未来已来——iphone X 开启时代大门(附官方设计规范下载)

    另外iphone8的设计尺寸要出了,所以老板马上会给你配iphone8的,不要着急

    宇相
  • iOS程序员请改掉影响你升职加薪的36个坏习惯!

    IT行业的科技公司们一直苦苦追寻传说中以一当十的超级程序员,最新的研究表明确实存在这样一小撮效率奇高的“程序金刚”,但是一位普通程序猿如何能够蜕变成代码金刚呢?

    原来是泽镜啊
  • 大数据东风下,Clickhouse这坨屎是怎么上天的

    网上有很多讲大数据的文章会告诉你,Clickhouse是来自俄罗斯的“大数据”查询引擎。这个由Yandex主导的大数据引擎,非常的牛逼,速度超级快。然后这个传说...

    用户1564362
  • 像设计马桶一样设计接口 No.109

    我发现很多人,包括我自己,在设计接口和流程的时候,都希望接口保持最小职责原则,因为我们是"平台",我们只能提供最小粒度的接口。

    大蕉
  • 看了很多技术书,为啥仍然写不出项目?

    这大概是还在读书的同学最大的困惑了。自己明明看了很多书,感觉不到自己的进步,很有挫败感。计算机科学是一门实践的科学,你发现你看了《现代操作系统》,《CSAPP》...

    Leetcode名企之路
  • 大数据人员必会的linux性能调优

    最近发现知识付费泛滥成灾,很多人买了很多课程,但是真正能看完的没有几个课程,比如大数据从业人员,工具还没用熟,就去学习数据结构,机器学习等,不是瞧不起你的学习能...

    Spark学习技巧

扫码关注云+社区

领取腾讯云代金券