技术债务管理_技术债务管理很重要：您无法继续在损坏的系统上进行构建

技术债务管理

每个软件公司都有一定的技术债务 &＃xff0c;这是通过在短期内采取捷径将代码发布出去而在长期内创造的额外开发工作。 技术债务可以采取糟糕的设计决策&＃xff0c;急需的重构&＃xff0c;技术升级和突出的错误的形式。

就像承担实际的金融债务一样&＃xff0c;技术债务现在会给您带来更多的时间&＃xff0c;但将来必须以利息偿还。 就像金融债务一样&＃xff0c;也有明智和不明智的方法来承担和管理技术债务。

在本文中&＃xff0c;我想讨论一下为什么重要的是要Swift偿还技术债务以及不这样做的后果。 我还将解决软件工程师在尝试安排时间处理技术债务时面临的一些常见障碍。

应该指出的是&＃xff0c;我是一名专业的软件工程师&＃xff0c;因此本文将反映该观点&＃xff0c;但是本文适合所有人。

让我们首先解决最基本的问题&＃xff1a; 为什么要减少组织的技术债务&＃xff1f; 毕竟&＃xff0c;您的应用程序运行良好&＃xff0c;到目前为止&＃xff0c;您还算不错&＃xff0c;当然您还需要完成更重要的功能工作&＃xff0c;不是吗&＃xff1f;

尽管这种推理方式很容易让人接受&＃xff0c;但您会采取类似的方法来管理您的财务债务吗&＃xff1f; 债务附带利息&＃xff0c;如果您还清债务的速度很慢&＃xff0c;利息很快就会累加。

Fabian Blank 在 Unsplash 上 拍摄的 照片

如果您每个月只用信用卡进行最低还款&＃xff0c;那么您最终可能还清数倍于您最初借入金额的款项。

相反&＃xff0c;使用典型的30年房屋抵押贷款&＃xff0c;每年多偿还一笔贷款会使贷款的总寿命减少数年&＃xff0c;并节省数万美元。

显然&＃xff0c;尽快摆脱您的财务债务很有意义。

是的&＃xff0c;偿还技术债务需要花费时间和精力。 它确实使您脱离了其他功能工作。 但是&＃xff0c;尽早还清技术债务是值得的。

让我们探讨偿还技术债务的一些好处&＃xff1a;

1.它使您将来可以更快地移动。

2.它可以让您保留顶尖的工程人才。

3.它可以帮助您避免每隔几年重新编写整个应用程序。

解决技术债务的普遍做法是“我们没有时间”。 如果我告诉您管理技术债务可以节省您的时间怎么办&＃xff1f;

每当我听到有人告诉我他们没有时间偿还技术债务时&＃xff0c;我都会想起这部漫画&＃xff1a;

斯科特·西默曼&＃xff08;Scott Simmerman&＃xff09;的卡通

显然&＃xff0c;拉动带轮的手推车比拉动带方轮的手推车要容易得多&＃xff0c;而且速度更快。 然而&＃xff0c;具有象征意义的是&＃xff0c;组织会发现自己在拖拉带有方轮的推车而没有意识到这一点。

马丁·福勒&＃xff08;Martin Fowler&＃xff09;在他的文章“高品质的软件值得吗&＃xff1f;”中阐述了解决技术债务和保持代码高质量的好处。 。

其中包含以下图形&＃xff1a;

图片由Martin Fowler提供

棕色线代表忽略技术债务并允许其代码库质量下降的软件公司的发展轨迹。 尽管它们在一开始就可以更快地发布功能&＃xff0c;但随着时间的推移&＃xff0c;交付速度会越来越慢。

糟糕的设计决策&＃xff0c;开放的错误&＃xff0c;过时的技术或任何可能的功能&＃xff0c;最终使功能开发陷入停顿&＃xff0c;因为使用复杂多变的代码库变得越来越困难。

另一方面&＃xff0c;蓝线代表软件公司的发展轨迹&＃xff0c;该公司了解保持高代码质量&＃xff0c;解决技术问题和及早修复错误的重要性。

尽管在开始时交付新功能确实起步较慢&＃xff0c;但在短时间之后&＃xff0c;他们在向客户提供价值方面就开始超过第一家公司。 这是因为他们在维护代码库健康方面所采取的谨慎态度可防止他们随着时间的流逝陷入困境。

这不是事实&＃xff0c;更是轶事证据&＃xff0c;但以我的经验来看&＃xff0c;那些无法解决技术债务的公司会失去他们最好的工程师。 没有人喜欢在越野车系统或项目中工作&＃xff0c;因为每天都在努力分配自己的工作。 很少有工程师喜欢使用“遗留代码”或使用已有数十年历史的技术。

Tim Gouw 在 Unsplash 上 拍摄的 照片

因此&＃xff0c;当开发人员的经验下降时&＃xff0c;软件工程师会做什么&＃xff1f; 那些能够找到更好工作的人去了其他地方。 换句话说&＃xff0c;组织的高级人才会留下而那些找不到其他工作&＃xff08;无论是由于缺乏需求的技能还是由于其他原因&＃xff09;的人会留下来。

因此&＃xff0c;如果您想保留顶级的工程人才&＃xff0c;则您的组织需要证明其与工程师一样重视高质量的代码。

公司为什么要从头开始重写他们的应用程序&＃xff1f; 有时&＃xff0c;这是一个非常正当的理由&＃xff0c;例如在现代化平台时需要摆脱20年前的过时技术栈。

但是&＃xff0c;由于我们前面在上面的Martin Fowler图表中讨论的开发速度问题&＃xff0c;有时应用程序需要从头开始重新编写。 开发人员的经验变得如此痛苦&＃xff0c;以至于最终您的工程师沮丧地举起了手&＃xff0c;说&＃xff1a;“我不能为此工作。 我们需要重新开始。” 经过许多长时间的交谈&＃xff0c;组织最终同意并决定从头开始重新编写该应用程序&＃xff0c;并为此花费了数百万美元。

照片由Amazon.com提供

我承认重新开始一个新项目很有趣。 您可以选择自己喜欢的编程语言和工具&＃xff0c;并且这次可以“正确地”设计一切。 &＃xff08;尽管将来&＃xff0c;其他开发人员可能对您的代码的感觉与您对当前旧版应用程序的感觉相同……&＃xff09;

但是可以避免这种情况吗&＃xff1f; 我的回答是&＃xff0c;是的&＃xff0c;如果您优先解决技术债务并避免事情一发不可收拾&＃xff0c;您可能会避免完全重写。

希望到目前为止&＃xff0c;您已经同意尽快减少技术债务是一件好事。 那么为什么不解决技术债务如此普遍呢&＃xff1f;

我可以想到一些原因&＃xff1a;

1.工程师认为要素工作更为重要。

2.工程师认为解决技术债务不是他们的问题。

3.工程师们害怕退缩产品和工程管理。

4.工程师无法有效地说服产品和工程管理。

让我们看看这些原因中的每一个&＃xff0c;并探索应对方法。

是的&＃xff0c;发布新功能很重要。 没有功能&＃xff0c;就没有产品。 但是您不能仅100&＃xff05;地开发功能。

当我听到有人告诉我功能工作更重要并且我们不能优先解决技术债务时&＃xff0c;我不得不问自己&＃xff0c;现在功能工作真的更重要吗&＃xff1f; 我们的客户真的希望在一个已经很慢且有错误的应用程序之上提供另一个充满缺陷的半成品功能吗&＃xff1f;

我在这里有点滑稽&＃xff0c;但是这个问题有些道理。 如果我们正在谈论为客户提供价值&＃xff0c;那么请确保提供良好的用户体验&＃xff0c;这意味着确保该应用程序性能良好&＃xff0c;并且没有使客户感到沮丧或阻止客户使用该应用程序的错误。预期目的。

一个让您同时使用功能和技术债务的不错的折衷方法是&＃xff0c;每个sprint花费约70–80&＃xff05;的时间来开发新功能&＃xff0c;而每个sprint则花费20–30&＃xff05;的时间来修复错误并解决技术问题。

塞巴斯蒂安·赫尔曼 &＃xff08; Sebastian Herrmann&＃xff09; 在 Unsplash 上 拍摄的 照片

如果工程师有这种感觉&＃xff0c;这很可能是潜在的工程文化问题的征兆。 我想在每个人都对代码库感到自豪和拥有所有权的环境中工作&＃xff0c;并希望使其达到最佳状态。 如果某人不具有相同的价值和愿景&＃xff0c;那么我可能不想与该人一起工作。

解决方案可能是&＃xff1a;1&＃xff09;尝试以更积极的方向影响工程文化&＃xff0c;或者2&＃xff09;让您离开公司&＃xff0c;以便您可以找到一个具有更好文化适应性的组织。

我在职业较新的开发人员中最看到这种恐惧。 他们可能会因为知道有一些重大技术债务需要解决而感到内心的冲突&＃xff0c;但他们害怕表达这种担忧。 也许是因为他们认为大声说出来会对他们产生不良影响&＃xff0c;或者可能危害他们的工作。

由 Icons8团队 在 Unsplash 上 拍摄的 照片

重要的是要记住&＃xff0c;作为软件工程师&＃xff0c;我们对公司在任何给定时间面临的技术债务有最深刻的了解。 我认为&＃xff0c;当技术债务继续被取消优先级或被忽略时&＃xff0c;我们实际上有义务表达这些担忧并退回产品管理或工程管理。

根据我的经验&＃xff0c;只要您认真表达自己的担忧&＃xff0c;退缩就不会给您带来尊敬。

这导致我遇到第四个&＃xff0c;也许是最关键的问题。 可以说&＃xff0c;作为一名工程师&＃xff0c;您确实同意解决技术债务很重要&＃xff0c;并且已经在产品管理和工程管理中提出了这一点&＃xff0c;但是他们没有听取。

Mimi Thian 在 Unsplash 上 拍摄的 照片

在这种情况下&＃xff0c;您不会感到无助&＃xff0c;而可能只是需要更清楚地传达您的担忧。 如果您只是在说“我们需要解决此问题”&＃xff0c;但您没有提供任何清楚的解释或原因&＃xff0c;说明您为何没有有效地进行沟通。

您应该提供背景信息&＃xff0c;说明您要优先考虑的技术债务为何如此重要以及这将给企业带来什么好处。 用非工程师的人可以联系和理解的术语来解释事情尤其重要。

例如&＃xff1a;

“我们确实需要花一些时间编写测试&＃xff0c;以增加此存储库中的代码覆盖率。 由于我们缺乏测试&＃xff0c;因此经常引入错误&＃xff0c;并且必须在生产中解决这些问题后再花些时间解决。 使测试套件处于更好的状态将使我们对代码更有信心&＃xff0c;并确保我们的客户也对使用我们的应用程序有更好的体验。”

或许&＃xff1a;

“我们现在有30个面向客户的开放错误。 这些给我们的客户带来了糟糕的体验&＃xff0c;甚至导致一个客户取消了与我们的合同。 我真的认为我们需要花费此sprint修复这些错误&＃xff0c;而不是研究此新功能。”

甚至&＃xff1a;

“我们的持续集成流程花费了太长时间。 我们必须等待一个多小时才能获得反馈&＃xff0c;以查看我们的构建是否通过&＃xff0c;并且这种延迟的反馈循环使完成任务花费了很长时间。 我真的认为我们需要花一些时间来优化我们的构建&＃xff0c;以使其完成得更快&＃xff0c;以便我们所有的工程师都能更快地移动。 试想一下&＃xff0c;如果我们的构建每次运行快十分钟完成&＃xff0c;并且分散到100位工程师中&＃xff0c;每位工程师每天创建五次新构建&＃xff0c;我们还能完成多少工作。 每天节省的集体开发时间超过83小时&＃xff08;10 * 100 * 5/60&＃xff09;&＃xff01;”

承担技术债务是不可避免的。 但是&＃xff0c;组织如何选择处理其技术债务会成败一家公司。 作为一名工程师&＃xff0c;我希望您感到鼓舞并有能力解决您目前在自己的角色中面临的技术债务。 这样做将使您的公司成为一个更好的工作场所&＃xff0c;也将为您的产品用户创造更好的体验。

翻译自: https://hackernoon.com/technical-debt-management-is-important-you-cant-keep-building-on-a-broken-system-rr5b32bd

技术债务管理