拥抱代码的短暂性

网站会发生变化。健康的代码库会不断更新。遗留代码最终会随着项目的消亡而消亡。认识到我的代码是短暂的，让我能够更务实地对待我的代码，以及在编写代码时指导我的决策。

你的代码是短暂的。

我喜欢认为代码更改源于以下两种原因之一：代码腐烂或网站相关性。

接受变化

变化的现实似乎是一件相当明显的事情，然而，我发现它对我有帮助，作为一个倾向于像建造吉萨大金字塔一样进行编码的人。编码通常更像是搭帐篷，不知道我们会停留几天还是一年。我尝试从假设它会很短暂开始，然后随着时间的推移安顿下来。在挖整个井之前，考虑在商店里买一些价格过高的水。我经常发现自己在搭帐篷几天后就陷入狂热的搬迁中。我不需要回顾几个月就能找到我编写的、现在需要更改的代码。它不需要更改，因为我第一次做得不够好——只是时候更改它了！这应该如何影响我们编写代码或思考代码的方式？以下是我最近采用的几点想法。

1) 编写短暂的代码。

知道我的代码在不久的将来可能会发生变化，让我能够专注于它的当前目的并确保它的足迹是孤立的。它让我能够专注于眼前的代码，而不必被我正在编写的代码的未来时间线所分心。这对于小型项目的很大一部分尤其适用。对于大型项目，你可以将此原则应用于代码库的各个部分。如果你在一整年里使用过库中的某个组件，那么通常它的需求会随着时间的推移而发生变化。移除过去的累赘可以帮助它为即将到来的未来赋予目标。我经常发现编写替换组件比更新旧组件更快，并且结果更容易使用和理解。在适用情况下，我尝试替换而不是修复。当我创建新事物时，我优先考虑现在，相信我将来会给自己空间来解决未来的问题。未来的问题通常最好在未来解决，因为你越接近问题，你往往掌握的事实越多，假设越少。

2) 尽可能避免依赖项。

我越来越倾向于内置的浏览器功能，并且在证明使用框架的合理性时设置了很高的门槛。在某些规模上，依赖项是不可避免的，并且在协作环境中经常更高效。当我确实使用它们时，我会尝试隔离或封装它们的功能，以便以后如果需要，更容易解开它们。如果你可以证明编写自己的代码的努力是合理的，你将更加熟悉网络规范并了解它们本身的强大功能。你最终也会得到一些长期更容易维护的东西，因为它最接近网络的核心进化路径。你的代码和不断发展的浏览器功能之间没有依赖项升级。

3) 让代码消亡。

虽然这对于不需要因重要原因（如可用性）而更改的情况来说只是一个可接受的结果，但这是我在有意义的情况下最喜欢做的事情。让事情变老。不要打算更新它们。创意项目和演示是此功能的一个很好的案例。通过让旧项目消亡，我承认它们的值与它们存在的时间点紧密相关。并非所有东西都需要永远存在（剧透，我们制作的任何东西都不会永远存在）。如果某些内容很重要并且你想要保留它，可以通过屏幕录制和文档来捕捉其意义，然后继续前进。这让我能够更自由地进行下一步操作。

展望未来

对我来说，作为一名编写代码的人，我能做到的最冥想和恢复活力的行动就是反思我编写的代码是短暂的事实。当我们谈论工具、最佳实践和新兴事物时，这个领域往往充满对抗。采用“最佳”方法的紧迫感在我们计划项目时施加了巨大的压力。我们以绝对的语气谈论持久性，并且经常忽视我们的观点在不久的将来会显得多么过时。当您做出有关工具的决策时，风险最终永远不会像您感觉的那样高。

我更喜欢处于一个不断认识到我编写的代码是临时的、技术发展速度超过我个人能够跟上的速度、并且我永远不需要在所有事情上都拥有专业知识的位置。在这里，我感到欣慰，因为我知道我编写的最好的代码就在我面前，并且我现在可以制作的最好的网站就是下一个网站。