这么烂的代码，谁写的？！

这么烂的代码，谁写的？ 

每个程序员都会发出这样的灵魂拷问。

烂代码可能是祖传的，上一代程序员写的，可能是离职的程序员写的，可能是同事写的，更悲催的是，可能就是你自己写的！

有的代码传了四五年，有的传了十几年，还有的传了二十多年！

做Java的同学，你能想象得到只用JSP做的系统吗？

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

大名鼎鼎的Oracle很强吧？ 

2018年有个Oracle程序员吐槽说每次处理一个Bug ，都需要花费两周时间搞清楚20个不同的flag以及它们之间的神秘作用，然后自己才能添加若干新flag和逻辑来fix bug。 

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

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

然后为你的更改再添加上百个测试，保证别人不会破坏。

是不是很疯狂？ 

你也可以看看你手头的代码，看看最早的作者是谁，经历了多少个版本。 

我看到的最早的版本是1998年，那个作者现在是个高级的架构师了。

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

但是，请放心，根据“代码腐化定律”和“破窗效应”， 你的项目很快就会变成“祖传代码”， 毫不例外！

01

遏制你重写代码的冲动

我不止一次一边砸键盘一边骂：这么烂的代码，维护成本这么高，重写得了！

但是理智告诉我：重写的成本更高，祖传代码虽然很烂，但是经历过无数测试和真实用户的考验， 那些看起来无法理喻的分支、条件恰恰是在弥补那些程序员没有考虑到的逻辑。 

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

软件质量包括两个方面：内在的和外在的。 

内在的是代码质量， 外在的是对外表现的行为是否符合预期，不符合就是Bug了。 

祖传代码的外在质量是不错的，毕竟是经过血与火的考验的。   

如果重写，你能保证内在的代码质量和外在的行为都超越祖传代码吗？ 

重写不能保证业务中断，这是基本条件， 2010年在华为做敏捷咨询，华为有个口号我记得非常清楚：要在高速公路上给汽车换轮子，这可能吗？  据说华为有团队真的做成了，如果是真的，确实让人佩服。 

02

寻找优秀架构的影子

祖传代码虽然乱，但是初始的架构一般还是优秀的。 

我在华为就看到有个产品是这样的，应用层堆积起来的代码看起来很差劲，但是仔细瞧瞧，依稀可见优秀架构的影子，这肯定没有守住， 后来慢慢腐化了。

所以面对祖传屎山代码，要捏着鼻子，抛弃细节，在里边努力搜索优秀架构的影子。 

从功能上看，系统分为哪些组件，组件之间是如何交互的？

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

一些核心组件的内部是如果进行再次划分的，如何分层的？ 

总之，要回答这么一个问题：如果是我，我能独自把这个系统给搭建起来吗？ 

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

03

在自己的范围内尽量重构

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

努力把自己的代码写好，能重构的地方尽量重构，哪怕是一个函数，一个变量名。 

这些都是自己赖以生存的技能，不能因为祖传代码烂，自己写的代码更烂！ 

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

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

要对得起自己，不能坑了自己。 

04

拓展视野，看优秀源码

祖传代码虽然有优秀架构的影子， 但是看多了也会吐的。 

在这个世界上还是有优秀源代码的， 尤其是开源的代码， 它们没有进度的巨大压力，维护者有足够的时间打磨自己的代码， 像一个工匠一样。 

我知道的一些优秀源码有这些：JUnit，Redis，SQLite,  Spring等。 

这写代码现在都很庞杂了，看起来很累，最好去找他早期的源码，要简单得多，并且基本架构还在。  

比如JUnit早期代码，几百行的代码就把很多设计模式都给组合了起来，非常巧妙，设计模式看多少都不如看一个活生生的例子。 

看完以后，自己尝试着造一个轮子，把主要思想都给体现出来，你的功力至少上一个层次。 

（完）

开了一个新号：想躺平的程序员， 谨防失联，请保存。

这个号不干别的，只为每天让你乐呵一下，不可错过。