我最近继承了一个大型代码库，并且不得不阅读它。问题是，我通常是开始一个项目的开发人员。结果，我没有太多阅读代码的经验。
我对不得不阅读大量代码的反应是，嗯，重写它。但我需要让自己快速上手，并在现有系统的基础上进行构建。
其他人是否有他们学到的吸收代码库的技术？在这一点上，我只是在阅读代码。我尝试使用 UModel 生成 UML 图。它们太大了，打印不干净，当我放大时，我真的失去了看到所有关系的视角。
其他人是如何处理这个问题的？
问问题
909 次
4 回答
1
哇——我刚刚听完一个关于阅读代码的播客！！！
我会推荐听这个。一个有趣的观点是我发现激进并且可能是你可以尝试的东西（我知道我要去！）。下载整个源代码库。开始编辑和重构代码然后...扔掉那个版本！！！我认为，我们对截止日期提出的所有要求，对于大多数开发人员来说甚至都不会发生。
在我自己的工作中，我的处境与您相似，我发现以下内容对我有用： - 在现有代码上编写测试用例。为了能够编写测试用例，您需要能够理解 cde 基础。- 如果可用，请查看在产品生命周期中记录的错误\问题，并查看它们是如何解决的。- 尝试重构一些代码——你可能会破坏它，但没关系，你可以把它扔掉重新开始。通过将代码分解成更小的问题，你会更好地理解它
不过，在重构时您不需要进行大刀阔斧的更改。当您阅读代码并理解某些内容时，请重命名变量或方法名称，以便更好地反映试图解决的问题。
哦，如果可以的话，请获取 Michael C. Feathers 的《有效地使用遗留代码》的副本——我认为你会发现它在你的情况下非常宝贵。
祝你好运！
于 2010-05-05T23:50:04.510 回答
0
一般来说，我从代码的入口点（主函数、插件钩子等）开始，并完成基本的执行流程。如果它是一个体面的代码库，它应该被分解成体面大小的块，然后你可以通过并找出每个代码块负责什么。回顾系统执行流程中的调用时间。
对于包/模块/类的探索，我使用在源代码上运行后会生成的任何doxygen 。它会生成一些不错的类关系图、继承层次结构和文件依赖关系图。这样做的好处是它们每个都专注于一个类以及它如何与它的邻居、兄弟姐妹和父母联系起来，因此这些图表通常具有可管理的大小并且易于理解。
当您了解不同的类、函数和子系统时，我喜欢添加注释来填补听起来明显缺少文档的内容。当您第二次重新阅读代码时，这会有所帮助。
于 2010-05-05T23:48:31.300 回答
0
我会推荐另一个播客和资源： 软件考古学 SE-Radion 插曲
于 2010-05-06T10:45:06.610 回答
0
这篇文章提供了一个指南
可视化：应用程序设计的可视化表示。
设计违规：了解对象模型的健康状况。
风格违规：了解代码当前所处的状态。
业务逻辑审查：测试现有资源的能力。
性能回顾：源代码的瓶颈在哪里？
文档：代码是否有足够的文档让人们了解他们正在做什么？
于 2012-01-18T12:08:01.640 回答