您如何进入大型代码库？

#1 楼

我一直要做的事情如下：

打开我的编辑器的多个副本（Visual Studio / Eclipse / Whatever），然后调试并执行换行以单步执行代码。找出代码的流程，堆栈跟踪以查看关键点在哪里，然后从那里去。

我可以逐个方法地查看方法-但是，如果我可以单击某些内容然后看看它在代码中的什么地方执行并继续。让我来感受一下开发人员希望事情如何运作。

#2 楼

你怎么吃大象？

一次咬一口:)

严重的是，我尝试先与代码作者交谈。

#3 楼

在完成工作之前我是否必须先进行黑客操作



在很大程度上，是的（抱歉）。

方法您可能会考虑：


尝试从业务角度找出代码应该做什么。
与可能对代码有所了解的任何人交谈。
在调试器中逐步遍历代码。
介绍一些小的更改，看看有什么坏处。
对代码进行小的更改以使其更清晰。注释来解释我的想法
更改变量名以使其更清晰（使用重构工具）
使用突出显示特定符号所有用途的工具
减少变量的混乱代码-注释掉代码，无意义的注释，无意义的变量初始化等。
更改代码以使用当前代码约定（再次使用重构工具）
开始将功能提取到有意义的例程中可能

...以及您可以进行的其他任何简单改进。开始的地方？从您所知道的开始。我建议输入和输出。您通常可以弄清楚这些应该是什么以及它们的用途。在应用程序中跟踪数据，查看数据去向和更改方式。不管有多小，它都有助于我将整个业务视为难题，并庆祝我正在取得的进步。

#4 楼

您的情况实际上很普遍。任何不得不从事现有代码的新工作的人都将处理其中的某些元素。如果该系统是一个非常讨厌的旧系统，则非常类似于您所描述的。当然，目前没有任何文档。首先，许多人建议Michael Feathers建议有效地使用Legacy Code。这确实是一本不错的书，其中包含有用的章节，例如“我无法将此类纳入测试工具”或“我的应用程序没有结构”，尽管有时Feathers只能提供同情而非解决方案。尤其是，该书及其示例主要针对花括号语言。如果您正在使用粗糙的SQL过程，则可能没有那么有用。我认为“我对这个代码的理解不充分，无法更改它”一章谈到了您的问题。 Feathers在这里提到了一些明显的事情，例如做笔记和标记清单，但也很重要的一点是，如果您具有源代码管理，则可以删除未使用的代码。很多人将代码的注释部分留在原处，但这通常无济于事。您必须首先全面了解代码的用途。

如果您必须回答问题，请绝对与导师或团队中的其他人一起工作。

如果发现了缺陷，也可以借此机会支持代码（尽管有时会发现缺陷）您不必为此自愿...缺陷将找到您！）用户可以解释他们使用软件的目的以及缺陷如何影响他们。当试图理解软件的含义时，这通常可能是非常有用的知识。另外，以有针对性的攻击目标进入代码有时可以帮助您在面对“野兽”时集中精力。

#5 楼

当我有一个非常大的源文件时，我喜欢执行以下操作：


将整个混乱复制到剪贴板上
粘贴到Word / textmate中任何
减少字体尺寸最小。
向下滚动查看代码中的模式

回到普通编辑器后，您会惊讶于代码看起来多么奇怪。

#6 楼

花费时间

尝试理解传统代码库时不要太着急，尤其是当它使用的是不熟悉的技术/语言/框架时。这只是一个不可避免的学习过程，需要一些时间。

一种方法是在代码和相关技术的教程之间来回切换。您阅读/观看了本教程，然后查看代码以了解您的前辈是如何做到的，请注意任何异同，做笔记并向任何现有开发人员提问。

”“您为什么这么做这样子就可以做到这一点”

”我注意到大多数在线用户都在这样做，而你们所有人都以另外一种方式来做。这是为什么呢？”你们都选择技术X而不是技术Y？“

这些问题的答案将帮助您了解项目的历史以及设计和实施决策背后的原因。
最终，您将对它足够熟悉，可以开始添加/修复问题。如果这一切看起来令人困惑，或者似乎发生了太多的“魔术”，则您还没有花费足够的时间查看，消化和绘制图表。创建图（顺序图，过程流程图等）是您了解复杂过程的好方法，此外，它们还将帮助“下一个家伙”。

#7 楼

cscope可以执行ctags可以为C做的任何事情，此外，它还可以列出所有当前函数的调用位置。加上它非常快。轻松扩展到数百万个LOC。整洁地集成到emacs和vim。

C和C ++代码计数器-cccc可以生成html格式的代码指标。我也用wc来获取LOC。doxygen可以在HTML中生成突出显示的语法和交叉引用的代码。在浏览大型代码库时很有用。

#8 楼

我向Drupal推荐的方式并不完全与Drupal有关：从问题跟踪器开始。肯定会有旧的，未公开的错误报告。你能复制它们吗？如果是，请更新票证以进行确认。如果否，则将其关闭。您会发现这种使用软件的方式很多，您可以开始查看崩溃的代码库。或者，您可以开始逐步执​​行代码，看看它如何到达崩溃的地方。这样，您不仅会开始理解代码库，还会积累大量的业障，您的问题将受到社区的热烈欢迎。

#9 楼

要做的重要一件事是使用工具生成依赖关系图，以自上而下地探索代码体系结构。首先将.NET程序集或jar之间的图形可视化，这将使您对功能和层的组织方式有所了解，然后深入研究名称空间的依赖关系（在一个或几个亲戚.NET程序集或jar中），从而获得更细粒度的代码概念结构，最后您可以查看类的依赖关系，以了解一组类如何协作以实现功能。有几种生成依赖关系图的工具，例如用于生成.NET的NDepend之类的工具，它生成了下面的图。

#10 楼

我曾经有一个非常出色的软件工程师告诉我，最昂贵的代码分析和维护形式是逐行浏览代码。当然，我们是程序员，而这几乎与工作有关。我认为快乐的媒介是（按此顺序）：
1。获取一个笔记本，为您理解代码的工作方式创建笔记，并随时间推移添加到笔记本中
2。请参阅有关代码的文档
3。与支持该代码库的作者或其他人交谈。要求他们进行“头脑风暴”
4。如果您了解一些细节级别的类关系，请对代码进行逐步调试，以在您认为代码如何工作与实际如何工作之间进行一些综合。

#11 楼

首先了解它的意思-如果没有它，那可能很乱。与用户交流，阅读相关手册。

然后运行并开始浏览似乎是关键功能的代码。

#12 楼

分而治之。我查看了每个功能和相关的代码，逐步进行操作，然后继续进行下一个步骤，慢慢地构建整体图。它们总是非常具有启发性和启发性。

#13 楼

运行所有测试（如果有的话），并查看覆盖哪些代码，哪些没有覆盖。
更改代码。不要破坏测试。

请参阅Michael Feathers的“旧版代码有效工作”

#14 楼

这是我的简短列表：


如果可能，请他人对代码进行高级介绍。考虑了什么模式，我期望看到什么样的约定，等等。这可能会有一些回合，就像一开始我会得到一个故事：随着我对代码的更加熟悉，我可能会有新问题在我处理现有项目的洋葱时询问。
运行代码，查看系统的外观。当然，它可能包含多个错误，但这对于了解其功能很有用。这与更改代码无关，而只是查看其运行方式。
如何将各个部分组合在一起构成一个系统整体？
寻找基础文档的测试和其他指标，它们可能有助于构建代码的内部思维模型。除非有很少的文档和测试，否则我可能至少建议几天。
我如何知道该项目中使用的语言和框架？这里的重要性是区别看待事物和“是的，以前看过十几遍并且相当了解”和“在这里尝试什么？谁认为这是个好主意？”之间的区别这类问题，虽然我不会大声说出来，但我会特别思考，如果我正在查看可能非常脆弱的旧代码，并且编写该代码的人要么不可用，要么不记得为什么事情按原样完成。对于新领域，可能值得花一些额外的时间来了解我在这段代码中可以找到的结构和模式。考虑到以下一些可能的预期想法，请根据您在每个时间点应该做的事情进行项目：


您是否要添加新功能？
您正在修复错误吗？
您要重构代码吗？这些标准对您来说是新的还是很熟悉？
您是否应该只是熟悉代码库？

#15 楼

我总是尝试从程序的入口开始，因为所有程序都有一个（例如main方法，main类，init等）。然后，这将指向开始的地方，有时是如何链接的地方。

之后，我进行深入研究。数据库和DAO在某处进行配置，因此我对事物的存储方式有所了解。也许还启动了某种全局实例类，在那里我可以弄清楚存储了什么。借助良好的折射工具，我可以找出谁在调用什么。

然后我尝试查找在何处配置和处理接口，因为这是信息的下一个输入点。折射，搜索和调试工具可以帮助我进行搜索。然后我可以弄清楚信息处理的开始和结束位置，并遍历所有类文件。

然后我尝试将流程记录在纸上，只是为了一开始就把头缠起来东西。提交按钮传递到通用验证，然后传递到DAO或数据库，然后存储在数据库中。这是大多数应用程序的过度简化，但这是总的想法。笔和纸在这里非常有帮助，因为您可以快速记下所有内容，而不必担心格式化程序本来可以帮助您。

#16 楼

我会说从文档等开始，但是根据我的经验，文档和本地知识的深度通常与系统的年龄，大小和复杂性成反比。

，我通常尝试确定几个功能线程。从功能上讲，我的意思是诸如登录，删除客户列表等之类的东西。如果这些模式完全一致，那么一个线程应该为您提供一个不错的，不一定是完整的系统截面。确定模式是否一致的最佳方法是分析几个线程。

我认为这毋庸置疑，但我认为，最好是从功能的角度而不是技术的角度来理解系统。我通常不会太担心正在使用的工具（ORM，日志库等），而将更多的精力放在正在使用的模式（MVP等）上。以我的经验，工具通常比模式更流畅。

#17 楼

我做了很多事情...

这是我目前针对“某些事情正在工作”的情况的方法，您需要使其“以其他方式工作”。


获取目标，该系统应解决（如果未编写目标）-编写目标。向经理，其他员工（甚至以前的员工）询问是否有空。询问客户或搜索任何文档。
获取规格。如果不存在，请写下。不值得去问别人，好像它不存在一样，那么当你处于其他人不在乎的时候。因此只有自己编写的方法（以后会更容易引用它）。
获取设计。不存在-写出来。尽量引用任何文档和源代码。
将详细设计写入需要更改的部分。
定义测试方式。因此，您可以确保新旧代码以相同的方式工作。
使系统可以一步构建。并使用旧代码进行测试。如果尚未将其放入SVC。
实现更改。不早
一个月左右后进行验证，没有发现任何问题。昨天已经完成”。在完成几个项目之后，他甚至可能开始帮助提前获取规格和文档。

但是通常（尤其是脚本）在业务范围内是不可能的（成本太高，而价值却很低）。一种选择是不进行任何更改，直到达到临界质量并且系统停止生产（例如将要使用新系统）或管理层认为所有这些都值得做。

PS：我记得一个代码，用于5个具有不同设置的客户端。而且，每项更改（新功能）都需要考虑“使用了哪些部件”和“配置客户端具有的配置”，以免制止任何事情，也不复制粘贴代码。将其设置用于项目cvs并编写规范，可以将这种思考时间几乎减少到0。

#18 楼

打印出源代码并开始阅读。如果它特别大，请仅打印出其中的部分内容，以更好地理解它，并根据需要进行许多注释/注释。

从程序的执行开始就跟踪该程序。如果您被分配给代码库的特定部分，请跟踪该部分中的执行并找出使用了哪些数据结构。

如果您使用的是面向对象的语言，请尝试使一般的类图。这将为您提供一个很好的高级概述。不幸的是，最后，您将必须阅读尽可能多的代码。如果您很幸运，以前的程序员已经写了尽可能多的文档，以帮助您了解发生了什么。

#19 楼

学习新的代码库时，您要做的第一件事就是了解它应该做什么，如何使用以及如何使用。然后，开始查看体系结构文档，以了解代码的布局方式，同时还查看数据库的方式。同时，您正在学习该体系结构，这是回顾任何流程或用例文档的好时机。然后，在了解了全局之后，开始研究并阅读代码，但是只有与您可能在该代码上进行的任何工作相关的代码，而不仅仅是尝试阅读所有代码。了解代码在何处执行X比确切地完成X更为重要，代码始终会告诉您如何找到它。

我发现只是想跳进去并且除了学习代码之外没有目标就读代码通常是徒劳的，尝试自己做一些小的更改或查看别人的更改的代码会更有效地利用您的时间。

#20 楼

如果代码量很大，则将注意力集中在当前正在处理的部分上。否则您会感到不知所措，并且可能会爆炸。我认为一些高级概述会有所帮助（如果可用），但是您可能会在调试器中花费大量时间来遵循以下程序流程。了解应用程序的概述并查看其使用是一个好主意，这样您就可以了解代码的使用方式/用途/原因。在代码上告诉我问题区域在哪里。得分高的区域可能很难更新。例如，我遇到了一个在圈尺度上得分为450的函数。果然有数百个IF。很难维护或更改它。因此，请为最坏的情况做好准备。

此外，不要害怕向现有开发人员提出问题，尤其是如果他们在系统上工作。保持自己的内在思想，专注于解决问题。避免发表可能会使其他开发人员感到沮丧的评论。毕竟，这可能是您的孩子，没有人喜欢被告知他们的孩子丑陋。提出程序代码流很有帮助，因此，如果我进行更改，则可以进行依赖项搜索以查看哪些方法/函数调用了什么。假设我要更改方法C。

如果只有1个方法/函数调用C，那么这是一个相当安全的更改。如果100的方法/函数调用C，那么它将产生更大的影响。如果是这样，将需要一些时间来理解它，但最终潮流将被扭转。

#21 楼

我要做的一些事情...

1）使用诸如Source Monitor之类的源分析工具来确定各种模块大小，复杂性指标等。

2）在Eclipse中从上至下钻取代码（有一个可以浏览引用的编辑器等很好），直到我了解正在发生的事情以及其中的位置代码库。

3）有时，我在Visio中绘制图以更好地了解体系结构。这对项目中的其他人也可能有帮助。

#22 楼

这经常发生。直到我开始在开源平台上工作之前，我认为我从来没有开始过以承认代码有一些“怪癖”开始的工作。一步调试器和许多坚韧不拔的道路。不幸的是，学习一个特定的大泥球经常需要时间和经验，即使多年之后，仍然会有一些子系统出现，没人知道。

#23 楼

我建议您在更改任何内容之前编写单元测试。并且一次只更改足够的代码以使测试通过。重构时，请事先添加单元测试，以使您知道重构并不会破坏业务功能。

对编程是一种选择吗？让另一个人反弹想法是应对这种令人讨厌的好主意。

#24 楼

这是我们用于消除重复项的过程。


为重复项选择一个标准的注释前缀（我们在注释标记后面使用[dupe]；
与您的团队撰写有关名称的规范用于重复的过程；
第一轮：每个人都取一些文件，并在重复的过程之前添加[dupe][procedure_arbitrary_name]；
第二轮：每个人都取一个过程或过程的子集，并分配一个值来指示不同目的的实现的相似性排序（字符串将为：[dupe][procedure_arbitrary_name][n]）；
第三轮：负责每个过程的程序将其重写到相关的类中；

#25 楼

我认为最重要的事情之一就是采用一个简单的功能，选择您能想到的最简单的功能，然后实施它。如果有一个已维护的愿望清单，请使用该清单，否则请与熟悉代码库的人交谈，并请他们提出功能建议。通常我希望这是5〜20 LOC的变化。重要的一点不是您要添加一个非常漂亮的功能，而是要使用代码库（或努力解决:)）并遍历整个工作流程。您必须


阅读代码以了解要修改的组件
更改代码并了解其如何影响周围的系统。
测试更改并因此进行确定组件之间的交互方式
编写测试用例并希望破坏一个或两个测试用例，以便您可以修复它们并了解系统的不变性。
构建事物或查看CI构建然后将其发货

清单继续进行，但要点是，像这样的小型项目将带您遍历清单中的所有项目，以熟悉系统，还可以进行有效的更改正在完成。

#26 楼

我想补充一点：

我最近开始使用的针对此类问题的一种工具（已极大帮助）是思维导图。我不会试图在脑海中塞满如何实现某事的所有细节，而是构建一个思维导图来描述我正在经历的系统如何工作。它确实可以帮助我更深入地了解正在发生的事情以及我仍然需要弄清楚的事情。它还可以帮助我以非常精确的比例跟踪需要更改的内容。

我建议在众多思维导图选择中使用自由平面。

#27 楼

没有文档，或者文档很少，或者已经过时。查找确实存在的所有文档。如果在团队存储库中，请不要进行复制。如果没有，请将其放到那里，并征询您的经理的许可，以组织它，也许要在一些监督下进行。所有基地都有行话；将其记录在词汇表中。制作有关工具，产品，特定于客户的等部分。

创建/更新软件环境创建文档。所有工具，古怪之处，安装选项等都请移至此处。

然后上传“ ProductName”入门文档或类似文件。让它随时间流逝并随着时间的流逝而自我组织。然后浏览过时的文档，并使其恢复最新状态。其他开发人员将不胜感激，您将在学习代码的同时以独特的方式做出贡献。尤其要记录所有使您难堪或被错误称呼或违反直觉的事物。

一旦您的学习曲线走到尽头，不必担心会更新文档。让下一个新家伙来做。当他到达时，将他指向您的工作。当他不断困扰您寻找答案时，请不要回答他。而是将问题添加到您的文档中，然后将其交给他。钓鱼竿。

副作用是，您将自己制作一个可以在几个月后忘记的情况下可以参考的工具。问题是您的队友所做的所有古怪的，人工密集的过程。使用批处理，sql脚本等自动化它们，并共享它们。毕竟，就在新环境中产生生产力而言，过程知识可以说与声明性知识一样大。不管是什么，都不要这样做。而是编写脚本，然后运行脚本。钓鱼竿再次击中。

#28 楼

我在这个主题上写了一篇很长的文章。这是摘录

我考虑了很长时间。我决定编写自己的个人解决方案作为一般过程。我记录的步骤如下：


创建词汇表
学习应用程序
浏览可用的文档
进行假设
定位第三派对库
分析代码

此过程是在大型桌面应用程序的上下文中编写的，但是常规技术仍然适用于Web应用程序和较小的模块。

来自：学习新代码库的过程

#29 楼

我可以分享一些小技巧。

对于现有产品，我将开始进行密集测试。如果选择了分配任务，我将重点关注特定功能。


下一步将是找到我可以插入并开始探索的代码

下一步将创建具有职责的简单类图（如CRC卡）
开始进行细微更改或占用较小的bug进行修复和承诺。这样我们就可以了解项目的工作流程；不只是代码。大型产品通常会为了授权和审核（例如医疗保健项目）而进行某种形式的记账。表达您的想法，想法，作为回报，他们可以长期从事该项目，并获得他们的经验和看法。这非常重要，因为这也可以帮助您与团队融洽相处。

#30 楼

自从我不得不深入研究大型代码库以来，已经有很长时间了。但是在最近几年中，我多次尝试让新开发人员加入具有现有的，相当大的代码库的团队。恕我直言，最有效的方法是配对编程。

在过去的12个月中，我们团队共有4个新成员，每次，新成员都会与另一个成员很好地配对熟悉代码库。一开始，年龄较大的团队成员将拥有键盘。大约30分钟后，我们会将键盘传递给新成员，新成员将在较早的团队成员的指导下工作。