0

我最近成为了一个复杂的嵌入式项目团队的一员，我将为其开发一部分。对于我负责的部分，只有旧代码，没有太多文档。

我渴望有一个好的开始，但害羞和害怕显得愚蠢使我很难提出问题。如何提问？

我想问一下你们用什么技术来理解一个项目？我的意思是有很多技术细节必须记住并保持在上下文中才能进行设计。您阅读了代码并获得了一些事实，但如何继续前进？例如，您阅读代码和文档并获得一些事实 A 和事实 B 。如何得出合适的结论 X，您可能需要也可能不需要考虑事实 C 和 D？

4

5 回答 5

1

如果没有足够的文档并且代码的文档记录和编写不佳，那么阅读代码可能会特别困难。我想现在最好的办法就是找到代码的入口点，慢慢了解它的流程以及它使用了什么数据。我会留意的

  1. 结构 - 实体/系统是否有任何分区？它们在代码中的什么位置（以及如何）相互通信？

  2. 数据 - 使用什么样的结构来保存全局数据？如何访问和保存数据？

  3. 如果您正在使用 C 或 C++，那么了解如何处理内存以及对于 C++（以及其他相关的非托管内存 OOP 语言，我猜）如何包含对象所有权也很重要。

  4. 既然是嵌入式项目，是否使用了非标准代码或编码结构？

于 2010-03-10T11:16:56.077 回答
0

通过编写文档来平衡阅读代码。

写下你的替代品需要的文件。想象一个比你知道得少的人。为那个人解释。

当您无法向您的替代者解释某些事情时，请提出问题。

当你有一个完整的描述时，你就会“了解”这个系统。

您将制作完整的文档。

于 2010-03-10T11:14:27.563 回答
0

你没有提到存在什么样的测试。如果有测试用例，修改它们并跟踪这将如何影响最终结果。

于 2010-03-10T11:17:39.477 回答
0

您可能希望查看给出系统逻辑结构的完整图片的图表，例如，查看 OOP 系统中的类图会很有帮助。查看大型复杂应用程序的设计图可以让您清楚地了解系统的内部模块是如何组织的，这样就可以更轻松地确定特定代码片段的功能。在没有图表的情况下，您最好从应用程序的入口点开始，例如 main() 并从那里开始，同时绘制（字面意思是在纸上绘制或写下）您自己对系统的结论（这样您就可以拥有自己的文档）并询问您的同行是否正确。

于 2010-03-10T11:40:15.133 回答
0

我的经验是，最好从某种任务开始——修复错误或其他小的更改。这将为您的学习提供重点。如果没有办法应用它，我发现很难通读活页夹或筛选源代码或文档页面。

如果您有一个沙箱，您可以在其中进行更改而不会弄乱代码库，那会更有帮助。

于 2010-03-10T14:06:26.227 回答