有的代码传了四五年，有的传了十几年，还有的传了二十多年！
做Java的同学，你能想象得到只用JSP做的系统吗？ 我遇到过， 6000多行的JSP充当Controller， 有个程序员某一次在JSP中加代码太多了，直接导致无法编译了。
大名鼎鼎的Oracle很强吧？
2018年有个Oracle程序员吐槽说每次处理一个Bug ，都需要花费两周时间搞清楚20个不同的flag以及它们之间的神秘作用，然后自己才能添加若干新flag和逻辑来fix bug。
然后需要将代码提交到200台服务器组成的测试集群，等待20到30小时运行数百万个测试。 可能有100~1000个测试失败，你需要分析它们和更多的flag。
如此循环两周，直到确保神秘的flag组合通过所有测试。
然后为你的更改再添加上百个测试，保证别人不会破坏。
是不是很疯狂？
你也可以看看你手头的代码，看看最早的作者是谁，经历了多少个版本。
我看到的最早的版本是1998年，那个作者现在是个高级的架构师了。
如果你很幸运， 一开始就启动了一个全新的项目，没有祖传代码的问题。
但是，请放心，根据“代码腐化定律”和“破窗效应”， 你的项目很快就会变成“祖传代码”， 毫不例外！
2. 遏制你重写代码的冲动
我不止一次一边砸键盘一边骂： 这么烂的代码，维护成本这么高，重写得了！
但是理智告诉我： 重写的成本更高，祖传代码虽然很烂，但是经历过无数测试和真实用户的考验， 那些看起来无法理喻的分支、条件恰恰是在弥补那些程序员没有考虑到的逻辑。
如果真的重写，你能保证这些边边角角的逻辑都实现正确吗？ 能保证不出重大的纰漏吗？能保证不给公司带来重大的财务损失吗？
软件质量包括两个方面： 内在的和外在的。
内在的是代码质量， 外在的是对外表现的行为是否符合预期，不符合就是Bug了。
祖传代码的外在质量是不错的，毕竟是经过血与火的考验的。
如果重写，你能保证内在的代码质量和外在的行为都超越祖传代码吗？
重写不能保证业务中断，这是基本条件， 2010年在华为做敏捷咨询，华为有个口号我记得非常清楚： 要在高速公路上给汽车换轮子，这可能吗？ 据说华为有团队真的做成了，如果是真的，确实让人佩服。
3. 寻找优秀架构的影子
祖传代码虽然乱，但是初始的架构一般还是优秀的。
我在华为就看到有个产品是这样的，应用层堆积起来的代码看起来很差劲，但是仔细瞧瞧，依稀可见优秀架构的影子，这肯定没有守住， 后来慢慢腐化了。
所以面对祖传屎山代码，要捏着鼻子，抛弃细节，在里边努力搜索优秀架构的影子。
从功能上看，系统分为哪些组件，组件之间是如何交互的？
从技术上看，这些组件部署到了什么样的软件上？ 组件之间交互用了哪些协议，同步还是异步？数据再组件之间如何流动？
一些核心组件的内部是如果进行再次划分的，如何分层的？
总之，要回答这么一个问题： 如果是我，我能独自把这个系统给搭建起来吗？
总有一天，你会成为这样的人， 要做好储备。
4. 在自己的范围内尽量重构
面对祖传代码，初心不改。
努力把自己的代码写好，能重构的地方尽量重构，哪怕是一个函数，一个变量名。
这些都是自己赖以生存的技能，不能因为祖传代码烂，自己写的代码更烂！
重构和测试不分家， 把自己的单元测试写好，把功能测试做好，必要的话请测试人员帮个忙。
一定要有勇气去做，尤其是面对屎山代码的时候。
要对得起自己，不能坑了自己。
5. 看优秀源码
祖传代码虽然有优秀架构的影子， 但是看多了也会吐的。
在这个世界上还是有优秀源代码的， 尤其是开源的代码， 它们没有进度的巨大压力，维护者有足够的时间打磨自己的代码， 像一个工匠一样。
我知道的一些优秀源码有这些： JUnit，Redis，SQLite, Spring等。
这写代码现在都很庞杂了，看起来很累，最好去找他早期的源码，要简单得多，并且基本架构还在。
比如JUnit早期代码，几百行的代码就把很多设计模式都给组合了起来，非常巧妙，设计模式看多少都不如看一个活生生的例子。
看完以后，自己尝试着造一个轮子，把主要思想都给体现出来，你的功力至少上一个层次。
