转载

KentBeck：“改善架构”比“还清技术债务”可以带来更好的感觉，决定和结果。

比尔盖茨说过：人们不会为修复bug付费，只为新功能付钱。技术债务作为Bug产生的根源，技术债务只是针对开发人员而言，如何能做到向最终用户收费？创造新的商业价值？KentBeck提出投资改善体系结构或架构，这样比单纯去修复bug、重构等还请技术债务的方式会更好吗？

众说纷纭：

商业价值来自：增加收入，保护收入或降低成本。我倾向于找到最好的方法来出售设计的改进。这样可以更快地添加新功能。[降低成本]这将防止我们在高峰期下降[保护收入]

“技术债务”一词太笼统，无法采取行动。这是一个很好的概念，但是在讨论时间的实际投资时不能使用。

我最近将“软件重构”重构为“软件升级”。各方面态度的变化是显而易见的。

不赞成，技术债务本身是一个错误的称呼。该名称使非技术决策者的优先级降低。这是错误的称呼，因为干净，经过测试覆盖的代码对企业具有非常明显的成本和时间收益。

据我所知，“技术债务”是指为发布功能而暂时接受的次优架构。解决以前的技术问题的问题是，我们目前不知道下一个功能需要什么样的架构。

重构无需计划，可以随机完成

我认为，“偿还技术债务”的用法如此宽松，以至于在许多情况下它都是模棱两可的。谈论结构和投资确实需要更精确的跟进对话。

长期以来，我一直是这种方法的支持者。它还有助于确定投资地点的优先级，而不是争论最大的债务是什么。使每个人更容易与产品积压/路线图保持一致。

我一直不喜欢“技术债务”一词。解决实际问题的方法是：设计和体系结构选择不佳通常是由于缺乏技能和经验造成的。有时，时间限制是一个因素，但很少会影响经验丰富的工程师的素质

在这个措词上不同：关于“还清技术债务”的思考使我感到难过。“投资改善结构”使我感到高兴。我喜欢正能量。

我认为技术债务带有负面含义，这种表述是积极/有动机的。

这是一个区别，但有一个重要区别：“债务”是指为权宜之计而进行的短期入侵；工程上自觉做错了。

在大型工程组织中，我发现“还清技术债务”实际上并不是一个特别有用的目标-因为团队可以以此为借口从事几乎所有工作！如果一个团队花了三个月的时间将某些代码重写为他们喜欢的另一种样式，这是否是有用的债务偿还方法？我更倾向于有针对性的偿还债务。到目前为止，我所看到的最好的方法是专注于“摆脱重复的系统”。如果您有两个系统可以解决一个特定的问题，并且将其合并为一个，那么肯定可以得到改善。而且，向非技术利益相关者很容易解释为什么拥有一个系统比维护两个系统更好。（banq注：对于老板而言：重用高于解耦，因为重用可以似乎节约成本，降低人力）

我已经注意到，当“技术债务”出现时，业界的人们会视而不见。我很同情，因为以前不是那样。大型机上的COBOL将会持续数十年。如今，工具和语言非常分散。我最近尝试启动并运行一个受欢迎的node.js应用程序，但是npm只是不断轰炸废弃的软件包。该项目已有2年历史，并且已经“负债累累”。Java非常擅长于此。在进行拼图之前，我们有13年没有接触过的项目，但它们仍在最新版本上进行编译。当然，这是有利有弊。

总的来说，我不认为技术债务应该传达给商人。这是工程工作的内部部分，不会影响用户。如果愿意，您可以将其视为“封装”。对外界来说，这听起来也像是“我们正在抽出时间来解决我们一开始就不愿意做的事情”。那不是* 100％错误的...

技术债务应该传达给商人或用户，由于业务需求，几乎总是产生技术债务。需要让他们知道当时正在产生债务，因此他们知道需要尽快偿还。示例：投资者要求一家初创公司从现在起一周内为贸易展览会实施一项特定功能。如果正确完成，该功能将需要更改数据库架构，否则查询将非常缓慢。幸运的是，对于贸易展览会，要查询的数据量足够小，因此无关紧要。但是，一旦开始使用，问题最后还是出现了，需要使管理层意识到这里发生了技术债务。是的，将在最后期限之前完成，并且交付将顺利进行。但是最好在时间表上列出待完成事项。

商务人士对债务一无所知，因为企业靠债务经营很普遍。

有趣的一种技术债务是当您意识到对问题的建模错误，或者问题已更改并且需要更改模型时。一个简单的示例是一个权限系统，该系统假定帐户和用户登录名之间是一一对应的。然后，您发现代理机构在概念上是一个帐户，但具有多个登录名（每个客户才能只能看到他们自己的帐户）。糟糕，这破坏了模型。更改此要求需要数据库迁移，代码更改，UX更改等。从概念上来说，这是一个简单的更改，但意义广泛。

我只在工程团队中使用“技术债务”一词。为了与更广泛的受众交流，我使用：“改善产品，工程和运营卓越性”。想法是，更广泛的受众关注点是总体收益和成本，而不是我们是否有债务。这句话还使我能够进行流程更改，从而提高了Tech Debt之外的团队效率。

您不还清技术债务。充其量，您可以为其再融资。除非您要终止功能，产品或公司。

大多数时候，我听到程序员在谈论技术债务，他们真正的意思是概要分析和性能（因为随着时间的流逝，需求变更和代码大小增加）或代码“清理”，但是技术债务是完全不同的。顾名思义，这是债务，债务意味着不会持久。通常情况下，管理层只是按照计划表看到了问题，因此无需回头再“重做”。尽可能地偿还技术债务。这将最终得到回报，这只是您这样做时会感到多么痛苦的问题。

我认为，可能公司需要在管理文化上进行根本性的转变，然后才能更加认真地对待技术债务。我曾经设法对技术债务做任何事情的唯一方法是隐藏我正在做的事实-因为完全不可能获得任何程度的管理层支持甚至是许可。其实不必那样做，我应该得到更高级别的支持，可以与其他开发人员一起工作并拥有胜任的测试人员-在这种情况下工作最终使我不再希望为其他任何人编写软件。这是一种无能的疾病，并且渗透到软件开发行业的众多机构的管理结构中。

由于生活的现实，技术债务是程序员造成的必然弊端。 唯一的问题是，当您开始向他人撒谎时，您可能最终会自己相信。

原文 https://www.jdon.com/53356

正文到此结束