这些老系统代码,是猪写的么?

简介: 这些老系统代码,是猪写的么?



小王新加入了一家公司,这家公司有点年头,所以连屎山都是发酵过的,味道很冲。

和大多数时运不济的程序员一样,到了这种公司,做的大多数工作,就是修补这些屎山,为其添砖加瓦铸造更大的屎山。每当被折腾的筋疲力尽,就忍不住鼻孔喷着浑浊的空气:“设计这个系统的人,真的是太垃圾了”!

当然,设计这个系统的人,可能早就离职了,也可能就是你的顶头上司。如果你有幸获得一个脾气温和的前辈,他会带着无比后悔的口气告诉你:“这个系统确实千疮百孔,如果我们当初按照正确的思路设计就好了”!

没有程序员不后悔过,就像亏钱的人都后悔买了股票,长大的人都后悔来到这个世界。

很多人看到烂代码,那都是事后来看的。在代码跑起来的那个时刻,“能运行”才是最重要的。烂代码能够进入仓库并投入生产,一定是某些环节的缺失造成的。

烂代码自有它的背景。

工期赶

有数不清的管理者,想要量化程序员的工作,由此产生了KPI、OKR这样的工具。在某个时期,它或许是有用的,但这种以截止时间点来衡量的工作方式,会造成技术债的大量积累。

在工期的压迫下,很少有人能够思考需求的合理性,以及后续的扩展性。烂代码在未经过Review的情况下,缺少重构、有限测试,就火急火燎的跑到线上运行。有些设计,可以说从源头上就是不合理的,但由于需要快速实现,方案上就不得不进行妥协。

大多数情况下,朝生夕死的代码并不会产生多大的问题。但总有一些项目,生命周期非常长,修修补补的需求还非常多。在一个地基不稳的地方造一座大厦,总有崩塌的一天。

不过管它呢,只要不是塌在自己手里就可以了。

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

练手项目

我甚至发现了一个非常有意思的现象。很多部门为了培养新人,会特意把一些非常重要的模块和功能,交给新人去做。

由于缺乏经验,新人在方案设计上有诸多的缺陷。但在时间成本上,它和老鸟相差并不太多。很多练手用的项目,在不经意间也会成长为巨无霸,然后它留下的缺陷就会被放大。

和大多数人的认知正好相反,新人在技术方案上,会采用更多的新技术和奇技淫巧,而老鸟善于使用最基本最朴素的工具来完成设计。这可能是一种想要把学到的东西付诸实践的功利心与追求时尚的虚荣心在作怪。

很不幸,追求技巧的代码,会有非常多的约定与规范在里面,如果不是项目统一把控,这种约定和规范会与项目中的其他约定和规范相悖,造成代码风格不统一,调试困难,无法扩展。

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

自起炉灶

很多程序员非常的自信,认为自己的english水平和编码水平特别高,表现在代码上就是龙飞凤舞,自起炉灶。

他们不去关心整个技术社区的约定和规范,在接口命名,对外API上倾注了自己过多的心血,我们通常把这些人称为东施效颦的轮子哥。

比如/health接口,我偏不叫health,我叫/server_status。

再比如错误码,我非要一个叫做 success_200,一个叫做fail_500。后续入职的修正帝看到这样的错误码,嗤之以鼻但是并不敢改动,于是他自己做了一套200和500。

这样的约定和修正约定,会在岁月的侵蚀下越积越多,以至于没人知道它是什么。

所以,如果你看到一个项目的代码非常的烂,不要着急修改,一定要按照它的烂逻辑写下去。相信我,它必定比你的修正稳妥的多。

copy帝

在很多公司,你去看他们的产品和代码,会有一种似曾相识的感觉。

没错,他们是抄的。

在缺乏产品设计和经费的前提下,老板下达了终极命令。

“照着xxx给我copy一个,连一个按钮也别放过”。

copy一个和设计一个是两个概念,copy通常意味着浅显的思考,在细节和功能上都比模子差了很多。

更要命的是,模子在变。如果运气不好,一个团队刚copy好了一个产品,结果第二天打开别人的产品一看,好家伙,人家全部改版了。

四不像和未经过设计的代码由此而来。

当然copy帝还指的是cv工程师,但他们的破坏力有限,初心也是好的,并不能造成多大的破坏力。

怎么办?

后悔,起码是好的。

这是相对于从不后悔的人来说的。后悔说明了他知道怎么做才是正确的,只是在某些特殊的环境中造成了这样的后果。

如果同样的轮回交给有后悔经历的人来说,他会有更多的思考在项目的时间和人员分配上。而从不后悔的人可能是倔驴,也可能是真的认为他自己是对的,这是非常可悲的一件事情。

如果你不幸在维护这些屎山,千万记得要做力所能及的事情,不要冒进,也不要过度修正。除非你的团队给了真正的时间和人员,来决定真正把这坨屎铲一铲。



相关文章
|
23天前
|
存储 网络协议 搜索推荐
宏函数的代码替换机制会对程序的可移植性产生什么影响
宏函数的代码替换机制可能导致程序可移植性降低,因为它在预处理阶段直接替换文本,可能引发类型不匹配、副作用等问题,不同编译器和平台表现不一。
|
2月前
|
算法 程序员
程序代码设计步骤
程序的设计过程,并不是立刻就进行代码设计,一般来讲包括设置文件的存放位置、说明书的设计、代码设计、程序测试、程序调试、注释说明。
62 7
|
3月前
|
搜索推荐 API 数据处理
什么是无代码?哪些人适合通过无代码来开发自己的业务系统
无代码是一种无需编程知识即可构建应用的方法。用户通过拖拽组件并设置参数,即可搭建功能完备的应用系统。其核心特点是普适性和包容性,降低了技术门槛,提供了直观界面,能快速响应需求变化,同时降低成本并具有一定的可扩展性。无代码适合一线业务人员、中小企业及专业技术人员使用,但在高度定制化、复杂逻辑处理或深度系统集成方面仍需传统开发。以草料二维码为例,无代码平台提供活码、表单、计划管理等功能,助力快速搭建各类应用系统,使每个人都能成为开发者。
|
2月前
|
Java 调度
代码打造每日任务系统
在游戏开发中,每日任务系统对提升玩家活跃度和留存率至关重要。通过Java的面向对象特性,可将每日任务抽象为`Task`类,并通过实例化及方法调用实现任务创建、执行与奖励功能。进一步,可以创建`DailyTaskSystem`类来管理所有每日任务,包括添加、删除和获取任务列表等操作。这种设计不仅简化了任务管理,还增强了游戏的可玩性和吸引力。更多细节和实现方法可见相关游戏逻辑设计与具体需求。
39 0
|
4月前
|
数据库
代码的应用重构问题之BaseActivity类的主要功能问题如何解决
代码的应用重构问题之BaseActivity类的主要功能问题如何解决
|
4月前
|
JSON 前端开发 Java
代码的应用重构问题之BaseActivity类的主要功能问题如何解决代码缩减的主要问题如何解决
代码的应用重构问题之BaseActivity类的主要功能问题如何解决代码缩减的主要问题如何解决
|
6月前
|
SQL NoSQL Java
系统干崩了,只认代码不认人
为了保障系统的高可用和稳定,我发誓以后只认代码不认人。文末总结了几个小教训,希望对你有帮助。
系统干崩了,只认代码不认人
|
6月前
|
存储 开发工具 数据库
认识HIS系统 HIS系统的主要功能解释说明
HIS系统即医院信息系统(全称为Hospital information System) ,是指利用计算机软硬件技术和网络通信技术等现代化手段,对医院及其所属各部门的人流、物流、财流进行综合管理,对在医疗活动各阶段产生的数据进行采集、存储、处理、提取、传输、汇总,加工形成各种信息,从而为医院的整体运行提供全面的自动化管理及各种服务的信息系统。
498 5
|
存储 小程序 容器
小程序中实现文章的关注功能
小程序中实现文章的关注功能
小程序中实现文章的关注功能
|
算法 安全 前端开发
程序常用的设计技巧
程序常用的设计技巧
程序常用的设计技巧