最近，我有幸与 hello2morrow 首席执行官兼联合创始人 Alexander von Zitzewitz 聊天。 Alexander 一直是减少技术债务的巨大拥护者，他开创性的方法帮助了包括福特和宝马在内的许多知名公司改进了他们的业务实践。我们就代码质量、减少技术债务的业务优势以及 hello2morrow 当前的项目“用于架构描述的领域特定语言”进行了精彩的讨论。
您于 2005 年与 Dietmar Menges 共同创立了 hello2morrow。是什么启发了您创办 hello2morrow？
这个想法的灵感来自于我在我以前的公司为宝马所做的一个项目，当时（1999 年）我有一家集成公司，为其他公司做软件项目。宝马要求我们为他们构建类似简单静态分析工具的东西来检查架构规则。所以我们这样做了，这个项目对 BMW 来说非常成功，因为在他们引入了我们所谓的软件测量工具之后，它使他们获得了更好的项目指标。该工具能够根据 XML 文件描述的架构模型检查简单的架构规则。它还计算了一些指标并检查了循环依赖性。这允许为 BMW 定义项目质量门槛。没有通过质量关卡的项目无法投入生产。而且质量门非常严格，你不能有循环依赖、架构违规或异常指标值。
那个项目非常成功，我们一直在想创建一家新公司，并以此为基础打造真正的产品。 2005 年，我们有机会讨论了这个想法，并说“太好了，让我们开始吧。”
您一直是代码质量的拥护者，并且在技术债务这个话题上直言不讳。我们目前的代码质量状况如何？
我会说它正在朝着正确的方向发展，但我们还有很长的路要走。我想说人们越来越关注质量话题，但它通常被搁置一旁。一旦压力变得过高，质量就会一落千丈，人们就不会认真对待它。另一方面，使用像 SonarQube 这样的工具的趋势很大，这确实是朝着正确方向迈出的一步。
但我认为使用这些工具，了解你在测量什么总是很重要的。因为如果您在其默认配置中使用 SonarQube，它就像基本的错误检查器和代码风格检查器一样。他们可以帮助您检测问题，但您会收到很多并非真正关键的问题报告。因此，例如，如果您没有以正确的方式配置工具，您会收到很多关于不会真正损害代码质量的事情的警告。而真正损害您的代码质量、结构和架构债务的东西，我认为是您可能拥有的最有害的技术债务形式，大部分根本没有被报告。
关于系统架构的方面没有检查，但人们会说“哦，我有 SonarQube，我们都很好”。这会给您一种错误的安全感——您的系统可能完全无法维护，即使 SonarQube 显示了大部分不错的指标。但是您已经可以使用 SonarQube 做的一件事是检查包或类似元素与其他语言之间的循环依赖关系，我认为这是一个非常好的步骤，因为太多的循环是烂架构和结构问题的第一个指标。归根结底，您需要了解您正在测量的内容并将重点放在正确的方面。我专门写了一篇博客文章：“ 并非所有的技术债务都应该得到平等对待 ”。
您的核心理念和运营原则实际上可以降低成本并提高效率，但正如您所提到的，这通常会被搁置一旁。你是如何取得这些成果的，为什么它经常被忽视？
我认为它被搁置了，因为压力太大，而且在许多公司中，他们没有正式的质量门，或者非常简单的门，只是没有考虑正确的指标。如果你没有质量关卡并且你有一个最后期限迫在眉睫，你会尽一切努力在最后期限前完成。因此，这意味着您将以更快的速度积累技术债务，尤其是结构和架构债务。而且，好吧，你设定了截止日期，但下一个截止日期已经更加困难，因为你已经积累了结构性债务，现在每一个变化都变得更加困难。这种情况一直持续下去，问题越来越复杂，直到改变的成本太高。这就是我在很多公司看到的。我做了很多软件评估，当我来到这些地方时，我看到许多关键任务软件系统在结构上很烂。有很多循环依赖，很多循环组基本上吃掉了整个系统，一切都连接到一切，然后你可以想象改变变得非常困难。不幸的是，人们大多只是在为时已晚时才给我打电话。
如果结构和架构债务超过某个阈值，那么您对此无能为力，因为在大多数情况下，修复达到该阶段的系统的成本是无法承受的。所以你做不到，你不得不忍受混乱，这意味着你做事的效率并不高。另一方面，如果您可以使软件系统保持非常结构化，如果您可以坚持一些合理的架构原则，那么变更成本的增长就会慢很多。它仍然会随着系统的复杂性和规模而增长。软件毕竟是复杂的，但如果你能坚持一些原则，比如避免循环依赖，并遵循架构蓝图，你就会好很多。我们从客户那里了解到这一点。我们在美国最大的客户是福特，他们已经使用这项技术四年了，他们的项目有了很大的改进，因为他们不再落入这个陷阱。我们从许多其他客户那里听说，只要遵循这些原则，他们就能够削减大约 50% 的维护成本和 20% 或 30% 的项目生命周期成本。
但是 [这些结果] 需要大量的纪律，这就是重点。大多数时候，我认为我们在购买软件的人和编写软件的人之间存在很大的脱节。而为软件买单的人当然希望以尽可能低的成本和尽可能快的速度得到结果，但他们不了解技术债的概念和技术债的影响。当团队回到他们那里要求重构时间和预算时，你真的没有得到足够的，然后问题就复杂了。摆脱这种局面的唯一方法是在公司制定一项自上而下和自下而上定义质量的战略，以便管理层中的每个人都认同质量关卡的重要性。然后你必须相应地实施你的开发操作并定义那些质量门并且不要让它们在系统中有一点压力时就溜走。而且系统中总是存在压力，这是事实。
Hello2morrow 有很多知名的合作伙伴，包括宝马、福特、巴克莱、英国石油公司和黑鸭子。您的哪些客户正在采纳您的理念，这些理念是如何实施的？
我们基本上有两组客户。一组客户购买了该工具，但他们并没有定期使用它，他们没有将其集成到他们的构建系统中，他们并没有真正严格的质量关卡，这些客户并没有取得很大的成功.它仍然有一些改进某些代码库的效果，但它们没有我们正在谈论的真正的成本削减效果。要获得这些成本削减效果，首先您必须将以结构和体系结构为重点的静态分析集成到您的构建系统中，这样如果出现问题，引入新问题时构建就会失败，其次是它有被定义为自上而下。所以自上而下的人必须说“我们希望随着时间的推移让这些质量指标变得更好，或者我们至少要确保它们不会变得更糟。”如果将这两件事结合起来，这就是成功的秘诀。一旦你遗漏了一个元素，要么没有管理支持，要么没有完全持续集成到你的构建中，你可能无法获得好处。大约 50% [的客户] 真正做到了，他们明白了，许多其他人在购买时会分心，所以仅靠工具无法帮助您，您需要工具和开发策略的变化才能成功。
您已经多次提到降低成本。提高代码质量和减少技术债务的其他具体效果是什么？
主要的实实在在的好处是人们盯着屏幕的时间会减少。因为如果你分析你的开发人员整天在操作中所做的事情，他们有一个混乱和腐烂的代码库，很多周期而没有留下很多架构结构，人们会花 80% 的时间盯着屏幕来弄清楚在他们甚至可以考虑更改他们的代码之前，该死的代码在做什么。他们首先要弄清楚这一块与另一块有什么关系，这块与系统中的其他块有什么关系，需要花很多时间才能理解。即便如此，如果你进行了更改，你也不会感觉很好，因为你永远不知道你是否会破坏其他东西，因为如果缠结指数非常高，你就会在不同部分之间有很多联系系统，回归的可能性正在飙升。如果你能避免这个陷阱，人们就有更多的时间来实际编写代码，这意味着有更多的时间来真正生产出能带来商业利益的东西。
另一个好处是，如果您雇用新人，他们的运作速度会更快。他们不需要这么长时间来弄清楚系统是如何构建的。
从软件方面来看，这对软件性能有影响吗？
不一定，这真的取决于。你可以说，糟糕的性能更可能出现在结构糟糕的代码中，因为人们不明白代码在做什么。但是良好的结构本身并不意味着你会获得更好的性能。但是如果你能更好地理解你的代码，如果它是可读的，我认为你将能够编写出性能更好的代码的可能性要大得多。
但它确实提高了代码的可维护性和可理解性，这一点很重要。如果它不可维护，那么你要花很多钱才能让它存活下来。
这么多开源库对质量和可维护性有何影响？
好吧，这是一个棘手的问题。首先，查看开源代码本身很有趣，因此我们可以使用我们的工具分析开源代码，找出哪些开源库在质量方面做得很好，哪些做得不好。这本身就是一个非常有趣的实验。我们已经知道 Spring 框架维护得非常好，因为它们遵循自己的架构规则。其他项目，例如 Hibernate 或 Apache Cassandra，在结构和体系结构方面已经处于不太好的状态。它们有很多纠结，它们非常紧密地耦合，并且维护这些代码库要困难得多。使用开源库的项目质量只会受到间接影响。您将开源库视为外部的东西。它不是您的代码库，它只是您正在使用的工具。因此，仅仅因为您正在使用 Hibernate 并不意味着您的软件质量好坏。你写了一些完全独立的东西，你只是在使用 Hibernate。
hello2morrow目前有哪些计划？
我现在正在做一些非常酷的事情，老实说，这真的很有趣。我正在研究一种用于架构描述的领域特定语言。所以基本上你通过定义我们所说的架构工件和它们之间的关系来用这种语言编写你的架构，这似乎是一个非常有前途的概念。所以我们现在正在使用它，我们正在进行不同的实验，我们对此感到非常兴奋。
我们对 Sonargraph 7 中架构模型的灵活性不是很满意。它对元模型有一点限制。所以你可以对大多数东西进行建模，但是有些东西你必须以某种方式建模，而且你建模的方式不是很灵活。如果你有一个大的架构，事情会变得有点复杂，特别是如果你想有任何特殊的规则。所以我们考虑如何改进它。所以我们说“为什么我们不把架构看作一个更通用的概念，在那里你有基本的架构概念，它们是架构组件或原子的容器。架构原子是您可以分配给架构元素的最小单元，例如，在 Java 中，它是一个 Java 文件，在 C# 中，它是一个 C# 文件，在 C++ 中，它是一个源文件和一个头文件的组合文件。
因此，您将我们称之为组件的那些分配给架构工件，并将软件系统分组为工件的嵌套组，并定义它们之间的关系。然后我们用这种语言的不同特性在它们之间进行了实验，比如工件的接口和工件的连接器，我们发现你可以拥有一个非常强大的工具，以许多不同的方式对结构进行建模。您不会拘泥于一种建模架构的方法，因此您基本上可以做任何您想做的事情。您甚至可以在不同的体系结构文件中描述体系结构的不同方面。这是另一个很酷的功能。如果你不想在一个大的单一文件中描述你的架构，你可以将它展开，一个文件描述客户端和服务器之间的架构，另一个文件描述分层，另一个文件描述你的业务组件，这给了你很大的灵活性。很酷的是，很多人更喜欢使用文本而不是图形编辑器，因此您基本上可以使用文本来描述您的架构。
