世界上最简洁易懂的代码，是自己刚写出来的代码。世界上最烂的代码，就是自己一年前写出来的代码。关于旧代码，我们经常能听到：“这段代码谁写的，也太垃圾了吧”之类的抱怨，就好似开发者和维护者的立场天然对立一样，当然也可能是一年前的自己和现在的自己是对立的哈哈。

对历史代码的不信任，也会导致代码的设计被破坏，相当于在摇摇欲坠的门框上又踹上一脚。毫无疑问，DRY是非常正确的，我们将其当作教条，并唾弃重复的代码。但是在维护一个遗留下来的项目时，我们却可能会害怕重用之前的代码，觉得之前的代码写的看不懂，没法维护了，得重新写一个。

不知道之前的这段代码被哪些地方依赖，与其害怕改出毛病，不如重新写一个，然后只能加上了一堆至少自己能明白的代码。但如果这段代码还能被后面的人维护，他们大概率也不会信任我们的代码了，周而复始。

是什么原因造成这种信任感的缺失呢？最主要的原因是我们不知道这段编写旧代码的具体场景了。

从维护者的角度来看，如果我们已经不清楚或者已经忘记了相关的逻辑，除非从头深入研究它们，否则我们很难理清这段旧代码的上下文。我之前修改过一段我认为很烂的旧代码，快改完的时候才发现，“哦，原来他这里是因为xx才需要要这样写”，然后又把代码给回滚回去了。

测试用例好像是一种维持信任感的有效方式，如果有测试用例，我们在修改之后还能跑一遍看看哪些地方不会通过，这样就能定位我们改动造成的影响（如果覆盖率足够高），但不幸的是，很多历史代码可能都没有测试用例。

虽然CSS算不上编程语言，但用来举例证明这种不信任感还是不错的。在没有css modules或者css scoped之前，整个应用的样式都是全局作用域的，假设我们现在要实现一个.title的类，就需要去历史的样式表中全局搜索是不是已经存在.title这个类了，否则可能会出现样式冲突、或者影响其他样式的地方。

为了偷懒，我们可以借助CSS 权重值计算规则进行样式覆盖，加个!important或者再加个标签.xxx .title之类的覆盖一下，以至于社区出现各种诸如BEM命名规则的方案，来解决这种情况。

此外包括zIndex等层级属性，也存在类似的信任问题，为了避免我的弹窗被代码角落的某个样式影响，直接写9999...续上接N个9，不管后面代码的死活。