这是哪里来的？-CSDN博客

在企业软件中，几乎每天作为开发人员必须回答的首要问题是“这是从哪里来的？”。当尝试修复错误，开发新功能，重构时。您必须能够跟踪代码流并弄清楚某个值来自何处。

而且，代码库越大，找出某物（某些值或值的组合）来自何处的难度就越大。从理论上讲，它要么来自用户界面，要么来自数据库，但是我们都知道它总是更复杂。我在职业生涯的早期就了解了这一点，当时我不得不浏览一个庞大的电信代码库，以实现功能和修复总共几十行代码的错误。

回答问题意味着轻松浏览代码，调试和跟踪对传递的值的更改。尽管这似乎很明显，但在宏大的计划中并没有那么明显。

框架，体系结构，语言，编码样式和IDE掩盖了“这是哪里来的？”这个问题的答案。对于个人开发人员和整个项目而言，情况都会变得更糟。让我举几个例子。

我对此感触良多， Scala为您提供了许多很酷的功能。还有一些可怕的东西，例如隐式的。隐式类似于全局变量，只是存在嵌套的隐式作用域。当您需要其中一些全局变量时，只需添加“ implicit”关键字，您就可以从最里面的作用域中获取与您要设置的参数类型相匹配的值。在大型项目中，追求隐式值的设置位置并不容易。要弄清楚为什么某些东西具有特定的价值，可能要花几个小时的调试工作，才能弄清楚代码中某些不相关的部分已经触及了相关的隐式对象。这使得很难追踪到东西从哪里来，因此对企业代码库不利，至少对我而言。

Scala的另一个功能是部分应用的功能。您有一个函数foo(a, b, c) （当然，这不是正确的语法）。您在某个时候知道一个参数，而在以后知道另外两个参数。因此，您可以部分调用该函数，然后将部分应用的函数传递给下一个函数，依此类推，直到您有其他可用参数为止。因此，您可以执行bar(foo(a)) ，这意味着在bar(..)可以调用foo(b, c) 。当然，到那时，回答“来自何处的价值”这个问题变得更加困难。如果使用得当（我已经用过，并为此感到骄傲），该功能确实很酷，但应将其限制在代码库的较小部分。如果您开始在各处扔掉部分应用的功能，那将变得一团糟。不幸的是，我也看到了。

对Scala足够了， 微服务体系结构 （我也对此感到mixed异）也使开发人员跟踪正在发生的事情的能力变得复杂。如果对于给定的请求，您调用3-4个既返回数据又处理数据的外部系统，则调试应用程序将变得更加困难。不必放置断点或进行调用层次结构，您必须跟踪与每个微服务的每次交互的参数。对于任何人来说，都有一个新闻，那就是微服务更难调试，但我只是想将其放在回答“这是哪里来的”问题的背景下。

动态键入是另一个示例。我把它包括在内，这也是为什么我更喜欢静态类型的原因。 Java IDE具有“调用层次结构”。对于大型企业软件，这是最有用的IDE功能之一（对我来说，它比重构功能更为重要）。实际上，您不仅可以在代码库中而且可以在依赖项中跟踪所有可能的代码流，而这些依赖项通常会隐藏重要的细节（可能是，您将放置断点并经常检查第3方代码）。动态类型无法使您正确执行此操作。在编译时未知类型上调用的doSomething可以是具有该名称的任何方法。追踪东西的来源变得更加困难。

我一直避免代码生成 。它从文本文件中获取输入（使用任何语言）并生成代码，将问题“这是从哪里来的”变成“为什么这样生成”。

一般而言， 消息队列和异步编程 –消息传递会模糊给定数据的源和目标；消息队列增加了模块之间通信的复杂性。使用微服务，您至少具有API调用和队列，在发送者和接收者之间具有多个抽象（交换，主题，队列）。这是异步编程的一个普遍缺点–程序流之间存在某种东西，它们可以“异步魔术”并在另一端吐出一些东西–但是它是否已转换，延迟，丢失和重试，是否还在等待？

通过所有这些示例，我并不是说您不应该使用消息队列，代码生成，动态语言，微服务或Scala（尽管我确实建议不要使用）。所有这些东西都有自己的长处，而它们正是为这些长处而选择的。之所以选择消息队列，是因为您要真正分离生产者和消费者。 Scala因其表现力而被选中。之所以选择微服务，是因为很难用多个团队和多种语言来管理一个整体。

但是，我们应尽量减少无法轻松跟踪程序流以及无法快速回答“这是哪里来的”的“损害”。在您的scala代码库上强加“禁止使用”规则。将代码生成用于更简单的组件（例如，用于protobuf的DTO）。将消息队列与可预测的消息/队列/主题/交换名称一起使用，并使用一些冗长的调试日志记录。确保您的微服务具有命名一致的相应SDK，并且它们可以在本地运行，而无需花费额外的精力来简化调试。

可以预料的是，项目越大，越复杂，跟踪项目的去向就越困难。但是，即使在设计和编码阶段要花费一点额外的精力，也要尝试使其尽可能地容易。您将在一周内设计和编写该功能。您（和其他人）将在未来十年内支持和扩展它。