有一个话题经久不衰：程序员入职新公司后接手已有的代码，怎么处理？
程序员都有一颗工程师的心，所以当他们到一片新的场地想做的第一件事就是，将旧的一切推倒重来。是的，他们决不会满足于简单的增量劳动。
或许这种微妙的心理定位可以解释：为什么程序员进入新项目组后宁愿丢掉旧代码重新写，也不愿意修修补补，他们认为旧代码简直一团糟。
但是，事实上真是这样吗？你之所以认为旧代码一团糟，其实是由编程的一个基本定律决定的，那就是：写代码容易，读代码难。
为什么你觉得旧代码异常混乱？因为读代码更难
这大概就是代码Reuse难以实现的原因，也可以解释为什么你组里的每个人都喜欢用不同的功能将分割的字符串转换成一个数组。比起猜测旧的功能是怎样实现的，重新写一个自己的功能要简单和有趣多了。
作为这个公理的推论，你可以问问身边的程序员他们正在奋战的代码怎么样？”简直是一塌糊涂！”他们肯定会这样说。”我简直想推倒重来！”
为什么认为代码这么糟糕呢？”额，看看这个功能，竟然有两页长！完全不知道这些东西为什么在这里！完全不知道这些API是干什么的。”他们[……]
对于如何进行代码重构，一直有着很多种说法。很多人都认为应该将重构代码放在backlog里。但是其实，这并不是一个理想的方法。
在项目刚刚开始的时候，你的代码很干净。
即使有的时候需要小小的绕一下路，但是这个时候我们可以轻松、平稳的添加功能。这个阶段一般都不会出现问题，而且由于我们比较着急，所以即使出现了一些小问题，我们也不会注意到。
然而，随着项目做的时间变长，这些小的问题就会累计起来。这就是人们所说的“技术债务“。其本质，就是并不算特别好的代码，但是这个时候其问题还没有完全显现出来。
但是，随着我们一直添加新功能，这些问题就会逐渐显现出来，我们不得不小心翼翼的绕开他们。
不可避免的，我们的开发速度会被拖慢。但是为了追求速度，我们开始变得越来越不小心，不久之后，问题也会越来越多。
这些问题会像积木一样累计起来，层层叠叠，让我们的开发速度变得更慢。虽然我们终于意识到了问题的存在，但是没有时间彻底解决它。我们只能继续小心翼翼的绕开它们。
很快[……]
有下列情形之一的，你患上了代码洁癖症。症状程度可轻可重，轻者帮助写出优雅整洁的代码，重者走火入魔，万劫不复。
里氏替换原则是1987年麻省理工学院一位姓里的女士提出的关于继承方面的原则：子类必须确保父类的行为不被修改，即子类不能覆盖父类的非抽象方法。
只有这样才能确保子类能够替换父类的任何对象。通俗一点说就是 老鼠的儿子会打洞。
里氏替换原则是关于继承方面的原则，子类可以实现父类的抽象方法，不能覆盖非抽象方法；子类可以扩展自己的方法。该原则确保父类的行为不会改变，后续有对系统做者扩展时，能够保障系统的稳定性。