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

2020-11-28 22:22:44

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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