[译]开发者与熵的博弈

原文：https://itnext.io/entropy-in-software-development-77ed9110ef28
翻译：我的文章翻译智能体 + 文章润色智能体 + 文章转脑图智能体+ 人工校对
文章脉络：
在这里插入图片描述

文章概括：
文章通过热力学的视角，深入探讨了软件开发中的复杂性管理问题，提醒开发者在面对时间和熵的挑战时，要保持对系统的持续关注和高标准的开发流程。

译文：

在这里插入图片描述

“软件如同熵：难以捉摸、无形无质，并且遵循热力学第二定律——它总是在增长。” ——诺曼·奥古斯丁

熵是一种衡量系统无序、混乱和不确定性的物理量。正是熵的存在，使得沙堡终将崩塌，回归海滩。

它解释了为什么冰块会融化成水。
为什么人类会衰老，而非变得年轻。
为什么代码会腐化、文档会失效。
为什么儿童的房间会变得凌乱，而不会自动保持整洁。

⠀

在软件开发中，熵同样无处不在，开发者必须不断努力对抗它，以防文档过时、代码腐化和技术债务的无序积累。每一次代码修复、每一行新增代码，都会不可避免地增加系统的复杂性，逐步侵蚀原有的设计。
若不通过有效的开发流程控制熵，混乱将不可避免地导致系统复杂性的急剧上升，进一步加剧开发过程中的混乱。

熵的影响

每当我思考熵的作用时，总会联想到热力学第二定律。

热力学第二定律指出，整个宇宙作为一个孤立系统的熵状态将随着时间的推移不断增加。这一过程是不可逆的，宇宙中的熵变化永远不会减少。

开发者们往往本能地意识到熵的危险，却很少在繁忙的开发和紧迫的截止日期中抽出时间去深入思考这一问题。

不断向代码库中添加新代码行会积累技术债务，最终将代码库演变为遗留系统。
文档或缺失，或无法跟上软件的演变。
需求逐渐脱离代码和定制化实现。

⠀

在软件开发中，虽然熵不可避免，但我们仍然可以通过精心的设计来减缓其进程。要有效控制技术债务，保持系统秩序，需要投入大量精力。这里的“精力”指的是良好的实践、严格的标准、DevOps流程、测试策略、定义明确的完成标准，以及严格的代码审查。高质量的代码审查是防止熵扩散、确保开发标准执行到位的关键措施之一。

熵的无处不在

一次，我在生产环境中修复了一个错误，并借机重构了部分代码（试图管理技术债务）。虽然错误修复得很顺利，但重构却引发了新的问题。
一位资深开发者严肃地告诫我：

永远不要修改运行正常的代码。

他接着补充道：

如果它没有 BUG，就不要修。

这让我陷入了矛盾：一方面，我希望通过改进代码来提高其可读性和质量；另一方面，我也明白，每次更改代码时都有可能引入新的问题。
复杂的代码如同“切斯特顿的围栏”，在了解其真正作用之前，不能轻易拆除。这道围栏可能是为了防止入侵，也可能是为了保护某些内部机制。
“在你了解设置原因之前，永远不要拆掉一面围栏。”——G. K. 切斯特顿

在移除或更改代码之前，首先考虑切斯特顿的围栏。代码的存在必然有其原因，可能是功能性的，也可能是为了维持系统的稳定。
开发者们常常会看着代码库中的旧代码嘲笑其作者的愚蠢，直到他们意识到那正是自己几个月前编写的代码——然后迅速将责任归咎于刚离职的同事。
要真正自信地更改代码，唯一的途径是通过全面的单元测试。修改后运行测试，以确保一切正常。
一个月后，生产环境中再次出现了新问题。这次的问题源于我们使用的DLL库被弃用，导致了兼容性问题。
在软件开发中，即使软件运行良好，你仍然需要主动维护和更新它，因为环境总在变化。系统升级、新功能发布、版本更新、旧版本弃用，这些都会对现有软件产生影响。
因此，必须保持对软件的持续关注，良好的源代码控制、DevOps流程和完善的文档是必不可少的。有一天，总会有人需要维护这个软件，而那时原开发者可能早已不在。

时间对软件开发的影响

讨论熵时，不可避免地要提到时间之箭，它代表着时间只会向前流动的单向性，且不可逆转。
科学家布莱恩·考克斯描述了时间之箭的不可逆特性：
时间之箭决定了每一个瞬间的变化是不可逆的。我们的人生因而充满了喜悦与悲剧。随着时间流逝，我们逐渐变老——人们出生、生活、然后离去。而在宇宙中，那些宏大而史诗般的循环似乎永恒不变，但那只是一种错觉。正如在我们生活中一样，宇宙的一切也在不可逆转地变化。

在一个软件项目中，时间越长，潜在的问题就越多。
时间、人员和需求的变化会导致错误、问题、优先级变化、人员流失和技术债务的积累。
在一个软件项目中，如果有可能出错的事情，那么最终它一定会出错。

技术灾难不应让开发者措手不及。虽然无法阻止错误和灾难的发生，但你可以做好准备。良好的实践和开发流程能够确保你在问题发生时迅速恢复。
新冠疫情并非“黑天鹅”事件。类似的全球性大流行曾多次发生，大多数政府都有应对预案，但他们的响应速度过于缓慢。
这不是一个黑天鹅事件，而是一个完全可预测的事件。我们知道它会发生，却未能做好准备。——亚历克斯·塔巴罗克

在软件开发中，有些错误和事件本不应该发生。开发团队必须预见并提前准备，以应对潜在的危机。

软件开发中的技术债务悖论

软件开发中存在一个悖论：开发者的职责是保持高质量，而他们的开发流程（如标准、代码审查、完成定义等）也旨在确保这一点。然而，管理者、客户和项目计划往往会优先考虑速度，而非质量。他们更关注项目的快速交付，哪怕这意味着技术债务的累积。
管理者和客户的目标与开发者的目标相冲突，最终只能通过折中的方式找到一个既不太慢又勉强可接受的质量平衡。
开发负责人在此过程中扮演着关键角色，他们决定了项目的质量标准并控制技术债务的积累。
格雷欣法则解释了为什么劣质代码会取代高质量代码。如果糟糕的代码与优秀的代码同等受重视，那么开发者将倾向于选择更快、更简单的方式来完成任务。
在软件项目中，开发者缺乏编写高质量代码的动机，因为他们往往因为快速交付低质量的代码而受到奖励。