关于代码质量:这么烂的代码谁写的-IDCF

10次阅读

共计 2077 个字符,预计需要花费 6 分钟才能阅读完成。

这么烂的代码,谁写的?

每个程序员都会收回这样的灵魂拷问。

烂代码可能是祖传的,可能是上一代程序员写的,可能是到职的程序员写的,可能是共事写的,更悲催的是,可能就是你本人写的!

有的代码传了四五年,有的传了十几年,还有的传了二十多年!

做 Java 的同学,你能设想失去只用 JSP 做的零碎吗?

我遇到过,6000 多行的 JSP 充当 Controller,有个程序员某一次在 JSP 中增加更多的代码,间接导致无奈编译了。

赫赫有名的 Oracle 很强吧?

2018 年有个 Oracle 程序员吐槽说每次解决一个 Bug,都须要破费两周工夫搞清楚 20 个不同的 flag 以及它们之间的神秘作用,而后本人能力增加若干新 flag 和逻辑来 fix bug。

而后须要将代码提交到 200 台服务器组成的测试集群,期待 20 到 30 小时运行数百万个测试。可能有 100~1000 个测试失败,你须要剖析它们和更多的 flag。

如此循环两周,直到确保神秘的 flag 组合通过所有测试。

而后为你的更改再增加上百个测试,保障他人不会毁坏。

是不是很疯狂?

你也能够看看你手头的代码,看看最早的作者是谁,经验了多少个版本。

我看到的最早的版本是 1998 年,那个作者当初是个高级的架构师了。

如果你很侥幸,一开始就启动了一个全新的我的项目,没有祖传代码的问题。

然而,请释怀,依据“代码腐化定律”和“破窗效应”,你的我的项目很快就会变成“祖传代码”,毫不例外!

一、遏制你重写代码的激动

我不止一次一边砸键盘一边骂:这么烂的代码,保护老本这么高,重写得了!

然而理智通知我:重写的老本更高,祖传代码尽管很烂,然而经验过有数测试和实在用户的考验,那些看起来无奈理喻的分支、条件恰好是在补救那些程序员没有思考到的逻辑。

如果真的重写,你能保障这些边边角角的逻辑都实现正确吗?能保障不出重大的纰漏吗?能保障不给公司带来重大的财务损失吗?

软件品质包含两个方面:外在的和外在的。

外在的是代码品质,外在的是对外体现的行为是否合乎预期,不合乎就是 Bug 了。

祖传代码的外在品质是不错的,毕竟是通过血与火的考验的。

如果重写,你能保障外在的代码品质和外在的行为都超过祖传代码吗?

重写要保障业务不能中断,这是根本条件,2010 年在华为做麻利征询,华为有个口号我记得十分分明:要在高速公路上给汽车换轮子,这可能吗?据说华为有团队真的做成了,如果是真的,的确让人拜服。

二、寻找优良架构的影子

祖传代码尽管乱,然而初始的架构个别还是优良的。

我在华为就看到有个产品是这样的,应用层堆积起来的代码看起来很差劲,然而认真瞧瞧,依稀可见优良架构的影子,这必定是没有守住,起初缓缓腐化了。

所以面对祖传屎山代码,要捏着鼻子,摈弃细节,在里边致力搜寻优良架构的影子。

从性能上看,零碎分为哪些组件,组件之间是如何交互的?

从技术上看,这些组件部署到了什么样的软件上?组件之间交互用了哪些协定,同步还是异步?数据在组件之间如何流动?

一些外围组件的外部是如果进行再次划分的,如何分层的?

总之,要答复这么一个问题:如果是我,我能单独把这个零碎给搭建起来吗?

总有一天,你会成为这样的人,要做好储备。

三、在本人的范畴内尽量重构

面对祖传代码,初心不改。

致力把本人的代码写好,能重构的中央尽量重构,哪怕是一个函数,一个变量名。

这些都是本人赖以生存的技能,不能因为祖传代码烂,本人写的代码更烂!

重构和测试不分家,把本人的单元测试写好,把功能测试做好,必要的话请测试人员帮个忙。

肯定要有勇气去做,尤其是面对屎山代码的时候。

要对得起本人,不能坑了本人。

四、拓展视线,看优良源码

祖传代码尽管有优良架构的影子,然而看多了也会吐的。

在这个世界上还是有优良源代码的,尤其是开源的代码,它们没有进度的微小压力,维护者有足够的工夫打磨本人的代码,像一个工匠一样。

我晓得的一些优良源码有这些:JUnit,Redis,SQLite, Spring 等。

这些代码当初都很庞杂了,看起来很累,最好去找它晚期的源码,要简略得多,并且根本架构还在。

比方 JUnit 晚期代码,几百行的代码就把很多设计模式都给组合了起来,十分奇妙,设计模式看多少都不如看一个活生生的例子。

看完当前,本人尝试着造一个轮子,把次要思维都给体现进去,你的功力至多上一个档次。

起源:码农翻身
作者:码农翻身刘欣
申明:文章取得作者受权在 IDCF 社区公众号(devopshub)转发。优质内容共享给思否平台的技术伙伴,如原作者有其余思考请分割小编删除,致谢。

7 月每周四晚 8 点,【冬哥有话说】研发效力工具专场,公众号留言“研发效力”可获取地址

  • 7 月 8 日,LEANSOFT- 周文洋《微软 DevOps 工具链的 “ 爱恨情仇 ”(Azure DevOps)》
  • 7 月 15 日,阿里云智能高级产品专家 - 陈逊《复杂型研发合作模式下的效力晋升实际》
  • 7 月 22 日,极狐 (GitLab) 解决⽅案架构师 - 张扬分享《基础设施即代码的⾃动化测试摸索》
  • 7 月 29 日,字节跳动产品经理 - 胡贤彬分享《自动化测试,如何做到「攻防兼备」?》
  • 8 月 5 日,声网 AgoraCICD System 负责人 - 王志分享《从 0 到 1 打造软件交付质量保证的闭环》
正文完
 0