对不起,因为之前的代码写的烂,所以我也只能继续烂

  1. 云栖社区>
  2. 云栖号资讯>
  3. 博客>
  4. 正文

对不起,因为之前的代码写的烂,所以我也只能继续烂

云栖号资讯小编 2020-03-10 11:00:56 浏览316
展开阅读全文

云栖号:https://yqh.aliyun.com
第一手的上云资讯,不同行业精选的上云企业案例库,基于众多成功案例萃取而成的最佳实践,助力您上云决策!

路怎么走,你应该能说了算。

上周四,我团队里的某技术经理在一次代码评审会上跟一位开发同学发生了争吵,而事情的起因是某段看似合理,却存在明显性能问题的代码片段。

image

图1. 利用时间格式生成一个数据主键

image

图2. 在调用方法之前,先随机休眠

我先来做下简要说明,图1的代码是一位离职员工写的,而图2的代码是这位开发同学写的,把这两段代码拼凑起来,基本可以得出这样一个程序逻辑:

1、执行 getDataId() 会返回一串格式为 “当日日期+时间+毫秒+随机0-9” 的编号。

2、调用 getDataId() 之前,为了防止由于线程争抢或并发而导致的 “编号重复问题”,

在调用之前,故意让当前执行线程随机休眠一段时间。

听到这,相信写过代码的同学都会产生一个质疑:“为什么要随机休眠?”

是的,这就是他们俩争论的原因。

先别急着吐槽,如果只站在 “执行通过” 的角度,你觉得这代码有问题吗?

粗糙的说,这代码不但能运行,而且作为一个企业内部系统,只要并发不达到一定规模的情况下,是绝不会出现异常的。

既然如此,那为什么还要争吵?下面我来还原一下他们俩的对话内容。

……
技术经理问开发:“调用之前为什么要增加随机休眠?这样做,你难道不考虑性能问题吗?”

开发说:“不是,我有考虑过。”

技术经理提高了嗓门:“考虑过干嘛还这么做?为什么不用同步(线程间互斥)来处理呢?”

开发听完反而来劲了,说:“我有提出过这个方案,但可能是涉及到的改动点比较多,大家都没理我,所以我也就没有坚持。”

技术经理反问:“什么叫没有坚持?你为什么不跟我来说?或者直接做一个新方法,甚至是把这个方法改了也可以呀。”

开发有些委屈,说:“不是啊,你给我的任务时间就一天呀,如果重构,除非搞个通宵,否则时间肯定来不及。再说了,公共方法又不是我负责的范畴,而且getDataId也是离职的人搞得。他们把代码写成那逼样,我有什么办法,又不是我弄得。”

开发耸了耸肩,继续说:“一个内部系统能有几个人用?怎么会有性能问题?没必要那么认真吧。接手那么烂的代码,我能把逻辑跑通就已经很不错了。”

技术经理明显被这一堆歪理激怒了,瞪大了眼睛说:“你这叫什么歪理?如果你觉得前任做的东西够烂,那你应该去想办法改善他们啊。“

“按你的逻辑,因为之前的代码写的烂,所以你也只能继续烂,是这意思吗?”

开发愣了一下,看了一眼技术经理,可能是顾及自己的KPI,从牙缝里挤出几个字:“那好吧,就按照你说的方式改吧...”

……

他们对话的时候,正巧我从会议室门口路过。

整个过程听的比较完整,但我并没有说话,更没有试图带着 “乌纱帽” 去对谁进行训斥,只是略微的缓和了一下两人之间的尴尬氛围,随后便各忙各的去了。

话虽如此,我慢慢地走回到自己的办公桌前,努力想让自己的内心平复下来,可是却无法平息内心的那股不爽。

我真不敢相信,这一番歪理居然是从一个年轻人嘴里说出来的。

对大部分写过程序的人来说,相信都有过接手别人代码的经历。

比如,你身边的某位同事离职了,领导安排你去承接他的工作,你一边感激领导的信任,一边顺势打开这位同事保存在GIT上的某段代码,顿时被眼前的镜像气的两眼发直……方法没有注释,属性命名都是AAA或者BBB,还有一个代码片段的注解写着 “这段代码是我前任写的,至今我也不知道它是干啥的“。

你咬着牙,内心狂奔过一万头草泥马,叹了口气,咽了口唾沫,想了想下个月的房租,默默地接受了这一切。怪不得在技术圈会酝酿出这么一个玩笑梗:“如果你恨一个人,就让他去接手别人的代码。”

这足以见得,如果被安排接手别人的代码,对程序员来说是最痛苦、最可怕的事,但生气归生气,郁闷归郁闷,生活还在进行着,何况搞技术的没有那么娇气。

不过,由于项目规模、业务形态、团队文化及领导风格的差异,再加上性格特点的不同,所以导致 程序员A 和 程序员B 在面对这个问题的时候会做出完全相反的行为。

有的人,心态积极,实干能力强,往往做事会更有干劲,自然也获得更多的收获。

有的人,毛嘴牢骚,得过且过,多一事不如少一事,自然不会获得更多的成长。

在我二十多年的职业生涯里,尤其我还是一名愤青程序员的时候,只要接手别人的代码,我一般都会表现的十分积极。

为什么?

因为这个时候,不仅是向领导展现能力的最佳时机,同时也是获得自我成长的绝好机会。

2001年初,我在某家从事电子政务的软件公司工作,职位是软件工程师。

在那个没有百度和Google的时代,如果遇到一个技术问题,除了翻阅大量书籍和咨询前辈之外,基本不可能有更好的解决途径。对一个刚踏入技术圈的菜鸟来说,这意味着我花费在解决技术问题上的时间会比其他人多。

不过我性格诙谐,说话直白,而且脸皮还厚,每次遇到解决不了的问题,我不是缠着张哥,就是拖着李姐,只要能获得成长,什么端茶递水都不在话下。而且每逢团队中有技术预研或性能优化的工作,无论多苦多累,甚至是熬夜通宵,我也会抢着去做。

也正因为如此,Leader也好,经理也罢,都比较喜欢我。

这一天,我的老大找到我。

“小王,小张下周就要离职了,这事你知道吗?”

“我知道呀“

“他手上的那个XX省地税系统,我想让他交接给你,你有兴趣吗?”

“啊?兴趣当然有啊,但那套系统难度那么高,我怕自己搞不定。”

“这不用担心啦,那么多人在呢。要不这样,你这两天先跟小张交接下,然后再说,怎么样?“

很显然,按当时的阅历,我确实很难理解这其中的 “套路”,所以我只能天真的点了点头。

他很高兴,拍拍我的肩头说:“答应了?太好了!“

我下意识地握了下拳头,说:”老大放心,我一定努力完成任务!“

他很高兴,点了点头,转身走了。

第二天,我从小张手里拿到了整个系统代码,在经过一下午的交接之后,我似乎才明白一个硬道理:为什么程序员宁可写一天代码,也不愿意读一行别人写的代码。

这堆破代码,除了数据库字段注解和零零星星的一些代码注释之外,要文档没文档,要流程没流程,甚至还存在内存泄漏。

只要你多问几句,或者问到一些细节,他就一百万个不耐烦。

到最后我的犟脾气也被点燃了,得嘞,你爱讲多少就多少,我也不必自讨没趣了。

第二天,老大跑来问我:”交接的怎么样?还顺利吧?“

我也不知道哪根筋搭错了,居然脑回路也没走,直接抬手做了一个OK的手势:“当然顺利啊,老大你放心吧。”

“哦?那太好了,那下个月的新版本能准时发布吗?”

新版本?下个月?我有点懵逼,但又急于表现,顺口回答:“当然没问题啊。”

他依然很高兴,点了点头,再一次转身走了。

那句话怎么说来着?自己吹出去的牛逼,含泪也要装下去。

于是,我从当天开始,白天开发新功能,晚上除了给老代码添加注释之外,还要还技术债,再加上技术经验尚浅,缺乏应有的资料和帮助,每天基本都要搞到凌晨2点之后,才能离开公司。

好在我当时居住的地方离公司也就两站路的距离,骑个车,最多20分钟。

就这样,这种节奏持续了一个半月,每天都是鸡叫起床,鬼叫回家,我似乎已经忘记了自己是谁,来自哪里,为什么要在这里,一睁眼,满眼都是代码,一闭眼,满耳朵都是Error的告警声。

不过,老天爷还算对得起我,通过这一个多月的努力,新系统通过了客户的验收,如期上线了。

但不幸的是,就在新版本发布后的第三天,我由于扁桃体一直肿大不消,在医院足足挂了一周的青霉素。

靠着年轻,还仰仗那股子驴脾气,这一关算是过了。

一周后,我的身体逐渐康复了。

为了能在职业生涯中留下些什么,我曾通过CVS、日志记录以及自己写的一些脚本做了一次统计。

从小张走后开始算起,我一共完成了12个业务功能,其中8个需求新增,4个需求调整。在接口方面,除了部分有简略备注之外,不仅命名规则混乱,而且都没有业务注释,我不但完成了几乎所有的注释添加,而且还整理出了一些注释规则,以方便其他人员接手。

另外,最恶心的是内存泄露,我一共发现了3处泄露点(从上线的情况来看,应该还有我没找到的,但能力和时间有限,只改掉了这些),并完成了修复。

至于数据模型的说明,和用户手册,那更是值得一提。不仅获得了团队的好评,更收获了客户真诚的感谢。

哦,对了,有个事这里需要特别提一下,那就是重构。

是的,我把之前系统中很多方法结构都进行了重构,至于多少,我也没数过,反正挺多的。

现在回想起来,之所以会在这种量级的系统上投入那么多时间,除了 “接盘侠” 与个人能力的因素之外,这也跟大量代码的重构有直接的关系。

但我觉得,重构也好,修修补补也罢,这只是一种手段。关键看你自己的选择,困难在你眼里,究竟是一种机会,还是一种麻烦。

当接手一堆烂代码的时候,你是选择继续烂,还是咬咬牙,跺跺脚,努力使那些接手这些代码的后来者,脸上能露出一丝灿烂的微笑。

相信在每个人的内心都有着不同的答案。

看到这,或许有人会问:“看你说的振振有词,这一番折腾之后,你拿了不少奖金吧?”

很遗憾,由于受到经济形势的波及,再加上合伙人的一些矛盾,这家公司在2002年初就宣布倒闭了。

但幸运得是,在倒闭之前我就成功跳槽了,算是躲过了欠薪危机。

说完这句话,或许你又要说:“啊?也就是说你被老板耍了一回,最终啥都没捞着?”
从物质的角度来说,的确如此。

但在那个项目中,我第一次接触到了Oracle,并对这个当时最流行的数据库产生了浓厚的兴趣,于是我第二年就去考了OCP(Oracle数据库认证专家)。

另外,在这个项目中,我也第一次接触到Servlet,在此之前我都是采用JSP中嵌入JAVA代码方式,这也使我在实战中明白了啥叫前端,啥叫模块化。

现在回想起来,虽然没能从那个项目中获得真金白银的回报,而且至今仍然能回忆起那份疲倦,但我并不后悔。

说到这里,可能还是有人不服气:“按你的说词,你能在这个项目中获得了成长,所以你才愿意努力付出,但对那些无法在项目或任务中获得成长的人来说,主动性也好,驱动力也罢,自然不会那么高。”

我曾经写过一篇名为 #为什么国内的程序员都痴迷 “海量高并发”?# 的文章,内容中略带吐槽的提到现在的年轻程序员内心浮躁、焦虑,再加上行业、企业及自媒体的威逼利诱,导致很多程序员都缺乏基本功,每天只盯着眼前的利益,什么技术赚钱,我就去学,什么行业薪资高,我就骑着马飞奔而去。

满脑子装的都是腾讯、阿里的牛逼架构,不相信任何好高骛远的未来,稍有不爽就跳槽,稍有不适就骂街,怪这个烂,怪那个蠢。

今天嫌弃这个任务没技术含量,明天抱怨那个项目的前任是傻逼。

是,这些可能都是事实,但这样做,真的有用吗?

我们把当年的我与文章开头的那位开发同学放在一起来作对比。

当问题出现的时候,我的第一反应是怎么来解决这个问题,解决这个问题有什么方法,哪个是最佳的方法。在我的思维中,问题是可以解决的,心态是乐观的。问题没能解决是因为自己找不到解决的方法,但是并不是说这是不可能的。

当问题出现的时候,那位开发同学的第一反应是怎么会出现这个问题?天啊,怎么会出现这个问题呢?怎么有可能会出现问题呢?为什么会出现问题,到底是怎么回事?我该怎么办,这个问题可以回去吗?假如之前的那个傻逼做的好一些,这些问题就不应该存在。为什么之前那个傻逼会这么不负责任呢?

凡事涉及到思维和心态,大道理说多了没啥意思。

今年春节期间,大部分人都体验了一把有生以来最长春节,有的人利用这个难得的时机学习、充电,而有的人则每天重复着 “拿起手机,刷疫情讯息,随之焦虑,又放下……两分钟后,再次拿起手机,刷疫情讯息,随之焦虑……”

有朋友跟我说过一句话:你用什么方式度过疫情,你就会用什么方式度过一生。
同样的道理,对一名程序员来说,你用什么思维和心态对待问题,那你也将用什么思维和心态度过职业生涯。

想怎么走,自己看,自己领会吧.

云栖号在线课堂,每天都有产品技术专家分享
立即加入圈子:https://c.tb.cn/F3.Z8gvnK
与专家面对面,及时了解课程最新动态!

原文发布时间:2020-03-09
本文作者:王晔倞
本文来自:“w3cschool公众号”,了解相关信息可以关注“w3cschool

网友评论

登录后评论
0/500
评论
云栖号资讯小编
+ 关注
所属团队号: 云栖号资讯