当处理一个包含许多不同文件的项目时，我似乎总是不了解零件之间如何交互。我从来没有真正遇到过孤立地了解较小的组件的问题，但是随着项目的复杂性增加，我发现自己无法从心智上理解正在发生的事情。随着方法和源文件数量的增加，我尤其在OOP项目中注意到这一点。
我的背景：我是一个自学成才的网络程序员。我主要使用python处理快速而肮脏的脚本，但是我也做了一些基本的django项目。我喜欢flask之类的Web框架，因为在单文件布局的简单性中，我可以轻松（大部分）跟踪正在发生的事情。
现在，我处于需要与其他人开发的大型Zend Framework PHP项目进行交互的情况，而试图理解扩展到许多文件的代码让我不知所措。
您发现哪些技术和过程对理解他人开发的大型代码库有用？您是否找到任何特定的图表来帮助您掌握大图？
Answers:
理解大型代码库的诀窍是不要试图完全理解所有代码。达到一定大小后，您就无法在整个过程中保持思维模型。您从一个锚点开始，该锚点对于您首先需要执行的任何任务都是有意义的，然后从那里进行分支，仅学习您需要的部分并相信其余部分可以像宣传的那样工作。就像了解递归一样。如果试图将整个堆栈都放在脑袋中，大脑就会爆炸。
Grep，调试器和intellisense是您的朋友。如果您不知道函数最终是如何被调用的，请在该函数上设置一个断点，然后逐步处理堆栈跟踪。
还要注意的另一件事是，大型代码库并非一无是处。它越大，越有经验的程序员，因此请问他们从哪里开始，但要具体。提出类似的问题，“我需要添加新的付款提供商。我应该在代码中的什么位置看？” 只专注于该任务，而不是试图理解整个代码库，您的熟悉程度将逐步提高。
没有捷径。您只需要忍受它。
为了回答有关如何获取图表的问题，doxygen是您想要的。AFAIK与PHP一起使用。
更一般而言，遇到新的代码库时，我大致经历以下几个阶段：
从用户的角度了解它的作用。能够像超级用户一样亲自实际使用该应用程序。了解真正的最终用户如何使用它。这可能需要与他们坐下来，直到您对他们的工作有深刻的了解。
如果可能，与原始开发人员进行交流。首先，您将遇到最终用户体验引发的体系结构问题。稍后，您将遇到有关边缘情况和细节的实现问题。能够从开发人员那里获得答案将比提供任何评论或文档（最多是不完整的，而且往往会引起误解或完全缺少）的帮助要大得多。
了解您使用的框架。至少，在进入生产应用程序之前，您应该能够使用该框架创建“ hello world”或其他简单应用程序。
掌握整个部署过程（最好由原始开发人员牵手完成）。如果您不能采用当前的代码库来构建它，并不能通过测试/验证/产品环境进行部署，那您就敬酒了。即使是最小的更改，也都需要跳过所有部署环节，所以为什么不立即考虑这部分呢？这样，您将了解该应用程序使用的所有可爱的服务器，数据库，服务和脚本-您将知道它的位置。
掌握功能测试（如果有）。您怎么知道事情是否正常运行？人们对于应用程序的维护和提供有什么操作？
了解应用程序的日志。尽管我从未使用过PHP，但我会大胆猜测，说任何严肃的PHP应用程序都将具有某种类型的日志记录。如果您了解日志，那么当调试问题的时机到来将是一个很好的起点。
----注意，到目前为止，我什至没有提到过仔细查看代码库。有很多，你可以了解一个大型项目，甚至没有看代码。当然，在某些时候，您必须熟悉代码。这对我有帮助：
对于图表，doxygen是一个出色的工具，它将为您生成调用图和其他关系。它恰好具有PHP功能！如果您没有尝试过氧气，那么绝对必须旋转一下。尽管我不能保证框架内的代码有多么的可理解性，但是它可以提供帮助。当原始开发人员看到由doxygen生成的代码文档时，通常会感到震惊。好消息是，这确实有助于缓和他们的记忆并更好地帮助您。
如果您有一组单元测试，请仔细查看它们，这将为您提供应用程序内部工作的窗口。这些也将是查找在进行更改时可能引入的错误的第一个地方。
IDE书签对于标记代码库中的热点非常有用。能够快速地通过它们进行切换将促进理解。
阅读最新的错误报告及其解决方案对于理解热点也很有价值，并且可以帮助您快速掌握代码库中最相关的部分。
实际上，我将在本周的过程中开始这样做，新客户需要对其他开发人员留下的产品进行增强。以下是要遵循的步骤：
a）确定所使用的编程框架，这有助于了解应用程序的流程。
b）识别常用服务-日志记录，异常处理，MVC，数据库连接，审核，视图（页面生成），因为这些是我们最常使用的部分。
c）运行普通用户流程（在应用程序中），然后尝试使其与代码的布局方式保持一致
d）尝试进行一些更改，看看它们如何产生。这是最大的一步，因为在开始进行更改之前，代码仍然是黑匣子..
我会告诉您在接下来的两个星期中我还有其他想法
我的想法是您应该阅读文档。我知道黑客喜欢告诉您“代码就是文档”，并以此为借口不写任何文档，但是他们错了。看一下Linux内核，它是一个包含数百万行代码的庞大软件项目：我认为没有人没有读一本书就可以真正了解它。如果您正在使用的代码没有记录（如果是较小的项目，则注释不清），那么它可能不是很好的代码。
如果您要处理零文档的大型工作（我也去过那里，那很粗糙！），我发现对您有所帮助的是尝试隔离正在处理的部分。在代码的那部分中，弄清楚数据/事件/消息/交互如何传入和传出该单元。换句话说，对接口进行反向工程。写下来。下次您在另一个单元上工作时（如果与您首先工作的那个单元对话，则有好处），请执行相同的操作。保留所有文档。几个月后，您将对事物的流向有个很好的了解。
找出正在使用的一个小单元的接口，并记录下来以备后用。随着时间的流逝，您将将大部分工作方式拼接在一起。查找程序的作用并跟踪该消息的流向。例如，如果您的系统接收一些输入网络消息并发送输出消息，则跟踪该消息在系统中的流动方式，而不必担心所有详细信息-只需查看它的去向即可。
我要做的是从所有从Java反向到UML的文件中创建一个UML模型。这种方法意味着模型不再只是项目的抽象视图，而是项目本身完全映射到MOF，因此也映射到UML。
我得到的是一个由多个子模型组成的大型单一模型，每个子模型均由由分类器等组成的包组成。我的意思是，相同的方法可以在项目A中调用一个分类器，在项目B中调用另一个分类器。查看项目完整结构的唯一方法是同时颠倒这两个分类器。我没有时间创建组件图，并且信息不是很准确。我宁愿要求计算机为我撤消整个项目。我在团队的每次迭代中都做相反的事情，我的所有图表都将立即更新。逆向工程是增量的，并使用Java到UML Ids的映射。我的意思是每个Java元素都映射到一个唯一的MOF元素，即使重构，MOF元素在所有项目生命周期中都保持不变。这样做不再给UML建模带来更多限制，并且允许非常非常大和复杂的项目建模。供您参考，我正在与超过500万行OOP代码的项目一起工作。我所有的项目都正确撤消，并且可以进行图形导航
我仅使用类图，因为从我的UML模型中，我可以根据需要创建尽可能多的视图，这些视图始终是最新的。我还可以为非常复杂的项目建模。