在我的新工作的两个月，仍然有困难学习一个新的代码库。我该如何改进呢？

Question

我是一个自学的程序员。到目前为止，我在建造我想要的东西方面还没有太多的困难。从历史上看，考虑到一个问题，尤其是我造成的问题，我没有遇到太多的问题。这一切在大约两个月前发生了变化，当时我在一家公司获得了我的第一份工作，我是在对他们使用的框架提出请求后熟悉该公司的。

我为这个职位重新安置，我非常喜欢这个环境，这是一个大约有十个人的团队，据我所知，他们都是非常有天赋的。他们给了我一个宠物项目，在这个项目中，我基本上有完全的自主权。他们强调说，他们不希望开发人员在3-6个月的时间内实现完全的生产力和盈利，并且这个项目将帮助他们理解我作为一个开发人员的地位。感觉很好，一个月后，我被派到他们的一个更大的项目上，这是他们最长期的合同之一。

在切换到这个项目后，我感到有点不知所措，这是一个大的代码库，在那里，我们的客户非常明显的变化，因为它为许多网站提供动力。它也是一个非常复杂的代码库，虽然我把很多困难归因于我缺乏经验--它最初是一个救援项目，在两个独立的框架之间同步所有东西，并且有一些我无法理解的模型，没有文档，还有85%的测试覆盖率。我最初的任务是做一些小的改变，比如在邮件发送失败时实现蜜月通知，或者将最小的测试重写为rspec规范。

然后，我的任务是升级项目所依赖的一个框架。这花费了我不正常的大量时间，我被要求做一些其他的事情，直到一个高级开发人员从假期回来，在这个过程中充当一个支持系统。我被重新分配的任务给我带来了同样大的麻烦。

我和我的雇主坐了下来，跟他们谈了这件事。他们说，这是正常的，鉴于我的经验，我目前满足他们的期望。然而，这是我生命中第一次，在任何合理的时间里，我都无法做到我想做的事情。这是一种其他人都有的感觉吗，这是正常的事情吗？

如果有50,000行的大代码库，那么我们需要多少时间才能熟悉呢？还有其他一些我可能不知道的做法可以帮助我更快地熟悉代码库吗？

Answer 1

我通过以下方法学习了新的代码库，取得了很好的成功。努力理解：

1. 目的:从概念上理解系统或框架的作用。
2. 体系结构:创建系统或框架总体架构的视图。
3. 组件:了解主要部件(组件)如何协同工作。
4. 代码:现在您已经准备好通过调试代码库中的主要流来进行深度潜水了，例如在修复bug时。

以下是每个步骤的基本原理，以及如何处理这些步骤。注意，从步骤1到步骤4可能需要几次迭代，慢慢来。

目的性

这听起来很明显，但我发现，即使是经验丰富的开发人员有时也缺乏对系统主要目的的基本理解。首先要努力学习业务概念*)不受技术限制(例如：“这个系统处理客户订单并发出发票-客户是什么，订单和发票是什么样子的，开发票意味着什么?谁在使用这个系统?他们需要做什么？”等)

*)“业务”的含义:从客户或用户的角度来看

了解概念层面而不特别关注技术是理解其最内在工作方式的一个主要优点--代码只是达到目的的一种手段，而在不知道目的的情况下，所有的代码本质上都是毫无意义的，所以它就会出现。如果你还没有概念上的理解，请找人解释。如果你认为你做了，解释给更高级的人在这个项目。不管怎样，你都会学到很多东西。

Architecture

接下来，努力理解总体架构。这是在技术层面，但没有详细的实现。架构级别的例子如下：

• 层-例如web层，业务层，数据库层，前端，后端，.
• 层-例如用户界面，业务模型，服务接口，ORM，.
• 主要部件--例如订单处理器，发票生成器，客户经理，.
• 基础设施--例如网络设置、服务器、消息队列、

同样，如果你还不知道这其中的任何一个，请某人给你一个概述(最多在1-2个小时内，以避免迷失在细节)。您将受益于记录这种介绍的结果，首先从简单的图表开始(可能使用Visio或类似的工具)，并随着时间的推移开发使用更正式的方法(如UML )的能力。文档化的过程听起来可能是乏味和无用的，但是它是非常有用的，因为它不是结果，而是绘制图表的思维过程。

组件

查看主要组件，了解它们如何协同工作以实现系统的目的。回到概念级别，映射概念和用户对每个组件的操作。绘制流程图或序列图，以查看数据如何通过系统。再一次，绘画的主要目的不是图本身，而是强迫你的大脑去思考它。

这也是将组件映射到代码的好时机。通常，这些组件由几个部分组成(例如，多个程序、类、数据库脚本或系统使用的任何代码构件)。对于每个组件来说，了解各自代码所在的位置是足够好的--稍后您仍然可以深入了解详细信息。

注意:可能你的同事除了实际的代码构件之外没有“组件”的概念--如果有人深深地沉浸在代码基础中，这并不是不典型的。试着问一些问题，例如“从总体上看代码库，是否有程序/包/类等属于一起的领域?作为一个群体，它们的目的是什么?这些领域中的哪一个需要同时工作才能实现X?”

码

取一个特定的入口点进入系统，例如用户界面、web服务、API等，并设置调试会话。然后逐步遍历代码，始终注意当前执行的代码属于哪个组件。在你的脑海里，把这个实际的流程映射回你以前的流程图，如果你发现了遗漏的地方，也许会更新它们。

您也可以使用分析器来代替调试会话中的代码。也就是说，一个为您记录流并显示所有子例程调用的层次结构的程序。

另一种选择是使用代码分析器/逆向工程工具，该工具能够降低依赖关系的层次结构。然而，根据我的经验，这些工具生成的数据太多，对新手来说并不有用，这就是为什么我更喜欢调试方法。

Answer 2

你说你是一个自学成才的程序员，通过这个问题，我想你以前对这么大的项目没有经验。

就我个人而言，我的经验比你少，所以不要把我的话当作上帝的礼物。老实说，我认为当你没有经验的时候，被这么大的项目压垮是完全正常的。如果他们已经表示你满足了他们的期望，那么你真的不应该那么担心。

正如您所说的，没有文档，如果文档允许的话，尝试改进文档。这将使每个人都得到肯定的帮助。

给它时间。习惯吧。不要害怕问问题，要积极地对待它--一两年后，你就会对它大发雷霆，不知道你怎么会搞不懂这么简单的代码。

Answer 3

你自己说：I'm a self-taught programmer。书籍和线性课程让你走到了这一步，但已经达到了极限。是时候不用被动的指导了。认真对待:接受正规的教学。

大多数人在聘请老师的时候都会有很大的进步:一个能主观地看待你并专注于你个人优点和弱点的人。这可能意味着在一所学校开设一门课程，坐在一位经验更丰富的乐于帮助你的同事旁边，甚至是一门提供主观反馈的现代在线课程。