技术债务管理_管理技术债务

技术债务管理

DevOps Essentials

DevOps基础

介绍 (Introduction)

Technical debt is one of the most insidious and damaging phenomena in software development. If left unchecked, it can destroy projects, products, entire software organizations, and even companies. Anybody that has worked on software intended to live for more than a few months is familiar with the signs that it has taken root:

技术债务是软件开发中最隐蔽和最具破坏性的现象之一。 如果任其发展，它可能会破坏项目，产品，整个软件组织甚至公司。 任何从事打算使用几个月以上的软件的人都对它扎根的迹象很熟悉：

• Making changes to code seems to take longer and longer over time
  随着时间的流逝，对代码进行更改的时间似乎越来越长
• There is low confidence in the quality of the software because changes often lead to regression bugs, and so a fear of change develops
  对软件质量的信心较低，因为更改通常会导致回归错误，因此人们对更改产生了恐惧
• The code is hard for anyone (even the author) to understand
  该代码对于任何人(甚至是作者)都很难理解
• Maintenance activities, such as updating dependencies, are almost always significant undertakings, and so the codebase is increasingly out of date
  维护活动(例如更新依赖项)几乎总是重要的工作，因此代码库越来越过时了
• Release cycles are in weeks, months, or even years
  发布周期为数周，数月甚至数年

These are undesirable traits leading to an inevitable end-state where all forward progress halts.

这些是令人讨厌的特征，导致不可避免的最终状态，所有前进进度都将停止。

So if tech debt is so dangerous, why do software organizations allow it to accumulate? You would think that organizations would make it a point to prevent it. If only it were this easy!

因此，如果技术债务如此危险，为什么软件组织允许其积累债务？ 您可能会认为组织将其作为预防的重点。 如果只是那么简单！

In this article, we’ll explore some of the reasons technical debt accumulates and look at a few approaches to manage it better.

在本文中，我们将探讨技术债务积累的一些原因，并探讨一些更好地管理债务的方法。

定义 (Definition)

The term “technical debt” was coined by Ward Cunningham in the 1990s:

“技术债务” 一词由Ward Cunningham在1990年代提出：

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.- Ward Cunningham, 1992

交付第一次代码就像陷入债务。 只要通过重写Swift偿还债务，一点债务就能加快发展速度。如果不偿还债务，就会发生危险。 花在不完全正确的代码上的每一分钟都算作该债务的利息。 整个工程组织可能会因为无法合并的实施，面向对象或其他原因的债务负担而停滞不前。-Ward Cunningham，1992年

To paraphrase: technical debt boils down to all of the shortcuts that development teams have taken during execution and never loop back to address. It can refer to subpar code, weak architecture, brittle infrastructure, sloppy development processes, or any number of sub-optimal work. The buildup of these things always results in friction in the development workflow, with the result being that it takes longer and longer to change or add code until development progress stops.

简而言之：技术债务归结为开发团队在执行过程中采取的所有捷径，从不回头解决。 它可以引用低于标准的代码，脆弱的体系结构，脆弱的基础结构，草率的开发过程或任何次优的工作。 这些东西的累积总是会导致开发工作流程的摩擦，结果是更改或添加代码需要花费越来越长的时间，直到开发进度停止。

Another way to think of tech debt is from the Lean perspective, which is to see it as a form of waste in the system. There is much more to the concept of waste in Lean thinking, but for our immediate purposes, we’ll say that waste is anything in our workflow that does not help us deliver value to our customers. Tech debt certainly falls into this category because it directly inhibits our ability to progress through our workflow at a reasonable speed.

从精益的角度考虑技术债务的另一种方法是将其视为系统中的一种浪费 。 精益思维中浪费的概念还有很多，但就我们眼前的目的而言，我们会说浪费是我们工作流程中无法帮助我们为客户创造价值的任何事物。 技术债务肯定属于此类，因为它直接抑制了我们以合理的速度完成工作流程的能力。

Whatever you call it, technical debt is not something we want to be overwhelmed by. Let’s attempt to understand it a bit better so that we might think of ways to avoid it.

不管您怎么说，技术债务都不是我们不希望所为。 让我们尝试更好地理解它，以便我们想办法避免它。

因果 (Cause & Effect)

两队的故事 (A Tale of Two Teams)

We won’t be starting our discussion by talking about the evils that lead to technical debt (don’t worry, we’ll get to that later). Instead, we’ll use a couple of scenarios to tell the all-too-familiar story of how one team’s (Team Blue) attitude towards technical debt can have a massive negative impact on its trajectory and contrast it with their counterparts (Team Green). This example is by no means a precise model. It merely describes the general order of events and the effects. We can use this to compare one team that ignores technical debt with another that embraces the practice of addressing it incrementally.

我们不会通过讨论导致技术债务的弊端来开始我们的讨论(别担心，我们稍后会介绍)。 取而代之的是，我们将使用几个场景来讲述一个团队(蓝队)对技术债务的态度如何对其轨迹产生巨大负面影响并将其与同行(蓝队)进行对比的故事， 。 这个例子绝不是一个精确的模型。 它仅描述事件的一般顺序及其影响。 我们可以用它来比较一个忽略技术债务的团队和另一个采用增量解决方案的团队。

As stated before, this is a generalization of what might happen. Often the decline isn’t as steep as drawn here. It can be much more gradual over a more extended period. It’s drawn like this because of the opposite case where there is a tech debt “wall” of sorts. It can manifest through the sudden realization that debilitating debt has crept up on the team, and an overriding sense of urgency emerges to address it. For example, management might insist that tech debt be focused on once they hear that changes that were taking days now take a month.

如前所述，这是可能发生情况的概括 。 通常，下降幅度不如此处绘制的那么陡。 在更长的时间内，它可以变得更加渐进。 之所以这样绘制，是因为存在相反的情况，即存在各种技术债务“隔离墙”。 突然意识到，使团队衰败的债务已经蔓延开来，这可以表明，解决这一问题的压倒一切的紧迫感出现了。 例如，一旦他们听说需要几天的更改现在需要一个月的时间，管理层可能会坚持要求将技术债务集中在重点上。

Sometimes there is a more obvious breaking point where forward progress completely stops until the team addresses some issue. What follows is a ripple effect where addressing the main issue means some other seemingly peripheral issue first needs to be addressed, which itself requires yet another problem to be solved. This situation can arise in cases where core dependencies are left too long, and the upgrade becomes urgent and painful. Either way, the scope of the work has expanded because tech debt was allowed to set in.

有时会有一个更明显的突破点，即前进的进度会完全停止，直到团队解决某些问题为止。 接下来是连锁React，其中解决主要问题意味着首先需要解决其他看似外围的问题，这本身又需要解决另一个问题。 如果核心依赖项保留的时间过长，并且升级变得紧迫而痛苦，则会出现这种情况。 无论哪种方式，工作范围都扩大了，因为允许增加技术债务。

If you’ve experienced any of these situations yourself, then you’ll recognize some of the effects that technical debt can have. If you identify more with Team Blue, then this article is for you.

如果您自己经历过上述任何一种情况，那么您将认识到技术债务可能产生的某些影响。 如果您进一步了解Blue Team，那么本文适合您。

Let’s take a closer look at some of the causes and effects of tech debt.

让我们仔细研究一下技术债务的一些原因和影响。

不断增加的开发成本 (An Ever-Increasing Cost of Development)

Accumulated tech debt directly impacts cost. Changes that might take minutes in codebases with low tech debt take hours in ones with high tech debt. Tech debt also leads to regressions, which means spending an unpredictable amount of time fixing work already considered done. In response, teams eventually introduce additional rigour around testing, costing more time and resources to put in place and maintain. We should mention that testing effort is, of course, right, but it does tend to leave tech debt unaddressed because it shifts focus away from the injection point of tech debt: development. The trend that emerges is that everything is harder and takes longer in tech-debt-ridden codebases.

累积的技术债务直接影响成本。 在技​​术债务较低的代码库中，可能要花几分钟的更改，而对技术债务较高的代码库则要花费数小时。 技术债务还会导致回归，这意味着花费不可预测的时间来修复已经考虑完成的工作。 作为响应，团队最终会围绕测试引入更多的严格性，从而花费更多的时间和资源来进行部署和维护。 我们应该提到，测试工作当然是正确的，但是它确实使技术债务无法解决，因为它将重点从技术债务的注入点转移到了发展上。 出现的趋势是，在技术债务缠身的代码库中，一切都变得更加困难，并且花费的时间更长。

If we’re talking a difference of minutes or even hours, this may not seem like a big deal. However, it’s rarely that minor. Unaddressed tech debt compounds over time, which usually leads to exponential increases to the amount of effort necessary to make code changes. So we’re talking about weeks or even months. We can see this in organizations that continue to release at a cadence of months, quarters, or worse.

如果我们谈论的是几分钟甚至几小时的差异，这似乎没什么大不了的。 但是，很少那么小的。 随着时间的流逝，未解决的技术债务问题通常会导致代码更改所需的工作量成倍增加。 因此，我们谈论的是数周甚至数月。 我们可以在以几个月，一个季度或更糟的节奏继续发布的组织中看到这一点。

Eventually, codebases become so difficult and expensive to work with that leadership deems it “throwaway” or flags it for a “significant refactor,” which is just another way of saying “rewrite the code.” We saw this when Team Blue hit Stage 4 and had to deal with the reality of their situation.

最终，与领导层一起使用时，代码库变得如此困难和昂贵，以至于领导层认为它“被抛弃”或标记为“重大重构”，这只是“重写代码”的另一种表达方式。 当Blue Team进入第4阶段并不得不处理其实际情况时，我们看到了这一点。

A rewrite is the most expensive action there is when it comes to maintaining a codebase, and should only be done in the direst of needs. Some people may think that this is just the way it works in software because this is the way that they’ve been developing software for years.

当维护代码库时，重写是最昂贵的操作，并且仅应在最紧急的情况下进行。 有些人可能认为这只是软件中的工作方式，因为这是他们多年来开发软件的方式。

However, one of the core tenets of Agile software development practices is to establish evolvable codebases that can be resilient to change and to make rewrites mostly unnecessary. Modern software techniques are all about optimizing cost through efficiency and building robust products. So there is another path. That’s the path Team Green took.

但是，敏捷软件开发实践的核心原则之一是建立可演化的代码库，这些代码库可以灵活地进行更改并可以进行大部分不必要的重写。 现代软件技术都是关于通过效率优化成本和构建可靠的产品。 因此，还有另一条路。 这就是格林团队采取的道路。

The threat of spiraling development costs alone should be enough reason to motivate software organizations to take action to eliminate tech debt. If that’s not enough, let’s look at the effect of the poor code quality that goes hand-in-hand with tech debt.

仅开发成本不断上升的威胁就应该足以激励软件组织采取行动消除技术债务。 如果这还不够的话，让我们看看与技术债务紧密相关的不良代码质量的影响。

代码质量低 (Low Code Quality)

Accumulated tech debt often causes constant time-pressure on development teams. Since tech-debt-ridden codebases take so long to work with, development usually proceeds at a snail’s pace. When this is the case, the last thing that developers are willing to do is to take on massive clean-up efforts. They just get their change in, breathe a sigh of relief when it gets approved and doesn’t result in a regression, and move onto their next task.

累积的技术债务通常会对开发团队造成持续的时间压力。 由于充满技术债务的代码库需要花费很长时间才能使用，因此开发通常以蜗牛般的速度进行。 在这种情况下，开发人员愿意做的最后一件事就是进行大量清理工作。 他们只是得到他们的改变，得到批准后松一口气，并且不会导致回归，然后继续下一步工作。

Over time, this results in poorer and poorer quality where mistakes are easy to make, and forward progress is harder to come by. Things break more often, and eventually, this destroys confidence in the product for customers, leadership, and the team itself. Perhaps the team will be able to keep their work afloat for a long time. Eventually, attrition, technological advances, unpredictable occurrences such as new critical vulnerabilities, vendors going out of business, or shifts in the market (like moving to the cloud or leveraging AI) will render their work obsolete. Teams in stasis because of tech debt will not be able to pivot because it’s too expensive and difficult to change their code. This outcome is always the end-game of poor code quality.

随着时间的流逝，这会导致质量越来越差，容易出错，并且很难取得进步。 事情更容易破裂，最终破坏了客户，领导者和团队本身对产品的信心。 也许团队将能够使他们的工作保持很长一段时间。 最终，人员流失，技术进步，不可预测的事件(例如新的严重漏洞，供应商倒闭)或市场变化(例如迁移到云或利用AI)将使他们的工作过时。 由于技术债务而处于停滞状态的团队将无法进行调整，因为这太昂贵且难以更改其代码。 结果总是代码质量差的最终结果。

As if the brutal effects of code quality and costs run rampant are not enough, there are even more negative impacts to come.

仿佛代码质量和成本高涨所带来的残酷影响还不够，未来还会有更多负面影响。

过度的认知负荷 (Excessive Cognitive Load)

Developers have a demanding job. To execute their work as developers, they must attain proficiency with the languages and frameworks, learn their development ecosystem. To make changes to the product, they must gain domain expertise in the product, refine their understanding of requested functionality so they can correctly produce it, communicate with teammates, and solve their day-to-day coding problems. So there’s quite a bit to hold in their head to work with any given codebase successfully. Not to mention the plethora of standards, best practices, and patterns they need to apply to achieve a decent level of quality.

开发人员的工作要求很高。 要以开发人员的身份执行工作，他们必须精通各种语言和框架，学习其开发生态系统。 要对产品进行更改，他们必须获得产品领域的专业知识，加深对所请求功能的理解，以便他们能够正确地生产产品，与队友进行交流并解决他们的日常编码问题。 因此，要想成功地与任何给定的代码库一起工作，他们需要投入很多精力。 更不用说为达到体面的质量水平而需要应用的过多标准，最佳实践和模式。

Developers need to juggle many considerations to manage what is referred to as cognitive load effectively:

开发人员需要综合考虑许多因素，以有效地管理所谓的认知负载：

In cognitive psychology, cognitive load refers to the used amount of working memory resources.- Wikipedia

在认知心理学中， 认知负荷是指工作记忆资源的使用量。-维基百科

Developers burdened with technical debt suffer cognitive load increases, which introduces drag on their ability to deliver. They have to consider even more things — things that are usually a poor use of their time.

承担技术债务的开发人员承受的认知负荷增加，这会拖累他们的交付能力。 他们不得不考虑更多的事情，这些事情通常是浪费时间的事情。

For example, if code is unnecessarily complicated, then the developer has to spend additional time to read and understand it to commit a simple change. This extra effort increases the chances that they’ll skip improving the code themselves, which would have made the next developer’s work more efficient, and so on and so on.

例如，如果代码不必要地复杂，那么开发人员必须花费更多的时间来阅读和理解它，以进行简单的更改。 这种额外的努力增加了他们跳过自己改进代码的机会，这将使下一个开发人员的工作更加高效，依此类推。

The point here is that technical debt incurs a cognitive load penalty, and it makes developers’ experience with code unpleasant, stressful, and error-prone.

这里的要点是，技术债务会导致认知负担的损失，并使开发人员在使用代码时的体验令人不愉快，压力大且容易出错。

All of the points above indicate one major failure. We’ll discuss that now.

以上所有要点均表明存在一项重大故障。 我们现在讨论。

无法识别和解决基本问题 (Failure to Identify and Address Underlying Problems)

The failure to address problems is what leads to technical debt. We’ll look at the most obvious reasons why this occurs now.

无法解决问题是导致技术债务的原因。 我们将看一下为什么现在发生这种情况的最明显的原因。

The most egregious and easily avoidable problem leading to this negative impact is feature-addiction. Feature addiction refers to the mindset where work on new features is always prioritized over quality or maintenance, and can even lead to management actively preventing developers from making much-needed improvements to the software or workflow.

导致这种负面影响的最极端，最容易避免的问题是特征成瘾 。 功能成瘾指的是一种思维定势，在这种思维定势下，始终优先于质量或维护工作来处理新功能，甚至可能导致管理人员积极地阻止开发人员对软件或工作流程进行急需的改进。

The inability to manage scope effectively, the overriding desire to please someone, or to tick off boxes in a checklist somewhere can all lead to this imbalanced approach. In organizations where product ownership, technical leadership, management, and development are in-sync, it’s always possible to come to some kind of prioritization compromise. In organizations mired in old ways of thinking where sales are the overriding concern, technical concerns like tech debt usually get pushed down the priority list.

无法有效地管理范围，无法取悦某人或在某处的清单中打勾的愿望，都可能导致这种不平衡的方法。 在产品所有权，技术领导力，管理和开发是同步的组织中， 总是有可能进行某种优先级折衷。 在沉迷于旧思维方式的组织中，销售是头等大事，而诸如技术债务之类的技术问题通常会被排在优先事项的首位。

If this is always the way teams work, the result is devastating: tech debt gets addressed very late or never. As it begins to pile it, it mutates and grows in unexpected ways, causing even more drag on the team, and thereby costing the organization many times more the amount of effort in the long-run. The irony is that the desire to do the right thing for the organization can doom the product.

如果这始终是团队工作的方式，那么结果将是毁灭性的：很久没有解决技术债务，甚至永远也不会解决。 当它开始堆积时，它会以意想不到的方式变异和增长，从而给团队造成更大的阻力，从长远来看，这使组织付出了很多倍的精力。 具有讽刺意味的是，为组织做正确的事情的愿望会毁灭产品。

Until now, we’ve only considered the aspects of tech debt that impact productivity and business aspects. There is also a human cost that needs reckoning, which brings us to our last section on the harmful effects of tech debt.

到目前为止，我们仅考虑了影响生产力和业务方面的技术债务方面。 还有一个人力成本需要计算，这使我们进入了关于技术债务的有害影响的最后一部分。

贫血工程文化 (An Anemic Engineering Culture)

Software organizations that allow technical debt to take root also resign themselves to a bleak future. Stress, lack of learning, over time, and a lack of engagement are all signs that the engineering culture is subpar. Again, tech debt is at the heart of it.

允许技术债务扎根的软件组织也辞职，走向黯淡的未来。 压力，缺乏学习，随着时间的流逝以及缺乏参与度都表明工程文化不佳。 同样，技术债务是其核心。

Tech-debt-ridden codebases are horrible to work within. Doing so saps developers’ will to work with the code and increases the chances that they will push to rewrite it just to escape the pain. A rewrite will usually show initial success because everything is new. This early success is a temporary situation because tech debt hasn’t had time to take root yet. However, since the engineering culture is still the same, tech debt inevitably accumulates again, and the grumbling about another rewrite ensues. This vicious cycle is part of the sort of fatalistic acceptance that tech debt is unavoidable and is just a fact of doing business.

负债累累的技术代码库无法正常工作。 这样做会降低开发人员使用代码的意愿，并增加了他们为避免痛苦而试图重写代码的机会。 重写通常会显示出最初的成功，因为一切都是新的。 早期的成功只是暂时的情况，因为技术债务还没有时间扎根。 但是，由于工程文化仍然相同，技术债务不可避免地会再次积累，随之而来的是关于另一项重写的抱怨。 这种恶性循环是那种宿命论的一部分，这种宿命论认为技术债务是不可避免的，而这仅仅是经商的事实。

There are also a few more distasteful reasons why tech debt can make its way into your codebase. Incompetence or indifference can be the cause. Sometimes developers just don’t care. The reasons why this might be the case aren’t important here. The disengagement of developers is a sign of a toxic culture, and leadership should investigate why this is the case. The likely culprit is the culture that they have created through the prioritization of specific values or types of work.

还有其他一些令人反感的原因，为什么技术债务会进入您的代码库。 无能或冷漠可能是原因。 有时开发人员根本不在乎。 在这种情况下，可能并非如此的原因并不重要。 开发人员的脱离是有毒文化的标志，领导层应该调查为什么会这样。 可能的罪魁祸首是他们通过对特定价值或工作类型进行优先排序而创建的文化。

While all of this is going on, developers aren’t doing one of the most important things for people that work with technology: learning. Since they are constantly being pressured and have their attention split, they often lack the motivation to put in extra time to learn. Their organizations may mandate training, but it’s rarely aimed at making developers more proficient at recognizing and eliminating tech debt. And so the vicious cycle continues.

尽管所有这些都在进行，但是开发人员并没有为从事技术工作的人员做最重要的事情之一：学习。 由于他们不断受到压力并分散注意力，因此他们通常缺乏动力来投入额外的时间来学习。 他们的组织可能会要求进行培训，但这很少旨在使开发人员更加精通识别和消除技术债务。 因此，恶性循环仍在继续。

补救措施 (Remedies)

It should be clear by now that we should avoid tech debt. It’s the invisible enemy that every software organization struggles with, whether they know its name or not.

现在应该很清楚，我们应该避免技术债务。 无论每个软件组织是否知道其名称，它都是与之作战的无形的敌人。

Fortunately, there are many ways to combat it. After all, this is a problem that some brilliant people have been thinking about for decades. They involve behavioural and process changes, some on the part of developers, some on the rest of the organization. People simply need to adopt them. Hopefully, the following ideas can give people a place to start.

幸运的是，有很多方法可以解决它。 毕竟，这是一些杰出人士数十年来一直在思考的问题。 它们涉及行为和流程更改，某些更改涉及开发人员，某些更改涉及组织的其余部分。 人们只需要采用它们。 希望以下想法可以给人们一个起点。

采纳质量观念 (Adopt a Quality Mindset)

Software organizations that only prioritize features will never develop the ability to build quality into the product. This mindset leads to the accumulation of technical debt and all of the undesirable outcomes we have already discussed. That said, delivery is essential, and so there has to be a balance between it and quality.

仅优先考虑功能的软件组织将永远不会发展将质量内置到产品中的能力。 这种心态导致技术债务的积累以及我们已经讨论过的所有不良后果。 也就是说，交付至关重要，因此必须在交付与质量之间取得平衡。

We can discuss methodologies like Agile, DevOps, and Lean, which revolve around the idea of shipping quality at speed. Each is a deep topic, and the details of each are far out of scope for our current discussion.

我们可以讨论诸如敏捷，DevOps和精益之类的方法，这些方法围绕着快速交付质量的想法展开。 每个都是很深的话题，每个细节都超出了我们当前讨论的范围。

At the heart of those movements, however, is the insight we’re after: to adopt a quality mindset, software organizations have to accept a slower pace of delivery. You have to slow down to speed up.

但是，这些运动的核心是我们追求的洞察力：要采用高质量的思维方式，软件组织必须接受较慢的交付速度。 您必须减速以加快速度。

At the same time, you also don’t want to swing too far the other way, where there’s so much red tape meant to enforce quality that nobody can ship anything. If you’re in an organization that feels like that, then you should take a hard look at what can be automated, and for other ways to optimize the workflow because without delivering value, you’re also missing the point.

同时，您也不想以其他方式摇摆得太远，因为繁琐的繁文to节旨在提高质量，以至于没人能运送任何东西。 如果您在这样的组织中，那么您应该仔细看一下可以自动化的内容，以及其他优化工作流程的方法，因为如果没有交付价值，那您就失去了重点。

教授识别“良好代码”的能力 (Teach the Ability to Recognize “Good Code”)

Developers often get caught up in only getting their code to work. For many, this is as far as their daily work can take them. Without proper technical mentorship, it’s hard to expect developers to know which characteristics maintainable code exhibit.

开发人员通常只能使他们的代码正常工作。 对于许多人来说，这是他们日常工作所能承受的。 没有适当的技术指导，很难期望开发人员知道可维护代码所表现出的特征。

We shouldn’t assume that every developer should be born with the knowledge of which pattern or abstraction to apply in any given situation. Instead, we should make sure to provide examples of code with the characteristics we desire. Even more critical is to provide coaching to help developers get there themselves. Coaching can come from senior developers, enablement coaches, consultants, or even peer study groups. The trick is to provide developers with the resources necessary to take advantage of coaching advice.

我们不应该假定每个开发人员都应该天生就知道在任何给定情况下要应用哪种模式或抽象。 相反，我们应确保提供具有所需特征的代码示例。 更为关键的是提供指导以帮助开发人员自己实现目标。 培训可以来自高级开发人员，功能培训师，顾问，甚至是同行学习小组。 诀窍是为开发人员提供利用指导意见所必需的资源。

The “good code” bit is up for debate. For most situations, though, “good code” is code that does what it’s supposed to, is fault-tolerant, and is as easy as possible to maintain. The last is up for interpretation, but testing automation and quality checks are usually a good start.

“好代码”位尚待争论。 但是，在大多数情况下，“好的代码”是可以实现预期功能，具有容错能力并且易于维护的代码。 最后需要解释，但是测试自动化和质量检查通常是一个好的开始。

使技术债务易于发现且无法忽略 (Make Tech Debt Easy to Spot and Impossible to Ignore)

Developers rarely willingly introduce technical debt. Sometimes, they only see the debt after building something. Refactoring can then be applied to fix it. Other times, a simple lack of knowledge leads to developers not recognizing that their code is rife with technical debt. Pairing and peer code inspection is a way to catch mistakes. The caveat is that competent pairing requires that the pair or the reviewer can recognize technical debt themselves. The best remedy is by establishing a software engineering culture that improves the overall practice of the team. This approach is difficult and time-consuming, and yet developers are often happier because they’re learning, finding better ways to do their jobs, and finding ways to avoid the stress inherent to tech-debt-ridden systems. They can see a way out.

开发人员很少愿意引入技术债务。 有时，他们只会在建造东西后才看到债务。 然后可以应用重构来修复它。 在其他时候，仅仅缺乏知识会导致开发人员无法意识到他们的代码充斥着技术债务。 配对和对等代码检查是一种捕获错误的方法。 需要注意的是，有能力的配对要求配对或审阅者自己能够识别技术债务。 最好的补救方法是建立一种软件工程文化，以改善团队的整体实践。 这种方法既困难又耗时，但是开发人员通常会更快乐，因为他们正在学习，找到更好的方法来完成工作并找到避免技术债务缠身的系统所固有的压力的方法。 他们可以看到一条出路。

The other way to make tech debt easy to spot is through static code analysis. Measures such as cyclomatic complexity, which calculates how complicated it is for a computer to read the code, or cognitive complexity, which measures how easy it is for humans to read the code, are straightforward to put in place. Most unit test tools come with this built-in.

使技术债务易于发现的另一种方法是通过静态代码分析。 诸如圈复杂度(用于计算计算机读取代码的复杂程度)或认知复杂度(用于衡量人类读取代码的难易程度)等度量方法可以直接实施。 大多数单元测试工具都带有此内置工具。

In addition to detection, static code analysis tools can help you block issues from making their way into the system. Aside from the educational aspect of learning to recognize and address quality issues, creating a system that prevents the most obvious ones from even entering the codebase is a powerful tool. When you do this, you force developers to address the problem, and you can stop the influx of certain kinds of quality issues.

除了检测之外，静态代码分析工具还可以帮助您阻止问题进入系统。 除了学习识别和解决质量问题的教育方面之外，创建一个可以防止最明显的问题甚至进入代码库的系统也是一个强大的工具。 当执行此操作时，您将迫使开发人员解决问题，并且可以停止涌入某些质量问题。

You can get a lot of mileage out of blocking technical debt, but you have to remember to support it with coaching. The goal should be to reinforce the culture of quality, not to create arbitrary red tape. If you create a system that blocks value creation, then developers will find ways around it. You’ll have missed a golden opportunity to create a workflow that supports a virtuous, constructive culture and instead just have created barriers and toil.

通过阻止技术债务，您可以取得很多进展，但是您必须记住要通过教练来支持它。 目标应该是加强质量文化，而不是制造任意的繁文tape节。 如果您创建一个阻止价值创造的系统，那么开发人员将找到解决方法。 您将错失千载难逢的机会来创建一个支持道德，建设性文化的工作流程，而只是创建了障碍和辛劳。

玄智玄武 (Genchi Genbutsu)

Managers and technical leaders often make the mistake of relying solely on the opinions of people too close to the code for objective advice. That isn’t to say that developers aren’t trustworthy — it’s more that they’re not subjective and at times may find it challenging to step back from the code.

经理和技术领导者经常犯这样的错误，即仅依靠过于接近法规的人们的意见来寻求客观建议。 这并不是说开发人员不值得信赖-而是他们不是主观的，有时可能会发现退出代码很有挑战性。

One way to address this problem is by taking a page out of the Lean playbook and follow Genchi Genbutsu to “go and see” for ourselves. Read the code. Ask one of the devs familiar with the system for a walk-through. Read the docs. Run the app yourself. Shoulder surf with a developer while they deal with problems.

解决此问题的一种方法是从精益手册中摘下一页 ，然后跟随Genchi Genbutsu自己“去看看”。 阅读代码。 要求熟悉该系统的一名开发人员进行演练。 阅读文档。 自己运行应用程序。 在开发人员处理问题时，应与开发人员一起冲浪。

It’s surprising how easily a fresh pair of eyes can spot technical debt when the person closest to the code has ceased noticing it after seeing it dozens of times.

令人惊讶的是，当最接近该守则的人在看了几十遍之后不再注意到它时，新鲜的双眼多么容易发现技术债务。

That isn’t to say that Genchi Genbutsu directly intended for this, but the underlying concept of Gemba where you go to the actual place of value creation can be enlightening. I employ this all the time when something catches my ear in standup, when I spot something in code review, or when I notice something when testing the product myself. Sometimes I’m able to make a suggestion or teach a concept that helps the situation, something it’s nothing, but I never come away not having learned something. Much of the time, I’m able to spot and address technical debt or habits that will lead to technical debt.

这并不是说Genchi Genbutsu直接打算这样做，但是Gemba的基本概念很有启发性，您可以在其中找到真正的价值创造场所。 当有人在直立状态中引起别人的注意时，在代码审查中发现某些内容时，或者当我自己测试产品时发现某些内容时，我都会一直使用这种方法。 有时，我能够提出建议或教导可以帮助解决这种情况的概念，这什么都不是，但是我从来没有学到一些东西就不会离开。 在很多时候，我能够发现并解决技术债务或导致技术债务的习惯。

对等代码审查和配对 (Peer Code Reviews and Pairing)

When it comes to writing code in an environment where you want to avoid technical debt, the key is to understand that the goal isn’t to get candidate code approved as quickly as possible. The goal is to prevent code quality issues from coming back to bite the team later and lead to rework. Nobody is perfect, so having a second set of eyes checking quality before shipping the code is necessary. Peer code inspection needs to be active (no “buddy merges”), and it needs to include running the application. Otherwise, the reviewer is not truly performing quality inspection, and may even be rubber-stamping things.

在要避免技术负担的环境中编写代码时，关键是要了解目标不是尽快获得批准的候选代码。 目的是防止代码质量问题再次引起团队的反感并导致返工。 没有人是完美的，因此有必要在交付代码之前再检查一下质量。 对等代码检查需要处于活动状态(没有“伙伴合并”)，并且需要包括运行应用程序。 否则，审阅者将无法真正执行质量检查，甚至可能是在加盖橡皮戳。

For an even better outcome, move code inspection earlier in the process and have use pair programming. Pairing acts as live peer inspections and helps catch problems as developers type them in. It’s the ultimate Shift Left on quality.

为了获得更好的结果，请在过程的较早阶段进行代码检查，并使用成对编程。 配对充当实时同行检查，并在开发人员输入问题时帮助发现问题。这是最终的左移质量。

不断减少技术债务 (Constant, Incremental Reduction of Tech Debt)

The tried and true method for eradicating technical debt is by incrementally reducing it. Setting aside at least 20% of development time for constant tech debt reduction will help teams maintain high velocity. The best way for this to work is to treat this almost like any other work, with the difference being that the team members are the ones identifying work that they believe will improve the workflow or the overall quality of the product. This work can be anything, from writing better documentation, cleaning up old sub-par code, upgrading dependencies, backfilling missing tests. They are the ones closest to the product and know the rickety and less-polished parts — that’s because they have to live with them every day.

消除技术债务的可靠方法是通过逐步减少债务。 留出至少20％的开发时间以减少技术债务，这将有助于团队保持较高的速度。 这项工作的最佳方法是几乎将其视为任何其他工作，不同之处在于，团队成员是确定他们认为可以改善工作流程或产品整体质量的工作。 这项工作可以是任何事情，从编写更好的文档，清理旧的低于标准的代码，升级依赖项，回填缺失的测试。 他们是最接近产品的人，并且知道摇摇欲坠和抛光程度较低的零件-这是因为他们每天都必须与他们生活在一起。

This step may seem drastic to people that want a constant influx of features. However, anyone that’s been around software development for more than a few years knows the inevitable conclusion of always ignoring tech debt. It’s hard to envision sometimes, but if regular, incremental tech debt reduction allows teams to maintain their velocity over time, then the long-term windfall makes it all worth it.

对于需要不断涌入功能的人们来说，这一步骤似乎太过激烈了。 但是，从事软件开发已经超过几年的任何人都知道总是忽略技术债务的必然结论。 有时很难想象，但是如果定期减少技术债务的增加可以使团队随着时间的推移保持其速度，那么长期的意外收获就值得所有。

结论 (Conclusion)

I spent the earlier parts of my career on teams that wrote code exactly as Team Blue does. Those teams were still able to deliver tons of value in the form of working production code. However, on teams like Team Green, the work was much less stressful, and the sorts of problems we dealt with were the sorts of detailed work you would expect when your software system has quality built-in. My Team Blue experiences always relied on heroic efforts, and the doubt and stress of finally flipping that switch and turning the system on in production were never pleasant.

我将职业生涯的早期阶段花在完全与Blue Team一样的代码编写团队上。 这些团队仍然能够以有效的生产代码形式交付大量价值。 但是，在像Team Green这样的团队中，工作压力要小得多，并且当软件系统具有内置质量时，我们要处理的问题就是您期望的各种详细工作。 我的Blue Team经验始终依赖于英雄般的努力，而最终翻转该开关并在生产中打开系统的怀疑和压力从来都不是一件令人愉快的事情。

The problem with technical debt, and the worst part of its insidiousness, is that it’s continually changing, and so you must adjust. You must be vigilant, and you must be willing to put the work in to address it.

技术债务及其隐患的最坏方面是问题，它在不断变化，因此您必须进行调整。 您必须保持警惕，并且您必须乐于解决该问题。

If you do, the reward is being part of a productive, proactive, and healthy technical organization. If you don’t, then you are resigning yourself to being part of an organization where everything is harder than it needs to be and where you are waiting for a more progressive competitor to come along and take over your share of the marketplace.

如果您这样做，那么奖励将是一个富有成效，积极主动且健康的技术组织的一部分。 如果您不这样做，那么您将辞职成为一个组织的一部分，那里的一切都比它所需要的要困难得多，并且您正在等待一个更具进步性的竞争对手来占领市场份额。

The great news is that you can keep tech debt to a manageable level. The time you’ll save by not having to deal with the toil can be reinvested in more valuable and engaging pursuits. You’ll also find that the team is happier and that work is more enjoyable.

好消息是您可以将技术债务保持在可管理的水平。 您无需花力气就能节省的时间可以重新投资于更有价值和更具吸引力的追求。 您还会发现团队更快乐，工作更愉快。

That said, you will never eliminate it because of the fundamental nature of things like dependencies and security vulnerabilities. What you remove is the self-inflicted wounds and the items that computers can detect. Teams that have already adopted these behaviours know this and are doing it.

就是说，由于依赖关系和安全漏洞之类的基本性质，您永远都不会消除它。 您去除的是自伤伤口以及计算机可以检测到的物品。 已经采取这些行为的团队知道这一点并且正在这样做。

For other teams, this is my advice: get started now and be prepared for a long ride. The path is hard, but it’s satisfying, and it’ll make you better at your jobs, further your career, and will serve the organization better. You will improve your command of the craft of software engineering and use those ideas to elevate your peers and your organization.

对于其他团队，这是我的建议： 现在就开始，并做好长途旅行的准备。 道路艰难，但令人满意，它将使您的工作更好，事业进一步发展，并将为组织提供更好的服务。 您将改善对软件工程技术的掌握，并使用这些想法来提升同行和组织的水平。

进一步阅读 (Further Reading)

左移 (Shift Left)

• Wikipedia: Shift-left testing

  维基百科： 左移测试

• Smartbear Blog: What it Means to “Shift Left”

  Smartbear博客： “左移”是什么意思

• DZone: The Shift Left Principles and DevOps

  DZone： 左移原则和DevOps

认知负荷 (Cognitive Load)

The following article is an excellent description of Cognitive Load from an engineering manager’s perspective:

从工程经理的角度来看，以下文章是对认知负载的出色描述：

• José Fernandes: Cognitive Load 101

  何塞·费尔南德斯(JoséFernandes)： 认知负荷101

These are some terrific descriptions of cognitive load from a developer’s perspective:

这些是从开发人员的角度对认知负荷的一些很棒的描述：

• DabApps: Programming and Cognitive Load

  DabApps： 编程和认知负荷

• Stitcher.io: A programmer’s cognitive load

  Stitcher.io： 程序员的认知负担

• Alberto Fernández-Capel: Cognitive load in programming: why the brain is the bottleneck

  AlbertoFernández-Capel： 编程中的认知负担：为什么大脑是瓶颈

免责声明 (Disclaimer)

I’m an employee of IBM. The views expressed in this blog are mine and don’t necessarily reflect the positions, strategies, or opinions of the company.

我是IBM的员工。 本博客中表达的观点是我的观点，不一定反映公司的立场，策略或观点。

翻译自: https://medium.com/swlh/managing-technical-debt-b4f30cbccbe0

技术债务管理