始终保留比您发现的更好的代码

我花了很多时间来维护工作代码。我认为这比软件开发人员的工作更典型。是的，肯定有一些工作需要编写更多的新代码，而不是维护，升级，错误修复和改进旧代码（没有产品市场适应性的启动公司，而提供咨询的另一种），但是总的来说，代码很昂贵，人们希望将其用于很长时间。

通常，您会跳入代码来修复错误，调查问题或回答问题。

当您这样做时，请对其进行改进。这并不意味着您重写它，或升级它依赖的所有库，或重命名所有变量。

但是你应该做得更好。只是清理一点。这样做可以使每个人的生活变得更好一点，以可持续的方式帮助代码库，并通过使其支持的基础架构更加灵活来帮助企业。

无论是注释说明了某些棘手的问题，还是代码外部的较大文档来解释如何与之交互，还是修正了错字，可信赖的文档，这都是与代码进行交互的关键。这是开始改进代码库的好方法，因为它对实际代码的影响最小。因此，它是低风险的。但是，如果您曾经在注释中解释过一些令人困惑的代码，那么您将不胜感激，因为这样做可以节省时间。

您也可以通过删除旧的，笨拙的文档来帮助文档。如果您看到不适用的评论，请将其删除。如果存在不适用的剪切和粘贴文档，请删除它。这将清理代码，以便下一个人（可能是您）出现。

测试可以帮助您编写可维护的，可扩展的代码，其他人可以毫不费力地更改它们。如果您运行未经测试的代码，并且有足够的时间和支持框架来编写代码，请这样做。

即使它测试了诸如“我可以实例化该对象”或“当我向它传递两个空值时该函数如何反应”之类的简单功能，另外的测试也将有助于代码的鲁棒性。

这是最灵活的改进之一。重构代码的范围可以从重命名变量以使其更真实，到对整个模块进行全面检查。从小处着手，不要陷入完美。有意使代码更清晰。

重构很容易缠绕到车轴上，进行过多的更改并最终导致损坏。时间调整是我在重构时避免或至少最小化这种倾向的一种技术。如果我只剩下30分钟，那么我将缩小范围。

有关重构的警告。不要重构您不了解的内容。不要开车重构。与更熟悉代码的人讨论您的计划； git blame是你的朋友。尤其是如果代码没有经过良好的测试，则要确保所造成的伤害不会大于弊端。

有时这是一条曲折的道路，但是定期升级依赖项是维护代码的好方法。我记得在支柱上工作。对于公司来说，这是一个重要的应用程序，但是我们花了很多时间来升级依赖关系，因为这太痛苦了。最终，部分代码变得更难更新。整个应用程序无法从较新的技术和范例中受益，因为旧的依赖关系使其无法使用。

花时间更新依赖关系永远不会感觉很好。对我来说，这总是感觉像在运行。但是，如果您不这样做，最终依赖项将会终止，并且您将被迫更新。那会更加令人不愉快。

所有这些动作不仅可以帮助其他人，因为它们可以提高代码质量，还可以向其他开发人员提供有关如何这样做的示例。例如，在套件中编写第二个测试要比编写第一个测试容易得多。您可以剪切和粘贴许多设置代码，并仅调整不同的地方。文档的第一部分将启发更多。

代码不是一切，但它是重要的工作成果。每当您触摸它时，都应努力将其放在比这样做之前更好的地方。