糟糕代码的后果不容小觑，必须加以缓解，以确保业务成功。
译自 Unraveling the Costs of Bad Code in Software Development，作者 Liz Ryan 是 Sonar 的产品营销经理。拥有近 15 年的经验，她是一位资深的产品营销、咨询和实施专业人士，擅长创造引人入胜的故事。
糟糕的代码一直是一个昂贵的问题。自 1980 年代以来，研究人员发现，在交付后修复问题的成本可能比早期识别和解决错误高出 100 倍。二十年后，国家标准与技术研究所估计，部署后的糟糕代码成本高出 30 倍。
2024 年，糟糕的代码继续困扰着公司，这是一个关键问题，因为企业依赖其软件的力量来实现目标并保持竞争力。代码比以往任何时候都更加重要和普遍，使得糟糕的代码成为更大的负担。
虽然生成式人工智能有望改变开发人员编写和检查代码的方式，并可能卸载部分代码编写工作，但现实是人类将始终是这个过程的一部分。由于人类并非完美，而且 GenAI 工具不断发展，因此应该预料到总会有错误出现。公司必须将软件视为业务关键资产，这意味着不能低估这些糟糕代码的后果，而必须采取措施以确保业务成功。
糟糕的代码影响软件的开发过程和整个生命周期。它往往难以理解，使得开发人员难以在以后扩展或修改。由于开发人员喜欢尽可能重用代码，如果一行糟糕的代码被复制并粘贴到不同的项目中，这可能会导致未来问题。它还缺乏可扩展性；它无法适应不断变化的业务需求或整合新功能。
糟糕的代码也可能成为 bug 的温床，因为隐藏的问题会突然浮出水面，变得昂贵且更难以恢复。这些问题积累得越多，技术债务就越多，而技术债务可能会变得非常昂贵。研究显示，五年内，相关成本可能高达 150 万美元或超过 27,000 开发人员工时。
修复这些 bug 需要时间。开发人员必须花费数小时解密糟糕的代码行并修复它们，这会占用他们编写新代码的时间，并导致整个开发过程的延迟，因为团队无法按时完成任务。糟糕的代码还会抑制生产力，使注意力从其他新颖的创新项目转移。
所有这些问题随着糟糕的代码继续滋生而不断积累。维护、修复 bug、重做和技术债务的成本不断增加，不仅影响开发团队，还影响公司，因为软件质量在下降。除此之外，糟糕的代码是一个重大的安全风险，可能会威胁声誉损失和合规问题，除了部署了包含它的软件的财务风险。
开发人员处于困境之中。由于业务领导者依赖其软件的力量和能力取得成功，开发团队比以往任何时候都更加紧张，工作负荷迅速变得不可持续和不切实际。已经有调查显示，这些工作者已经感受到了时间压力增加的影响，其中 83% 的人表示正在经历工作枯竭。
疲劳和对高效率、快速编写代码的期望可能会带来潜在的后果，特别是许多人转向 AI 编码工具以获取帮助。研究表明，因此，代码的频繁更改（称为代码抖动），即衡量两周内被抛弃的代码行数的百分比，正在增加，并预计到年底将翻一番。糟糕的代码不仅仅是一个静态问题；它正在恶化。公司如何才能在糟糕的代码问题变得灾难性之前消除它？
完美并不现实，但开发人员有工具和流程来确保他们编写和交付最佳的代码。干净的代码应该始终是目标 - 一致的、有意的、可适应的和负责任的 - 最终更容易维护。干净的代码提供了一种使企业能够实现目标并超越目标的软件。
开发人员如何确保他们编写和使用这种类型的代码？边写边清理的方法是答案。更早地、更全面地测试和分析可以在问题变严重之前发现问题。这样做可以确保，如果代码以后被重用，它将不受困扰项目和公司的错误和问题，这些错误和问题在开发周期后期会出现。
采用静态分析和单元测试措施可以使编码人员有效地进行工作，并捕获任何威胁到质量的问题。这种边写边清理的思维方式 - 工作更聪明，不一定更艰苦 - 也使开发人员能够更快地交付更高质量的软件。
开发人员不能等到开发过程的后期才发现问题并找到解决方案，也不应该如此。早期预防和质量保证是编写高质量代码和减轻技术债务的最佳途径，而不是增加技术债务。随着团队越来越习惯于使用人工智能来减轻他们的工作量，这种早期测试的重要性也日益增加。GitHub 最近甚至更新了其 Copilot 信息中心，警告称它可能生成“不良模式”，并补充说开发人员有责任确保其代码的安全性和质量。
事实上，企业必须认真对待糟糕的代码，因为它威胁到他们开发团队的工作负荷和生产力，以及他们的整体业务目标。在开发过程的早期优先考虑清洁的代码是公司将自己置于能够在现在和未来成功所必需的位置的唯一方法。