公司项目中的代码为什么会烂得像一坨SHI

原创 吴就业 103 0 2019-06-10

本文为博主原创文章,未经博主允许不得转载。

本文链接:https://wujiuye.com/article/3ad8837fa90444bd8ef2ee4a071166a9

作者:吴就业
链接:https://wujiuye.com/article/3ad8837fa90444bd8ef2ee4a071166a9
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。

脉脉上看到有人吐槽公司项目代码跟一坨SHI似的。说实话,以前的我,也会有这种想法。

图片

我一开始接触现公司的一个老项目时,也是各种吐槽,一个方法三千多行,那时候我并不是很理解,为什么会写出这样的代码。

现在,根据我的经验,我猜测项目长残主要是以下几种原因。

1.需求多,没时间

我全程参与了一个新项目的开发,从项目的一开始设计、项目架构的搭建就开始参与其中,到现在,已经有半年时间,已经不再是当初设计的那个样子,加了数不清的需求,某些功能改了数不清的次数,连整体的架构都被我改了好几次。

新的需求总是很紧急,每个bug都是很紧急,所以根本没有太多时间让我去好好想如何设计,往往有bug就先解决bug,有需求就赶需求,事情多得需要给它们贴标签排优先级,基本每周一的事情都能安排满这周与下周的时间。

所以说,代码写得烂的原因之一就是需求多且时间紧。

2.需求频繁变动

我记得年后上班的第一个月,是我今年最累的一个月,老项目一堆问题,也一堆需求,各个都标着紧急的标签,同时,那时候又是新项目赶进度上线。

新项目赶进度,但是协议没定好,这个很好理解,一个新的产品存在的变数很大,前期需求盲摸索找准方法。前后端也需要时间磨合,只有踩在一个点上,才能稳定下来。一时间,功能一直在变,一直在变,连数据库表的结构设计都调整好几次,那时候每天都要修改sql,昨天写的代码,今天就得删了重写,天天开会讨论,客户端与后台的接口协议天天变。

所以,这第二种原因,就是需求频繁变动。一开始可能是想做个饼,但是做着做着,觉得饼不好吃,又改成了做包子。

3.无法预测的需求迭代

我之前重构的一个模块,就是一个实现广告单数据过滤的业务逻辑,一个方法写了三千多行代码。

我猜测它的发展历史是这样的:

我记得后面一个是我加的,所以一个方法三千多行,就是这么来的。

所以,第三种原因就是,无法预测的需求迭代。一开始逻辑很简单,但慢慢的加了很多新的逻辑,所以本来一个方法只有几十行代码的,最终写到了一千多行。

4.以后再优化

很多人都有一种心理,就是先实现,以后有时间再优化。

接到一个需求,一开始都是先实现功能,怎么简单怎么来。例如,原本一开始可以用算法优化的一个排序功能,结果为了快速上线,就写了个简单的for循环。

这不就是埋下了一颗定时炸弹吗?如果忘记去优化,不知道哪天就会爆炸。

5.技术更新太快

我跟同事讨论过,项目中的某某功能为何不用消息中间件,同事的回答真是打脸:16年的时候我都不知道消息中间件。

所以说,就算那时候听说过,但是项目在初建期,时间就是金钱,越早上线越好,没有时间等你们程序员回去学习消息中间件再开发。

至于后面为什么没改,你想啊,可能那位哥辞职了,或者没时间,或者他不学习新技术,还是吃老本。

SO

不要再抱怨你们公司项目的代码写得多烂,因为你不了解它的历史,你没有参与它的成长,你根本就不懂它是怎么长残的。

如何避免代码变成一坨SHI

如果你不想你写的代码也被后来者吐槽,那就从现在开始,写好你的代码,发现或者预测到有烂代码出现时,应及时调整或者重构。

对于第2、3种原因,需要我们主动的去对项目进行优化。看到一个方法写到一千多行,那你就需要主动去进行拆分,可以使用设计模式就改用设计模式,不行就按照功能拆分成多个方法。

当你发现这块功能的代码逻辑太乱,或者想加一个新的逻辑进去很难的时候,说明这个功能模块需要进行重构了。对于这种,越早重构越好,否则越往后拖,别说加入新的需求,就算让你改动某个逻辑都很难,不知道你是否有体会过。

我跟同事就遇到过几个老项目中的不解之谜,其实没有什么不解之谜,只是涉及的东西太多,逻辑太复杂,连调试代码都找不出问题。如果不尽早重构,总是将就着能用就用的态度,吃苦的可能不是你,因为你可以辞职,只是痛苦的往往是后来者,也有很多后来者忍受不了辞职的,可以说,把后继人坑惨了。

我们预知不了,随着业务的发展,会给项目带来哪些巨大的变动,但我们可以预测会有哪些需求,从而在对某个业务模块、某个功能的设计时,尽量满足预测未来可能要实现的,这就是扩展性。所以我们也需要对业务很了解,还是那句话,一味的追求技术是不够的。

#后端

声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。

文章推荐

Netty高并发编程及性能调优实战经验分享

本篇内容介绍我们项目为何选择使用Netty,以及如何衡量一个服务的并发处理能力,再介绍如何做业务代码调优、针对不同业务场景的高并发性能调优。

传统BIO网络编程知识点总结与Java NIO简介

本篇作为“Netty高并发编程及性能调优实战经验分享”的补充,归纳总结传统BIO编程知识点,以及介绍Java NIO。

RocketMQ集群搭建与监控后台部署

本篇介绍RocketMQ集群几种模式的搭建、配置,以及监控管理后台的部署。

使用Sharding-JDBC实现分表,并让动态数据源支持Sharding-JDBC数据源

本篇介绍了笔者在一个业务场景下,通过各种优化手动都无法降低查询耗时的情况下,选择将表拆分多个,并使用Sharding-JDBC实现分表的查询,并介绍如何在已经实现了多数据源的项目中支持Sharding-JDBC数据源。

使用Jprofiler远程监控线上服务

需要特别注意的一点是,本地安装的Jprofiler图形界面工具一定要与远程服务器安装的版本号一致。否则远程连接就连接不了。

使用Jhat排查问题实战:查看类型为List的静态字段的大小

我使用浏览器的开发者功能,找到api,确实服务器返回给浏览器的结果是空数据。然后我顺藤摸瓜找到了这个api的代码,结果发现又是使用的内存缓存。本篇介绍如何借助JHat的强大功能查看内存缓存是否是空的。