接手前同事代码,特别烂,各种BUG,看麻了。。。

简介: 接手前同事代码,特别烂,各种BUG,看麻了。。。


年前公司优化了一些人,最近我开始接手他们的项目。

然后...我就麻了。

一开始接到这个任务的时候,我没怎么当回事儿,根据一些需求评估的时间也比较紧凑。

后面越看越不对劲,估时两天的开发,我每天加班都硬生生的花了 5 天。

绝大部分业务实现就是直接干,硬怼!

没有抽象,没上缓存,没有批处理的概念循环一个一个调,有些方法也没有事务,更别说补偿。

一个方法多的有七八百行,平铺直叙。

上传图片、创建订单等等操作一个方法里面同步直接干,超不超时就随缘。

把我都看傻了,也得亏这个项目是新项目,当前没什么用户,不然真有用户大量使用这方法不报错我直播倒立洗头。

鉴赏下

业务或者性能方面不说了,因为就连编码风格或者说基础可能还不如实习生(我们公司都是招5年以上的)。

我截了几处,一起来来鉴赏下:

都是公司代码,所以打码

先来个开胃菜,热热场子:

这样的代码很正常,有些人写 demo 会输出到控制台,但是对应生产项目里面在 main 分支我看到很多这样的代码,这就有点说不过去了。

就算习惯用这种方式调试,一两个可以说忘了删了,但是遍地都是说明压根就没想删除。

对自身提交代码的要求太低了。(合并分支的同学也得背点责任)

趁热打铁,我们再来看下这段代码:

JSONObject 本身就实现了 Map 接口,内部也是个 map:

也就是说 JSONObject 本身就可以通过 key 去 get value,何必再变成个 map 执行一样的操作,em....。

上述的代码可以说其实影响不大,接下来的代码就有点东西了!

来看看这个 sleep:

首先看下这个方法的上面标记了 @Async 说明这是一个异步方法,那为什么要 Thread.sleep(300)?

起初我也没看明白,后来发现了这个异步的方法里面需要修改前面主方法新增的一个数据库数据,所以这里  Thread.sleep(300) 的目的就是等待主线程的事务提交,不然异步方法就取不到数据了。

我称这个为玄学编程,就是拿 300 毫秒赌主线程的事务已经提交,提交了好说,正常执行异步的逻辑。

要是没提交?那就....爱咋咋了。

既然说到  @Async 了,那继续看这个项目里的另一个  @Async  使用,我称之为假想异步:

可以看到声明了一个 createWxxx 方法,使用 @Async,很明显编码者想异步执行这个方法里面的内容。

然后我查看这个方法的引用,发现全局只在同个类里面的另一个方法使用:

就是个类的本地方法调用。

我们都知道在 Spring 里面,不论是事务注解还是异步注解,通通都是依靠 AOP 注入逻辑的,而内部方法调用是走不了代理的,所以这里的 @Async 压根就没生效,所以说这叫假想异步:只要我加了 @Async 我就异步啦!(还指定了线程池)

最后们再看一个分布式锁的操作。

我先给你点时间仔细看看下方的代码是否有问题。

其实一开始我都没发现,后面定睛一看,我滴妈加解锁的 key 都不一样,可以看到加锁的 key 比解锁的 key 多个 dto.getOrderNo()....

ok,没问题,这可以认为是疏忽,谁都有疏忽的时候。

但是分布式锁是这样用的??

 if (redis.setNx(xxx)) {
    //抢到锁了,dosth
 } 
 finally {
   redis.del(xxx) ???
 }

如果抢到锁就执行后面逻辑,这个没毛病,但是 finally 里面直接就删除锁是个什么意思??

合着抢不到锁,也直接把别人的锁给删了?

这还加什么锁呢?

这压根就是个大坑,坑的后面的人可能需要疯狂修数据!

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

最后

哎,还有很多神操作,比如 for 循环 RPC 调用外面还套了个事务。。真的都是大改!

其实很多时候公司压根不需要什么多牛的程序员。

基础踏实,稍微有点代码追求的程序员在大部分情况下比大牛都重要多了,毕竟一个项目绝大部分代码都是普通程序员写的,如果这里一点坑那里一点坑,加起来就是屎山,坑的就是公司和后人。



相关文章
arm-linux-gcc的下载与安装步骤
arm-linux-gcc的下载与安装步骤
2118 2
|
设计模式 算法 程序员
程序员为何需要反复修改Bug?探寻代码编写中的挑战与现实
作为开发者,我们在日常开发过程中,往往会遇到反复修改bug的情况,而且不能一次性把代码写的完美无瑕,其实开发项目是一项复杂而富有挑战性的任务,即使经验丰富的程序员也难以在一次性编写完美无瑕地完成代码,我个人觉得一次性写好代码是不可能完成的事情。虽然在设计之初已经尽力思考全面,并在实际操作中力求精确,但程序员仍然需要花费大量时间和精力来调试和修复Bug。那么本文就来分享程序员需要反复修改Bug的原因,以及在开发中所面临的复杂性与挑战。
504 1
程序员为何需要反复修改Bug?探寻代码编写中的挑战与现实
|
监控 Java
如何使用VisualVM分析内存泄漏?具体流程看这里
如何使用VisualVM分析内存泄漏?具体流程看这里
1728 1
|
SQL 存储 分布式计算
统一sql引擎Quicksql
统一sql引擎Quicksql
|
7月前
|
存储 Rust Go
介绍一下这只小水獭 —— Fluss Logo 背后的故事
Fluss是一款开源流存储项目,致力于为Lakehouse架构提供高效的实时数据层。其全新Logo以一只踏浪前行的小水獭为核心形象,象征流动性、适应性和友好性。水獭灵感源于“Fluss”德语中“河流”的含义,传递灵活与亲和力。经过30多版设计迭代,最终呈现动态活力的视觉效果。Fluss计划捐赠给Apache软件基金会,目前已开启孵化提案。社区还推出了系列周边礼品,欢迎加入钉钉群109135004351参与交流!
894 3
介绍一下这只小水獭 —— Fluss Logo 背后的故事
|
8月前
|
存储 消息中间件 Kafka
基于 Flink 的中国电信星海时空数据多引擎实时改造
本文整理自中国电信集团大数据架构师李新虎老师在Flink Forward Asia 2024的分享,围绕星海时空智能系统展开,涵盖四个核心部分:时空数据现状、实时场景多引擎化、典型应用及未来展望。系统日处理8000亿条数据,具备亚米级定位能力,通过Flink多引擎架构解决数据膨胀与响应时效等问题,优化资源利用并提升计算效率。应用场景包括运动状态识别、个体行为分析和群智感知,未来将推进湖仓一体改造与三维时空服务体系建设,助力数字化转型与智慧城市建设。
864 3
基于 Flink 的中国电信星海时空数据多引擎实时改造
|
8月前
|
人工智能 物联网 Apache
Flink Forward Asia 2025 新加坡站议题征集开启|The future of AI is Real-Time
Flink Forward Asia 2025 将于7月3日在新加坡盛大召开!作为Apache Flink社区顶级会议,大会聚焦实时AI、实时湖仓、实时分析等前沿方向,汇聚全球顶尖技术实践。即日起开放议题征集,诚邀开发者与数据专家分享创新经验。席位有限,立即行动!扫码或访问官网报名参与这场年度技术盛宴,共话实时计算未来。
585 17
Flink Forward Asia 2025 新加坡站议题征集开启|The future of AI is Real-Time
|
存储 SQL 人工智能
Apache Flink 2.0:Streaming into the Future
本文整理自阿里云智能高级技术专家宋辛童、资深技术专家梅源和高级技术专家李麟在 Flink Forward Asia 2024 主会场的分享。三位专家详细介绍了 Flink 2.0 的四大技术方向:Streaming、Stream-Batch Unification、Streaming Lakehouse 和 AI。主要内容包括 Flink 2.0 的存算分离云原生化、流批一体的 Materialized Table、Flink 与 Paimon 的深度集成,以及 Flink 在 AI 领域的应用。
1483 13
Apache Flink 2.0:Streaming into the Future
|
供应链 监控 数据可视化
探索 Leangoo 在电商新品运营中的创新应用与价值
Leangoo 提供了一套全面高效的电商新品运营解决方案,涵盖项目规划、营销推广、供应链管理及数据分析等方面,通过任务卡、甘特图等工具实现跨部门协作与进度追踪,助力电商企业在竞争中脱颖而出。
探索 Leangoo 在电商新品运营中的创新应用与价值
|
Ubuntu Java 程序员
Flink1.9.2源码编译和使用
修改flink1.9.2源码,并编译构建,在新的任务中使用和验证
426 0
Flink1.9.2源码编译和使用