程序员技术衡量标准 绩效_衡量和管理技术债务的5种最佳做法

程序员技术衡量标准 绩效

对于任何管理技术债务的开发组织来说，这都是一个巨大的挑战，这是过去软件开发工作中的决策所产生的大量工作。

解决技术债务通常会很快失败，因为这样做很少能解决紧急的业务需求，尤其是对于非紧急情况，投资回报率尚不明确，因此被认为可延期。 对于涉及维护的任何事情，无论是代码还是房屋，这都是一个经典问题。 但是，有一些方法可以衡量和管理技术债务，这将帮助您保持对技术债务的控制。

[ 小心！ 每个开发人员应该避免的8个职业陷阱 。 • 要成为一名真正的软件开发人员，必须阅读7本书 。 • 即使是经验丰富的开发人员，也会犯15个菜鸟错误 。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

您今天开发的应用程序如何演变为明天的遗留应用程序？ 您和开发团队正在按定期的发布计划来冲刺和发布应用程序改进，因此可能很难想象这些应用程序将来会变成旧状态。 您可能还想知道今天在开发应用程序以减少其成为旧版应用程序的风险时该怎么做。

应用程序不会在一夜之间成为遗留物，它们之所以成为这种方式，是因为有两个主要因素：

• 随着应用程序的老化，组织可能会分配更少的人来维护它，而是将人们转移到更具战略意义的项目上。
• 鉴于专注于新活动，团队致力于解决应用程序技术改进的时间可能会随着时间的流逝而变小。

这些技术改进的积压被称为技术债务 。 开发团队必须维护技术债务来维护应用程序的体系结构，底层平台和代码。 技术债务的例子包括：

• 一些小事情，例如围绕一段代码要做的事情，应该在有更多时间实现更强大的解决方案时进行重构。
• 实施一项复杂功能后，维护工作被遗忘了。 团队可能用很多故事点来估计该功能，但是产品所有者仍然优先考虑其开发。 然后，它是出于最好的意图而开发的，但是事后看来，可能会有更高效，更强大的实现。 这造成了技术债务的另一个来源。
• 为一个简单的用例开发的代码模块，但是随着时间的推移，它的重构意味着该代码将用于更广泛的用例。
• 有时，在没有适当的“脚手架”的情况下发布代码会使代码在生产环境中更强大。 支架包括应用程序日志记录，错误检查，异常处理，文档和其他工件。
• 有时，可以更好地将代码模块作为独立的微服务进行管理。 某些人可能会将这种过渡视为体系结构升级，但我仍将其标记为技术债务，因为这是技术驱动的改进。
• 有时，团队使用库或服务的新版本部署新代码，而将旧代码的升级留给以后。 这种延迟会造成技术债务。
• 升级和修补平台，第三方服务，开发工具以及与新API版本的连接也是技术债务的形式。

测量此债务可以表明开发团队认为需要多少工作才能最好地支持应用程序。 具有大量且不断增加的技术债务的应用程序是向着传统状态迈进的有力指标。

维护应用程序并避免或至少延迟旧状态的秘诀在于组织和团队如何管理技术债务。

利用所有这些技术债务来源，不同规模的技术组织如何处理这些问题？ CIO面临的最棘手的问题之一是管理遗留系统和技术现代化，因此我们对管理技术债务有着既得利益。

美国东部时间每个星期四下午2点，我会使用#CIOChat标签参加Twitter聊天。 我向该小组询问了他们的技术债务战略，并包括了他们在接下来的五种最佳实践中如何最好地衡量和管理技术债务的想法。

没有某种捕获细节并进行管理的方法，您将无法解决日益严重的问题。 正如Cloud Technology Partners的副总裁兼首席架构师Ed Featherston所说：

一切都是权衡。 技术债务是直接的结果。 权宜之计的决定是留下必须偿还的债务。 我所看到的最好的处理方法之一是将特定的技术债务积压与产品积压分开。 这样可以使累积的债务具有可见性/透明度，并且每个Spring都应包括产品和技术债务的故事。

在积压中逐项列出技术债务对于敏捷团队来说是一门重要的学科。 可以在确认技术债务后在sprint中完成，并且可以在sprint追溯中捕获。 Featherston和我在这里有所不同：我更喜欢在同一积压订单中同时捕获产品增强功能和技术债务，但要用标签或一个或多个史诗标记技术债务用户的故事和任务。 但是，只要团队和产品所有者对每次冲刺中添加和解决的技术债务都具有可见性，则这两种方法都有效。

大多数开发组织都有一种管理应用程序发布的方法，其中可以根据发布的目标范围和时间做出决策。 甚至练习更连续发布周期的团队也会召开会议，以审查短期和长期优先事项。 在这些会议中，架构师和开发人员可以说出哪些功能优先事项是复杂的，并可能导致新形式的技术债务。

换句话说，Affinitas Life的CDO和CTO Wayne Sadin说：

通过确保项目预算/计划明确解决持续的维护成本并包括要更换的系统的报废（日期/成本/过程），停止增加技术债务。 填充Kong的第一步：停止挖掘！

萨丁在计划会议上暗示了几项强有力的管理原则：

• 在计划时讨论复杂的功能，并寻求更简化的解决方案，使其更易于实施，并减少技术负担。
• 确保将团队优先级的一部分用于解决技术债务。 我的经验法则是， 应将发行速度的30％用于解决债务 ，发行计划会议是讨论和辩论优先级的好地方。
• 尽管我们所有人都喜欢构建新应用程序并致力于创新，但是开发组织还需要集中精力淘汰旧平台，应用程序，库和代码模块。 这也可以计入发布计划中。
• 最后，可能也是最重要的是，技术组织如何管理新技术的选择和采用，包括开发平台和库。 如果您选择某项技术是因为它是“次优”，而“次优”则与已经使用的技术重叠，那么您正在创造新的技术债！

开发人员的主要实践之一是实施持续集成， 持续测试和持续交付管道或CI / CD管道 。 这种自动化将代码检入版本控制系统中，打包应用程序，将代码交付到开发或测试环境，并通过一系列回归测试运行。

借助这种自动化，团队可以更有信心地对代码库进行小的，增量的更改，因为部署是通过脚本编写的，而回归测试可以确定应用程序的问题。

[InfoWorld的要点： CI / CD入门：使用CI / CD管道自动执行应用程序交付 。 • CI / CD的5个常见陷阱-以及如何避免这些陷阱 。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

将其与没有进行此自动化或测试的传统应用程序进行对比。 开发团队担心更改这些应用程序，因为他们不知道会破坏什么以及部署是否可以可靠地执行。 这种担心减慢了团队解决技术债务的速度，并加速了应用程序的继承地位。

较小的技术债务项目，例如修复和重构代码，可以在发布的范围内完成。 但是，当涉及到较大的升级时，通常需要专门的“系统升级”版本来执行和测试升级。 在不引入新功能的情况下，最好执行系统升级，以便团队可以根据已建立的测试和已知行为来验证升级。

纪律严明的组织会执行周期性计划，以安排对企业和用户需求影响最小的这些升级时间。 正如奥克兰大学（Oakland University）的CIO Theresa Rowe所建议的那样：

我们通过对现有技术投资进行仔细的周期性计划来管理技术债务； 投资需要保留或与战略计划相匹配的计划叉车。

例如，如果您的应用程序在具有MySQL后端的Java上运行，则开发团队可能希望每年安排一次重大升级，以说明这些平台的主要发布周期。 然后，它应寻找使用率相对较低的时段来安排这些升级。

重要的是要认识到，大多数企业领导者看不到应用程序维护状态。 他们只有在可靠性不佳或所需的功能升级花费的时间太长或实施成本太高时，才可以感知传统应用程序。 换句话说，他们可以感知应用程序何时达到旧状态，但是他们对度量和管理导致它的技术债务的理解和可视性较差。

解决这一差距是技术组织的集体责任。 首先，通过测量。 第二，通过主动确定优先级并加以解决。 第三，创建报告或提供可见性的通讯工具。

翻译自: https://www.infoworld.com/article/3309258/5-best-practices-to-measure-and-manage-technical-debt.html

程序员技术衡量标准 绩效