去年夏天，我有幸成为 Google Angular 团队的一员，负责源代码索引器的工作。我为 Google 的代码库开发了一个 Angular 索引器，为存储库中的静态文件启用了语言服务的功能。作为这项工作的一部分，我向 Angular 编译器添加了一个新的语义分析 API，称为索引 API 。

Angular 框架无疑是我使用过的最大、最复杂的代码库，它教会了我有关软件开发的宝贵想法。这篇文章讨论了我在理解和处理大型代码库方面所学到的知识，以及自从从事 Angular 工作以来我对开源贡献的信心发生了怎样的变化。如果您对我的工作的技术方面感兴趣，我已在另一篇文章中讨论了它们。

从上面看到的景色

在使用 Angular 编译器完成少量工作后，我发现在为大型项目做出贡献时通常最好着眼于大局。

Angular 是一项巨大的努力——撇开 Angular CLI 或 Angular 组件不谈， Angular 框架本身就有 50 万行源代码。就上下文而言，Chromium 接近 5MM SLOC，Rust 的rustc编译器约为 700K SLOC。

Angular 框架的很大一部分不会影响使用 Angular 构建的应用程序；其中大部分致力于构建良好的开发体验、文档和公共库。但其主要思想是，很难深入理解所有框架并在三个月内制作出使用它的产品。

不要试图理解一切，而必须将注意力集中在项目中影响和依赖于产品中新集成的部分。那么问题就变成了如何将注意力集中在这一点上，这在大型代码库中可能非常令人畏惧。

---

当我在 Angular 编译器中安装新的 API 时，我开始将其想象为至少三层的堆栈：

• 产品层，由编译器作为一个整体组成。
• API层，提供产品使用的API。
• 模块层，由 API 使用的较小代码单元组成。

因此，新的 API 既消耗一些模块，又被产品消耗。

考虑每一层的复杂性很有趣。在我看来，理解每一层的某些内容的复杂性随着层树的顶部而增加。理解封装在单个模块中的逻辑可能很容易，但理解封装在模块使用者中的所有逻辑要困难得多；对于使用多个模块的 API，它可能会复杂 10 倍，而对于整个产品，它可能会复杂 100 倍。这些是粗略的数字，但这个想法是成立的。

鉴于此，请考虑一些新的、正式的 API 规范。至少有两种策略来弄清楚如何实现此 API：

• 自上而下：从产品层开始，往下看API应该插入到哪里。
• 自下而上：从模块级别开始，向上查找 API 需要组合哪些模块。

这两种方法之间的区别在于自上而下划分了理解的复杂性；自下而上放大了复杂性。较低抽象级别通常不应该了解较高抽象级别；尝试这样做会增加较低级别抽象的复杂性。但由于高级抽象是包罗万象的，因此从顶部看，抽象的复杂性（和心智模型）是分裂的。

最终，两个方向都会达到相同的复杂程度。到达那里才是最重要的。我并不相信它总是最好的方法，但对于像 Angular 编译器这样的大型代码库，我发现自上而下的方法在做出集成决策时要容易得多。

当然，这是一个微妙的结论，但我认为对于经历规模效应的大型项目来说，这是一个普遍合理的指导方针。在小型项目中，更改模块中的某些内容可能很容易，然后通过 API 和产品层将更改向上冒泡。但这在大型项目中通常很困难，因为有很多移动部件使得它通常更容易通过了解模块在整个产品中扮演的角色来首先得出整体实施计划。

最终，两个方向都会达到相同的复杂程度。到达那里才是最重要的。

试穿鞋子（有可能翻译【试试】比较合适？）

除了开发方法之外，我在 Angular 编译器方面的工作还教会了我一些如何处理不熟悉的项目。我在这里谈论开源软件项目，但这通常适用于任何类型的项目。

我认为开源项目有点像贡献者穿的鞋子。当一个人选择穿什么鞋时，至少会考虑两个因素：

• 款式搭配——鞋子是否有适合个人的款式。
• 无障碍匹配——鞋子是否适合个人。

在这些考虑因素上，开源项目与鞋子类似。贡献者希望对一个项目感兴趣并帮助开发它，并且还必须找到可访问的项目开发——也就是说，贡献者更喜欢更容易启动并拥有资源网络的项目。

做出贡献是困难的。观察一个人一无所知的东西，弄清楚它是如何工作的，然后对其进行增强以做一些不同的或新的事情是很困难的。如果有足够的时间，这总是可以做到的，但没有人有足够的时间。因此，对于考虑在项目中投入精力的贡献者来说，决定通常取决于项目风格和可访问性匹配的考虑。

我思考过如何让项目更容易被其他人使用；有很多人对这个问题进行了更多研究，并且比我有更好的答案，但也许最重要的答案之一是开发人员文档。优秀的代码注释和描述项目实现的书面文档使贡献者更容易开始创建心理模型。这比贡献者身边有一个代码作者更有价值，因为作者会忘记或离开去做其他事情，但文档会永远保留。

另一件事对我来说，至少在某种意义上，贡献是一种技能。随着时间的推移，我对贡献的看法已经失去了固有的困难和恐吓感。我现在发现打开另一个开源项目并对其进行修改以完成我想要它做的事情相对容易。除了我作为一名工程师的进步的结果之外，我认为这是我所建立的一些贡献直觉的结果。很难解释它到底是什么，但就像骑自行车一样，它就在那里，很难忘记。

对我来说，这种直觉很棒，因为虽然进入一个新社区或引入一个大的改变可能仍然具有挑战性，但对从哪里开始做这些事情有一些一般性的了解，对于提高对自己的贡献的信心大有帮助。这是最重要的事情，因为贡献者应该受到重视。

无论如何，这些都是我的一些经历和想法。我希望他们能够提供一个视角。

文章来源地址：https://blog.angular.dev/perspectives-from-contributing-to-angular-a3340a3b5585