当高管需要功能时管理你的技术债务

Hayden Baillio
对。

‍

Hayden Baillio
让我们来看看。

‍

Hayden Baillio
我们正在直播，我们在这里等着大家。

‍

Kelvin Del Monte
各位，欢迎，欢迎。

‍

Hayden Baillio
是的，我很难见到大家。如果你在聊天室，请打个招呼。

‍

Hayden Baillio
打招呼、问好。

别朝我扔东西，好吗？

‍

Kelvin Del Monte
You

祝正在收看的各位周三快乐。驼峰日快乐

‍

Hayden Baillio
是的，是的。

‍

Hayden Baillio
好了好了，我们到了。

‍

Hayden Baillio
好吧，我想我们应该开始了。

‍

Kelvin Del Monte
好吗？好的

‍

Hayden Baillio
只是要确保你的前沿和中心。卡尔文对我说，你和我的朋友是中心，还是你们现在是朋友？

‍

Kelvin Del Monte
我们都是同样的前沿和中心。

‍

Hayden Baillio
同样的前沿和中心。喜欢。我喜欢这样，我们应该这样。好吧，完美。

好了，好了，好了，我们到了，各位。感谢大家参加我们这次精彩的网络研讨会，我们将讨论在执行人员需要新功能时如何管理技术债务。我就开门见山了。我们只有 30 分钟，所以我要介绍一下今天的演讲者。女士们、先生们，他可能同时拥有科技界最流畅的嗓音和解释技术债务的罕见能力。

而不会让高管哭泣。作为 HeroDevs 公司的解决方案架构师，他的职业生涯是将传统系统改造成尖端平台，并帮助人们解决技术债务问题，让债务消失。我开玩笑的。但他确实绝对了解生命末期软件的流沙，以及 HeroDevs 在软件生命周期管理中的作用。

今天，他将向你展示如何在代码库不会像上次家庭聚会上的折叠桌一样倒塌的情况下交付功能，对吗？请欢迎技术债务管理的 ASMR 声音。卡尔文-德尔蒙特（Calvin Del Monte）。感谢加入卡尔文，把它拿走，伙计。这都是你，你知道的。都是你

‍

Kelvin Del Monte
非常感谢。

‍

Kelvin Del Monte
非常感谢。谢谢谢谢你，海登。好的欢迎大家的到来。感谢大家的到来。对于那些稍后会收看的人，你知道，因为这次会议，因为这次网络研讨会正在录制，欢迎在这个美丽的星期三收看。让我们来谈谈技术债务。在开始之前，我想先自我介绍一下。我叫凯尔文-德尔蒙特（Kelvin Del Monte）。我是 Hero Devs 的解决方案工程师。我从 2008 年开始担任软件工程师。

在我的职业生涯中，我也有机会领导和管理过几个工程团队。我今天要讲的都是我的亲身经历，对吗？我曾在各种组织中工作过，大组织、小组织、初创公司都有。在这个过程中，我学到了很多关于技术债务的知识。我想和大家分享一下。首先，我认为我们应该从什么是技术债务开始？

你知道，这就是技术死亡的感觉，对吗？我知道这是很流行的说法 我觉得很好笑是啊

‍

Hayden Baillio
Kelvin，Kelvin，对不起。我想你还没有分享你的演示文稿。一切顺利。技术故障。这是我们系列的第一个。

‍

Kelvin Del Monte
对不起，对不起。谢谢Thank you for that.Yeah, let me actually.是的，没问题，没问题。现在你应该能看到了。

‍

Hayden Baillio
就这样。

‍

Kelvin Del Monte
完美。是的所以，是的，首先我们应该...我之前给你们看了一个你们看不到的备忘录，但这是一个超级流行的备忘录，它描述了技术债务的感觉。虽然感觉是这样，但...

并不总是这样，对吗？你的房子并不像现在这样破烂不堪，你的老板问你能不能加一扇新窗户。如果房子坏成这样，你怎么加窗户？但这确实是一种感觉。我们会在以后的幻灯片中再多讲一点。在讨论什么是技术债务之前，我们应该先讨论一下...

技术债务这个词是谁创造的，是谁提出来的，就是在座的这位先生沃德-坎宁安先生，他早在 1992 年就创造了技术债务这个词，当时我才三岁，他使用了这个比喻，当时他正在研究一种金融产品，尽管这种金融产品被称为 "Y 现金 "和 "技术债务"。

他用这个比喻向老板解释了他的团队在不断开发 Ycash 软件的过程中所经历的一切。随着开发的进展，他们对系统的理解，以及他们自己对正在构建的系统和构建方式的看法都在发生变化。

因此，他们开始以一种方式构建它。然后随着时间的推移，他们发现了新的范式、新的模式，认为它们更有用，更适合他们正在做的工作类型。因此，这几乎就像他们在时间的长河中不断前行，在他们编写代码或设置应用程序的那一刻，对他们来说最优的决策就是最优的决策，但随着时间的推移，他们发现新的模式和范例更适合他们的工作类型。

‍

Kelvin Del Monte
你知道，六个月后的未来，一年后的未来，他们作为人，作为工程师，已经进化了，软件也进化了，他们的合作方式也进化了。也许他们有了新的工具。这期间可能会发生很多事情。在这种情况下，他们发现自己正在寻找过去构建的代码。

他们的代码已经不再符合现在的构建标准。你看，有一小队人在开发软件。代码没有改变。他们变了。他们的观点变了。这就产生了技术债务这个词。他解释说，这是因为团队正在回溯并与他们过去编写的旧代码进行交互、

坎宁安先生向他的老板解释说，这种感觉就像你在为贷款支付利息。这就是技术债务的由来。现在，我想花点时间反思一下这个问题，对吗？是什么造就了最初的技术债务？是意见。

和团队理解的演变，对吗？这一点很重要，因为如果你现在考虑技术债务，它并没有改变。

这个比喻很有力，以至于很多人都在用。30 年后，33 年后，人们仍在使用它。我们今天还在谈论它。它超级强大。而且它涉及到很多观点。众所周知，观点是会变的。每个人都有自己的观点。所以我们必须确保牢记这一点。技术债务是基于对什么是构建软件的最佳方法的看法。

‍

Kelvin Del Monte
那么，是什么导致了技术债务？正如我们刚才谈到的，技术债务是团队成员不断发展的认识。它可以是其中的任何一种。随着学习的深入，你之前的选择不再有意义，或者比现在的选择更没有意义。短期决策。你正在建设一个项目，也许你的时间很紧迫。你没有足够的时间。

而你又无法充分提前思考或规划项目，以帮助你看到前方或提前规划。因此，你会做出所有这些短期决定，并不断累积。在做出这些决定的同时，你也在积累技术债务。你也可能会有糟糕的架构选择，这可能是由于缺乏经验或...

当你有架构上的选择，而整个应用程序又是一笔巨大的技术债务时，这些情况就会发生。你还会在这里或那里看到杂乱无章的代码，这些代码来自不同的贡献者。重复，有时没有测试。这也是技术债务。这也会造成技术债务。团队变化。很大，很大。

技术债务。因此，你可能有你的团队，你知道，一直与你合作的团队。比方说，你是产品负责人或利益相关者，而你有一个开发团队，五年来一直与你合作，没有任何变化。他们可能不认为自己的项目存在任何技术债务。

但恰好有几位工程师离开了，你又从其他环境引进了一些工程师。而对他们来说，这又是非常基于观点的。对他们来说，你有大量的技术债务，他们会开始指责你。这些技术债务可能是实际的技术债务，也可能是他们的观点。而且没有任何依据，对吧？没有实际证据，这一点我们稍后也会谈及。

‍

Kelvin Del Monte
当然，转变需求也是一个非常常见的问题。开发人员会一遍又一遍地修改同一段代码，以增强某个功能，在不破坏先前实现的情况下稍微改变一下功能。这一切都发生得非常快。因此，随着代码的迭代，这也与短期决策息息相关。很多决定都是在执行过程中做出的。

这就导致了技术债务。技术债务是一种自然现象。我的意思是，我们已经谈过这个问题了。这是一种进化，对吗？因此，当你向前迈进时，你就在积累技术债务。在地球上，人类或人工智能所做的项目中，绝对不会存在或永远不会存在没有技术债务的项目。

这对你有什么影响？技术债务会在很多方面影响你的项目、组织和产品。在安全方面，你可能会有几个你不知道的漏洞，因为它们被淹没在这些面条代码或没有得到适当维护的代码中。

速度问题也是最大的抱怨之一。实际上，速度问题就是这个词的由来，对吗？坎宁安先生向他的老板解释说，嘿，每次我们与这些旧代码交互时，我们的速度就会减慢。所以，你的团队就是你的工程团队。

速度降低的原因是，他们不得不与这些旧代码进行交互，而他们并不确定如何维护这些代码，或者他们认为这些代码难以维护。这就伤害了开发人员的士气，对不对？我曾经遇到过这样的情况，你所处的环境似乎整个应用程序都被贴上了死标签。你害怕做出改变，因为你可能会引入一个 Bug，导致生产问题，让公司赔钱。

‍

Kelvin Del Monte
你不希望被困在这样的环境中，因为这会给你带来很大的压力，老实说，人生苦短，你既想好好工作，又不想承受这么大的压力，所以这给开发人员带来了很大的压力，也损害了他们的日常生活。

因此，我在这里引用了一句话：企业领导者应将技术债务视为交付风险，而不仅仅是工程方面的问题。这是你如何获得认同的一部分，我们将在以后的幻灯片中稍作讨论。

‍

Hayden Baillio
很好。

‍

Hayden Baillio
Kelvin，我喜欢这句话。我喜欢这句话。我喜欢这句话，因为很多时候，我觉得我们与很多工程师交谈时，看到他们不得不去与他们单位的业务领导交谈，他们只是在推卸这种担忧，比如，是啊，好吧，我们有一个生命周期结束的软件。这是个更大的问题。这些旧软件、技术债务阻碍了我们提供更好的产品、体验或解决方案。所以我很喜欢这句话。它很棒。它更大。技术债务不仅仅是工程部门的问题。我喜欢这句话。

‍

Kelvin Del Monte
100 % 100 % 有时很难让 C 级人员或高管理解这一点，但我们必须让他们理解，因为这不仅对我们工程师或产品所有者有利，也对他们有利。我们正在努力帮助我们 帮助你们，基本上就是这种情况

下一张幻灯片是我的另一个备忘录，它与开发人员的士气有关，对吗？有些工程师离开公司，就是因为他们不得不面对这些技术债务。这种情况我见过一次又一次。有时，有趣的是，创造这些技术债务的人

大部分的技术债务都是像这样蹑手蹑脚地从房子里逃出来的，而技术债务却在扼杀着团队中每一个真正留下来的人。是的，这与一些离开的人有关，他们不是技术债务，而是技术债务。

‍

Hayden Baillio
棒极了。

‍

Kelvin Del Monte
所以是的，它发生了。这种情况时有发生。它会导致人们离开你的公司、团队，当然还有工程师。那么，我们能做些什么呢？这是一个显而易见的问题。它伤害了我们的公司，伤害了我们的产品、员工和团队士气。因此，我想谈谈一些常见的误区。基本上，我们应该从我们不应该做的事情开始。这些都是我过去做过的事情。

我想提醒大家的是，千万不要试图去做这些事情，因为你最终很可能会走上错误的道路。因此，只能被动地修复技术债务。这是一种非常幼稚的方法，也是你会对团队说的方法。在你的职业生涯中，你总会听到这样的话。有人会说，我们边做边修就好了。

或者，如果你在一个文件中，而该文件包含了一些在这里有问题的债务，那么就继续修复它。不，这行不通。它影响了范围，有很多问题。它会影响你实际工作的范围。

这可能会让你错过一条时间线，然后你的备用方案就会是，我正在担心我在文件中发现的另一个问题。所以它会污染你的范围。我们绝不希望这样，对吗？当我们遵循敏捷原则时，你要确保你的工作范围严丝合缝，而不是出现这些可能有也可能没有的技术债务问题。

每当你打开一个文件或处理一段代码时，都会在这里显示。因此，这不是你想要做的事情。这不是你想要采取被动方法的东西。你要绝对采取积极主动的方法。首先确定它，然后为它制定计划，然后获得，以及实际确定它，把它写下来，从你的团队成员中获得一些支持，这一点我们将在未来讨论。

‍

Kelvin Del Monte
你永远不要被动地去做，这是一个糟糕的方法。其次是没有可见性，如果你做的是反应式的，如果你做的是反应式的，这也是一个问题。比如，只有你自己知道，或者不管是谁审核了你的代码，这个问题曾经存在，而且已经被修复了。你的团队并不知道。没有办法跟踪它。所以，没有可见性或任何与之相关的优先级。

这也是你不想做的事情。这里是永远不要做的事情之王。这就是过度承诺大规模重构。我过去也这么干过。我也参与过几次，尤其是在我职业生涯的起步阶段，那时我经验不足，应该说更有激情。更多，而且绝对更天真。

在一些事情上，我想使用最新的技术，我想尽可能快地做到这一点，而没有真正考虑这么多的业务，这是为你和你的同事支付账单，并为你的家庭和你的客户正在使用的许多东西提供保障。这才是最重要的。而不是你正在考虑的大规模重构。因此，即使在你成功的情况下，这种大规模重构也是如此。

你失败的几率就会大得多。即使是那些支持你在未来进行大规模重构的人，在这次大规模重构的过程中，当他们开始痛恨自己的日常生活时，他们也会忘记是他们支持了你。因为他们所经历的痛苦，就像以色列离开埃及时，他们回过头来说，埃及是多么伟大。

当然，你在沙漠中央，几乎快死了，你找不到水。当然，你会回首往事，埃及是个不可思议的地方，对吗？但这正是将要发生的会耽误一些时间。它基本上会阻止你的团队发布功能，因为每个人都在全力以赴，投入到这次大规模的重构中。

‍

开尔文-德尔蒙特（Kelvin Del Monte）
这很有可能，意思是说，所有的机会都对你不利，很有可能会把你带入，把你置于这样一个位置，即你是造成这次大规模重构的人。即使你错过了，这也是一项巨大的成就。你只错过了两天或三天。你现在的处境是，每个人都承受了太多的痛苦，业务岌岌可危，而这一切都是因为你或支持这次大规模重构的人。这样做是不对的。

真的如果这是你的团队唯一可行的方法，那一定有非常非常好的理由。大多数情况下，这并不是唯一的办法。这是我在职业生涯中学到的东西。我把这句话放在这里，那就是通往地狱的路是用良好的愿望铺成的。对于这次重构，你可能有着最美好的愿望。

但听着，这不是你或你的朋友想要使用最新技术的问题。这关系到你的团队。你必须在取得共识后才能继续前进。你必须确保你做事有条不紊，每个人都同意，而不仅仅是你的好意。这将会把你引向一条可怕的、可怕的道路。

好了，接下来说说有效的策略。我试过这些，效果非常好。它们和我们刚才说的正好相反。因此，我们将详细介绍这些策略，但我只想在此列出它们。跟踪深度、明显负债、估算、获得执行人员的支持，然后执行，这就是这位作家的概念。执行的方式有些微妙，我稍后再谈。

如果有必要，还得请外援。这并不是什么丢人的事。实际上，作为我们的组织，这也是员工的一种福利。我们稍后也会谈到这一点。那么，好吧。明显追踪债务。所以，我把这些要点放在这里。所以，你必须大声说出来。

‍

Kelvin Del Monte
你必须对整个团队大声疾呼债务问题。你发现任何你认为团队应该解决的问题，你都必须提出来。在团队会议上提出来。无论是站起来，还是在回顾中，也许你有一些东西，也许在积压工作梳理中，你都可以开始说这些事情。在这里找到一个你可以...

把这些事情说出来，让你的团队知道。你想和你的团队一起了解，这又回到了一开始的观点因素。你可能会认为这是个死胡同，但你可能会让其他同事向你解释为什么这不是死胡同，也许你还没读过某些文档。也许你并不熟悉这部分代码，也不知道为什么要这样写。还有...

文件，让你的生活更轻松。也许它还没死。所以，首先你必须达成共识，你的团队是否认为这是正式债务，它是否可以被标记为 "死亡"，对吗？

要想提高，要想有这样的知名度，就要考虑一下。它必须出现在你的黑板上。它必须出现在积压工作的某个地方。必须在积压工作梳理会议上讨论，否则就会被遗忘。因此，作为工程师、项目经理，无论你是项目经理还是项目经理，也许你都在多个项目上花费时间。

在我看来，每个人，甚至是一些高管，都在关注你的积压工具或项目管理工具。所以，Jira、Santa、Trello、Monday，这些工具都可以。

‍

Kelvin Del Monte
它们具有很高的可见度。事实上，这也是它们存在的原因，因为它们可以让你开展工作，组织工作。技术，对不起，技术债务绝对必须记录在这里，并以可操作的方式记录。因此，在记录技术债务的过程中，你必须与项目经理或技术负责人合作。

或者，如果是你自己的问题，那就与你的项目经理合作，把这些事情记录下来，并把你能提供的所有信息整理出来，使其具有可操作性，对吗？

不一定要一次性完成，但这正是积压工作梳理的目的。输入细节，然后边做边梳理。确保可操作，并通过创建史诗将其分开。我过去也这么做过，在 JIRA 或其他工具中创建一个史诗。这是一个史诗，你知道，不是一个永远运行的史诗。这只是一个史诗，里面的任务数量有限，只能解决一个问题。

可以这样处理。因此，请确保您以自己认为合适的方式对其进行了组织。在其他一些环境中，我们以前也使用过标签，非常重标签的环境经常使用 JIRA 标签。我们以前也用过。无论你喜欢以何种方式组织它，都要确保它被组织好，并且对团队可见，并在团队会议上被提出。可见性会导致死亡。

变成你可以真正优先考虑和努力的事情。你无法解决你看不到的问题。眼不见，心不烦。

‍

Kelvin Del Monte
好的，首先让我们谈谈成本估算，好的，你的债务已经可见，你的团队正在讨论它，你的积压梳理会议，把时间精力放在它上面。

你知道，你可能会做故事点，你可能会做一些其他的估算，但所有这些都归结为某种成本，对吗？因此，这可以让你把这项你认为重要的、拖团队后腿的任务做出来，并把它提交给你的执行团队，这就是我们接下来要谈的。你要确保，你知道，高管们关心的是......

你想做的这件事的可行性有多大？他们想，你知道，他们用数字来思考。他们想权衡一下，看看对这笔债务采取任何行动是否合理。

还是可以推迟到将来。因此，你要向他们提供成本，不管是时间成本，还是执行团队能够理解的估算成本。你要确保与团队和项目经理合作，确保梳理这些技术债务故事，并对其进行某种估算。

当然，这也会带你走上这条道路，让你拥有一个或多个超级完美的技术债务史诗，并将其呈献给你的执行团队。然后，你就可以获得 "买进"，也就是批准真正开始工作，并就我们如何以及何时有能力开始这项工作提供某种指导。我举的一些例子如下

‍

Kelvin Del Monte
这个错误之所以存在，是因为在过去的一段时间里，这些事情都曾发生在我身上，我曾提出过这样的问题：嘿，为什么会出现这个错误？出现这个错误是因为我们没有单元测试。我们没有意图测试覆盖，而这正是我们一直要求的。所以，向他们提出来吧。这就是技术债务的原因，这就是技术债务如何影响你和你的底线。我向你保证，他们会非常非常认真地对待技术债务问题，对吗？

当你提出来时。在这一点上，你会有一堆完全可执行的任务，这些任务都有相关的成本，当他们要求你交付功能时，你可以更容易地获得高管的支持。你必须把你的痛苦、工程设计的痛苦、项目管理的痛苦转化为他们能够理解的东西。交付速度、风险、知识、为公司赚钱的功能交付风险。

最后，现在你已经得到了批准，那么你应该如何实际执行和推进呢？你已经得到了执行团队的批准，可以向前推进了。既然你已经得到了批准，也许他们的批准是松散的。他们没有给你指导，而是让你按照自己的意愿行事。好吧，这又回到了 "不会做 "或 "不做 "的问题上，这是绝对的。

不要进行大规模重构。像这样做，作家们。在高中的时候，我了解到在美国政府，或者应该说是国会，有这样一个概念，那就是 "编剧"，即在即将通过的大法案后面附加一些较小的法案，或者说这些法案已经做了大量的工作。

他们附加的这些小账单，有时与附加的大账单毫无关系。因此，你也可以用这种方式来处理技术债务，即在每个冲刺阶段预留一些周期。这样，你就能继续交付功能，同时减少技术债务。我知道，有时你做不到这一点。你可能做不到，但这应该是最佳方法。

‍

Kelvin Del Monte
循序渐进，不断取得小的进步。随着时间的推移，它们肯定会产生 100% 的复合效果。无论时间长短，半年还是一年，你都会看到不同之处。在不断推出新功能的同时，您的应用程序也会更加健康。每个人都会很开心。作为领导者，你很开心。你的团队也很开心，因为你作为领导者或作为团队成员真正采取了行动。

很显然，你的利益相关者会很高兴，因为他们正在交付功能。

因此，我想说的最后一个建议是，如果有必要，可以请外部人员帮忙，这也是我们的优势所在。实际上，我将在下一张幻灯片中介绍我们的具体做法，但这就是我们的面包和黄油。所以，你可以让我们这样的公司来帮你解决技术债务问题。

我们会在你的团队进行功能发布时关注这一点。这对于大规模升级，或者你正处于支持依赖性地狱，或者你知道，你想用其他技术或其他语言进行深度重写，都是非常有用的。我们可以提供帮助，你也可以寻求外部帮助。这可以提高开发人员的士气，因为这就像是公司给他们的福利。你是一名工程师。你可以继续开发功能。

你的公司会请外援来做那些你可能觉得不那么有趣的事情，也就是解决所有这些技术债务。因此，考虑引入专家是非常重要的。我想向你介绍一下我们 Hero Devs。我们从 2018 年就成立了。

‍

Kelvin Del Monte
我们有 800 多家客户，来自财富 500 强、财富 100 强企业。我们专注于，你知道的，停止支持，在许多方面支持生命周期结束的软件。我们有一支绝对优秀的团队。我们在这方面已经做了很长时间。下面是一些与我们合作的公司。这是一个...

我的同事们称之为 "感觉良好的幻灯片"，它向你展示了我们的业务。我们与所有这些公司合作，帮助他们进行迁移。此外，我们还有另一种方式来帮助这些公司，那就是通过我们的 NES（永无止境的支持）。

的产品系列。我们简称它为 NES。因此，这就以不同的方式解决了技术债务问题。我想以AngularJS Twangular 迁移为例。很多团队可能在 2010 年就开始构建自己的应用了、

2011 年，您可能正在使用AngularJS。但当你完成产品时，他们已经迁移到Angular 了。所以你不可能，也许你没有资源迁移到Angular。那你该怎么办？现在，你已经失去了支持。显然，我们可以帮助你迁移，但你不必真的迁移。

我们将为您在这里看到的许多图书馆和更多图书馆提供支持。如果您联系我们，我们还将提供更多支持。是的，我们可以帮助您在您正在使用的软件或库的生命周期结束时继续获得支持。这显然也消除了强制技术债务，也就是你正在使用的技术不再支持。因此，这也算是为你创造了债务。所以，我们...

‍

Kelvin Del Monte
不断扩大我们的产品范围，是的，我想海登在过去一年里我们发布了多少产品？

‍

Hayden Baillio
去年，我们发布了 20 多款新的 NES 产品。我认为这很酷，因为我们看到很多新产品都是由我们的客户驱动的，而且我们已经在帮助那些使用 Interlife 库的人找到我们，他们说，嘿，我们也需要这方面的支持。你们能做到吗？因此，我们有很多业务或新产品开发都是由现有客户推动的。

是啊，我总是乐于倾听新的需求。这是肯定的。

‍

Kelvin Del Monte
是的，有很多人对此感兴趣，当然，如果我作为客户来到 Hero Devs，而我正面临着无法完成的大规模迁移，这就是我的救命稻草。所以，是的，你不必做任何事情。即使在软件生命周期结束时，你也可以继续发布功能。因为当你购买 NES 时，它已不再是生命末期软件。

总之，最后的提示和启示是从小事做起，确保技术债务清晰可见。尽可能将其融入到交付过程中。如果需要，可以寻求外部帮助。不要追求零负债。这很正常。这是构建软件的自然组成部分。它会一直存在。管理好它就行。感谢您抽出宝贵时间，下面请海登先生结束发言。

‍

Hayden Baillio
是的，不，非常感谢，Kelvin。谢谢你的概述。技术债务绝对是我们接触过的每个人都会遇到的问题，它无处不在，对吗？你无法摆脱技术债务。我认为，我们在这里开始采用的说法就像，你知道，如果你采用开源，那么你就是在采用技术债务。事情就是这样。你只是在采用未来的技术债务。我认为你给出了一些很好的实际见解。我们很有可能将录音发布在YouTube上。谢谢大家的参与。

我知道我们已经超时七分钟了，我们将不得不，你知道，如果你有Q问题，请联系，你知道，邀请你参加这次网络研讨会的个人，或者，或者联系，如果你愿意的话，特别是联系凯尔文。Kelvin，如果大家有这方面的问题，你有什么好的联系方式？

‍

Kelvin Del Monte
此时，您可以给我发电子邮件，kelvin at herodevs.com。我很乐意回答您的问题并与您联系。

‍

Hayden Baillio
Kelvin at Herodotus.com。非常感谢，感谢大家的参与。谢谢你，开尔文。保持安全，并开始计划如何处理技术债务。和平，英雄们。