无论是开始一份新的工作，还是同一家公司接触新的项目，都会面临相同的挑战：学习代码，开始工作。
了解项目的大致流程
您需要查看产品使用的库 - 它的依赖关系。如何找到依赖关系将取决于语言以及构建工具。由于每种语言和构建工具都有自己的处理依赖关系的方式，因此了解项目用于构建产品的工具链非常重要。
像Ruby on Rails（RoR）这样的项目是基于约定的，这意味着所有的RoR项目都符合相同的设计，文件布局和基本工具链。这样即使在没有接触的时候，也能较快的了解。
如果这个项目是基于配置的项目，比如许多Java项目，那么这个任务会变得有点棘手。许多Java项目使用Apache的Maven，但是如果它是旧的，它可以使用Ant，或者如果是新的，也可以使用Gradle。你需要挖掘才能找到答案。
一旦确定使用了哪种构建工具，就可以经常使用该工具的命令行选项来查看所有可用的任务。搜索信息或使用手册页通常是找到哪个选项将返回可用任务的最简单的方法。例如，Rake将使用-T选项向您显示所有可用的任务。
了解产品的架构和设计
术语体系结构和设计经常互换使用。虽然它们是相关的，但实际上是两个不同的概念。体系结构是系统的高层次观点，而设计则是较低层次的观点。
项目体系结构由项目的多个“视图”组成，并捕获非功能性需求或质量属性，如安全性，性能，可修改性，可测试性，可维护性，模块性，弹性，可用性，甚至上市时间。
相反，设计就是你看到设计模式开始出现的地方。这个层次是你弄清楚不同的类如何相互连接和沟通的地方。
让我们仔细看看如何使用这两个概念来帮助您掌握新的代码库。
体系结构可以让您更好地了解产品的总体布局。通过查看编译时（模块）视图，运行时（组件和连接器）视图以及部署（分配）视图，可以将体系结构拼凑在一起。这些视图中的每一个捕捉系统的不同品质，并且它们一起形成产品的更完整图像。
通过查看代码，架构可能很难被自己发现。如果你足够幸运能够使用一个使用约定配置的产品，比如Rails，那么很多工作都是为你完成的，因为它们遵循相同的基本架构。
如果您正在开发一个基于配置的项目，那么您将需要更多的时间，因为这些项目对其架构没有限制，因此是独一无二的。它们完全受到最初开发它的开发者的影响，架构决策背后的原因很少被记录。
在任何一种情况下，约定或配置，大型项目都会长时间地增长，并涉及到不同的开发人员，他们可能会也可能不会（很可能不会）以良好的文档来捕捉项目的架构决策和变化。
发现产品的设计要稍微简单一些，因为通过设计建立了相关的类。有些工具可以帮助您揭示项目使用的设计模式，以及这些类如何相互联系和交流。最简单的方法是使用工具为项目的全部或部分生成UML类图。如果你对类图不熟悉，他们会显示类（自然是对的），以及这些类如何相关，例如继承，组合。Eclipse，IntelliJ或Visual Studio等IDE可以生成UML类图或支持插件。
了解项目目录
学习代码库的第三个要素是知道事物在物理上位于目录结构中的什么位置。
自然而然，一些像RoR这样的基于约定的项目，由于它们都遵循类似的布局，使得找出位置更容易一些。但这并不是说你无事可做。你需要看看什么是在lib目录中，其中局部视图保存，哪些目录是在app目录之外的预期assets，models，controllers，和views。
对于像Java那样对文件的物理位置及其相关软件包有严格要求的语言，熟悉这种布局将帮助您发现可用的软件包。
对于像Ruby这样没有包到文件位置要求的语言，您可以浏览所使用的名称空间。几乎所有我曾经工作过的Ruby项目都使用了类似于Java的命名空间到文件的位置约定。
探索包（或名称空间）将有希望向您显示它们以合理的方式分组，这可能有助于您发现架构级模块。如何将类分组到包中，以及将哪些包组合在一起，可以表明它们意味着在同一个模块中。
从小功能开始
看看你的修改如何改变最终产品，这对巩固你对代码的理解有很大的帮助。从低优先级，低严重性错误或功能开始，可以帮助您轻松进行更改。
为了让我在新项目中有所作为，我有几个策略，具体取决于项目的类型：
如果缺陷附有堆栈跟踪，我将从项目堆栈中最高的类开始（如果在库中发生错误，可能不是最高级）。
如果项目具有用户界面（UI），并且我正在使用的缺陷或功能具有UI组件，那么我首先搜索在要更改的用户界面中使用的文字字符串。我可以使用它作为交互开始的入口点，并根据它找出业务逻辑的位置。
如果项目是基于约定的，那么我将首先寻找最有意义的视图，控制器或模型（或者任何可能影响缺陷或特征的设计方面）。什么是有道理的，只是你可以猜测什么类可能涉及。
如果项目是一个Web应用程序或服务，我将努力寻找可能涉及的URL路径，并查找哪个类处理对该路径的请求。
如果缺陷或特征不符合任何其他标准，我开始寻找可能接近我想要改变的代码，这需要一些受过教育（或未受教育）的猜测。看看测试还可以帮助找到你想要的代码。
使用这些技术，我几乎总能找到我想要修改的代码段。然后，我可以开始玩一些我可以看到的变化，无论是在用户界面，测试，日志，还是简单的打印到标准输出。
最后总结一下
通过检查构建脚本来发现用于构建项目的工具链和流程。
如果可能的话，一旦你建立了产品，看看它是什么。
查看项目所依赖的库来确定产品使用和依赖的服务和系统。
使用UML图生成工具为您的项目的全部或部分创建类和序列图。
在阅读代码时手动创建序列图。
通过查看部署脚本（如Capistrano）或文档来调查产品是如何部署在硬件上的。
仔细查看项目在文件系统中的布局以及如何将类分组到包或命名空间中以帮助发现体系结构。
使用一个小功能或低优先级的错误作为一种方式来让你的脚在代码中，并开始了解代码的真正作用。记录任何你感兴趣的事情，这可能会帮助未来的开发人员更快地理解项
这个过程需要实践，并不是每一种技术都适用于每个开发人员或项目。整理某些项目对你有用的东西，然后把这些东西加倍加以改善。通过有目的的学习和提炼，可以加速整个过程。
注：文章来源于国外，由名字就服你整理翻译
