克服拖延症的三个技巧
在上一篇文章中 ，我们研究了导致技术债务不可避免的宏观趋势。 但是，即使技术债务已成事实，也不必一定要技术破产。 因此，这一次，让我们看看可以采用哪些方法来避免技术破产，并为每个人节省大量的悲伤，时间和金钱。
技术债务不一定会导致技术破产。 但是，如果我们不抗拒那些将高增长软件公司推向高增长趋势的微观趋势，那么这就是我们最终的结果。
公司通常没有采取正确的措施来避免技术破产。 他们只是接受它会在一天之内发生，而一旦发生，他们将在一个庞大的项目中重构整个代码库来处理它。 但是，当然，这些项目很少能按计划进行。
即使对于使技术债务不可避免的宏观趋势我们几乎无能为力，正如虚构的苏格兰太空船工程师可能已经说过的那样，我们无法改变物理定律，但仍有许多方法可以避免可怕的技术破产。
为了将有效的解决方案与无效的解决方案区分开，我们需要深入了解起作用的力量及其在社会学，犯罪学和博弈论中的根源。
微观趋势将我们推向技术破产
破窗理论
犯罪，反社会行为和内乱的明显迹象创造了一种城市环境，助长了进一步的犯罪和混乱，包括严重犯罪。
就我们的目的而言，我们可以归结为以下几点 ： 技术债务孕育出更多的技术债务 。 容忍即使是最小的犯罪也将导致它成为可接受的行为，并且会像犯罪波一样传播到您的代码库的其余部分。
正如我们在技术债务不可避免的简单原因中了解到的那样，在任何增长的系统中，软件熵都将永远增加。 因此，技术债务也是如此。 这使得修复代码库中所有损坏的窗口并防止技术债务泛滥变得极为困难，甚至是不可能的，也是不明智的。
“公地的悲剧”与“囚徒困境”
公地的悲剧是一个经济问题，其中每个人都有动机以消耗其他每个人为代价来消耗资源，而没有办法排除任何人进行消耗。 这导致过度消费，投资不足，最终导致资源枯竭。
通常，软件工程团队会因尽快完成分配的任务而获得奖励。 他们消耗的资源是时间 。 他们被激励尽可能快地前进，因此经常走捷径，从而造成技术债务，这随后成为每个人的问题。
但是，由于每个人都被激励保持与时俱进的新功能，因此工程团队不会有动力来偿还技术债务。 这是囚徒的困境。
囚犯的困境是决策分析中的一个悖论，在该悖论中，两个人为了自己的利益行事并没有产生最佳结果。
这两个概念都是损害公共利益的个人利益。 结合起来，他们解释了为什么技术债务通常无法解决，直到它导致整个软件开发机器停滞不前。 彼得·梅雷尔 （ Peter Merel ）在他的文章“ PMO的悲剧 ”中对这个问题进行了有趣的模拟。
一旦他们在技术上破产，公司别无选择，只能偿还技术债务，而且由于在交付新功能时没有连续偿还技术债务，因此他们必须在一个大型项目中全部完成。 。 。 或丢掉代码并从头开始。
这种方法的问题在于，项目越复杂，规模越大，尤其是在技术债务缠身的情况下，准确估算任务就越困难。 大卫·贝利（David Bailey ）撰写了一篇很棒的文章，可以帮助您解决这一问题： 重建技术时不要做什么 。
为什么该问题的典型解决方案不起作用
技术债务并非出于恶意。 无能并不像您预期的那样重要。 我们不能只是拧紧我们的工程团队的螺丝钉，并期待技术债务会消失。 您可能知道有人尝试过这种方法但失败了。 实际上，没有解决技术债务问题的典型解决方案。
这就是为什么。
技术债务不仅仅是解决工程问题：康威定律
设计系统受约束的组织必须制作设计，这些设计是这些组织的通信结构的副本。
我们希望软件工程师能够正确管理技术债务。 但是，他们设计的系统受到公司组织结构的约束-他们对此几乎没有控制权。
公司结构和沟通方式的任何变化都必须来自最高层，如果幸运的话，最高层的人们会理解并认真对待技术债务。 但是，如果他们像大多数人一样，却不了解，那我们就麻烦了。
除此之外，公司经常遭受组织债务的困扰， 史蒂夫·布兰克（Steve Blank）认为这比技术债务还要致命 ，而且很清楚为什么工程师要为失败做好准备。
技术债务并不总是一件坏事：Knuth的优化原则
[...]过早的优化是编程中所有邪恶（或至少是大多数邪恶）的根源。
唐纳德·克努斯（Donald Knuth） 的计算机编程艺术
Knuth的原则最初与代码运行的时间有关，但它也是精益启动和敏捷方法的基础，精益启动和敏捷方法被高增长软件公司的众多现代工程团队所采用，而且也是如此。
它解释了为什么选择技术债务来避免过早优化的恐惧通常是正确的选择，您可以在我们的文章中深入探讨如何定义有效的技术债务预算 ，这是一个主题。 但是，技术债务需要谨慎管理，尤其是一旦公司达到产品市场要求。
及时的优化非常棒，但是当每一个诱因促使您Swift推出新功能时，这也非常困难（请参阅上一篇文章 ）。
打破科技债务的恶性循环
当您应该考虑激励的力量时，再也不要考虑其他事情。
查理·芒格
我们讨论过的法律，规则，原则和理论都有一个共同点：它们描述了一组现有的激励措施及其后果。 但是，解决技术债务恶性循环的方法是确定一套非常具体的激励措施，以扭转局势对我们有利。
使用帕累托原理对技术债务进行优先排序
您的代码库中大约20％的技术债务可能会造成大约80％的问题（例如，错误，中断等）。 正如我们在有关如何定义技术债务预算的文章中所揭示的那样，Microsoft Research显示，尽管活动文件仅占整个系统的2–8％，但它们却占所有缺陷的60–90％。
换句话说，您不需要立即解决所有技术债务。
仔细 听 Linus Law的话 （他再次正确）
只要有足够的眼球，所有的bug都是浅的。
莱纳斯·托瓦尔兹
将拉取请求的大小保持在较小的范围内，这样它们就易于检查，并确保有足够多的适当人员检查该代码（提示：可能是拥有此代码的人 ）。 这样一来，您就可以在大多数bug投入生产之前就将它们捕获。
庆祝科技债务英雄
这很简单。 在星期五的演示中，不仅要赞扬发布新功能的工程师。 为那些无名英雄的技术债务加油打气：重构此令人讨厌的功能，修复该错误，查看这些请求的人员，使您摆脱了似乎不可避免的技术破产的命运。 这是您迈向拥有所有权的工程文化和建立健全的代码库的过程中的一站 。
谈论整个公司的技术债务
公司领导层需要了解技术债务如何影响整个公司及其在其中扮演的角色。 只有这样，他们才会认真对待它。 作为了解技术债务的软件工程师，我们有责任在整个业务范围内进行沟通。
我们将很快在一篇文章中对此进行讨论，但与此同时，请看一下马丁·福勒（Martin Fowler）的出色著作：“ 高质量的软件值得吗？ '。
习惯的力量
请注意，以上建议均不要求额外的工程工作。 实际上，它将技术债务问题分解为更小的习惯，如果正确遵循的话，它将使每个人的工作变得更轻松，更快，更有趣。
冠军不会做非凡的事情。 他们做普通的事情，但是他们却没有思考，对其他团队来说React太快了。 他们遵循所学的习惯。
查尔斯·杜希格（Charles Duhigg）， 习惯的力量：我们为什么要在生活和商业中做我们要做的事情
随时间改变小习惯，您的工程师将更快地发布更好的代码，您将拥有更快乐的客户，他们将推荐更多的潜在客户。 。 。 然后您就会击败竞争对手。
为了帮助您养成良好的习惯，我们构建了一个免费的VSCode扩展，以持续跟踪和偿还技术债务。
翻译自: https://hackernoon.com/4-habits-every-engineering-team-needs-to-beat-tech-debt-wbr3zl1
克服拖延症的三个技巧
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
