了解软件系统
我最近成为一个复杂的嵌入式项目团队的一员，我将为该团队开发一部分。对于我负责的部分，只有旧代码，没有太多文档。
我渴望有一个好的开始，但害羞和害怕显得愚蠢让我很难提出问题。如何提问？
我想问一下你们用什么技术来理解一个项目？我的意思是，为了进行设计，人们必须记住许多技术细节并将其与上下文联系起来。您阅读了代码并了解了一些事实，但是如何继续前进？ 例如，您阅读代码和文档并获得一些事实 A 和事实 B 。如何得出合适的结论 X（您可能需要也可能不需要考虑事实 C 和 D）？
I recently became part of a complex embedded project team for which I will be developing a part. For the part which is my responsibility there is only old code and not much documentation.
I am keen to make a good start but shyness and fear of appearing stupid makes it difficult to ask questions. How to ask questions ?
I wanted to ask what techniques do you guys use to understand a project ? I mean there are of lots of technical details which one must remember and keep in context in order to make a design. Your read the code and get some facts but how to move ahead ?
For instance you read the code and the document(s) and get some facts A and fact B . How to reach suitable conclusion X for which you may or may not have needed to take into account facts C and D also ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果没有足够的文档并且代码文档记录不充分并且编写得不好，那么代码阅读可能会特别困难。我想现在最好的办法就是找到代码的入口点，慢慢了解它的流程和使用的数据。我会密切关注
结构 - 是否有实体/系统的分区？它们在代码中的何处（以及如何）相互通信？
数据 - 使用什么类型的结构来保存全局数据？如何访问和保存数据？
如果您正在使用 C 或 C++，了解内存的处理方式以及 C++（我猜还有其他相关的非托管内存 OOP 语言）如何包含对象所有权也很重要。
既然是嵌入式项目，是否使用了任何非标准代码或编码结构？
Code-reading can be particularly difficult if there is not enough documentation and the code is poorly documented and badly written. I guess the best way now is to find the entry point of the code, and slowly understand its flows and what data it uses. I would keep a look out for
Structure - are there any partitioning of entities/system? Where in the code (and how) do they communicate with each other?
Data - what sort of structures are used to hold the global data? How are the data accessed and saved?
If you are doing C or C++, it is also important to find out how memory is handled and for C++ (and other related non-managed memory OOP languages, I guess), how are object ownership contained.
Since it is an embedded project, are there any non-standard code or coding constructs used?
通过编写文档来平衡阅读代码。
写下您的替代者需要的文件。想象一下一个比你懂得更少的人。给那个人解释一下。
当您无法向继任者解释某些事情时，请提出问题。
当你有了完整的描述，你就会“了解”这个系统。
您将生成完整的文档。
Reading the code is balanced by writing the documentation.
Write the documentation that your replacement will need. Imagine someone who knows less than you. Explain it for that person.
When you cannot explain something to your replacement, ask questions.
When you have a complete description, you will "know" the system.
And you will have produced complete documentation.
你没有提到存在什么样的测试。如果有测试用例，请修改它们并跟踪这将如何影响最终结果。
You don't mention what kind of tests exist. If there are test cases, modify them and trace how this would affect the end result.
您可能想要查看提供系统逻辑结构全貌的图表，例如，查看 OOP 系统中的类图将会有很大帮助。查看大型复杂应用程序的设计图可以让您清楚地了解系统的内部模块是如何组织的，这样就可以更轻松地弄清楚特定代码段的功能。在没有图表的情况下，最好的选择是从应用程序的入口点开始，例如 main() ，然后在绘制（字面意思是在纸上绘制或写下）您自己关于系统的结论时从那里开始（这样你就可以拥有自己的文档）并询问你的同事他们是否正确。
You might want to look at diagrams which give the entire picture of the logical structure of the system, like, for example, looking at class diagrams in an OOP system would be of great help. Looking at the design diagrams of large and complex apps gives you a clear understanding of how the internal modules of the system are organized and this way its makes the task of figuring out what functionality does a particular piece of code does much much easier. In the absence of diagrams, you're best bet would be to start from the entry point of the app, like main() and proceed from there while you draw(literally draw or write down on paper) your own conclusions about the system(this way you can have your own documentation) and ask your peers if they're correct.
我的经验是，最好从某种任务开始——错误修复或其他小的改变。这将为您的学习提供重点。我发现如果没有办法应用它，很难阅读活页夹或筛选源代码或文档页面。
如果您有一个沙箱，您可以在其中进行更改而不会弄乱代码库，那么这会更有帮助。
My experience is that it's best to start with some kind of task -- a bug fix or other small change. That will provide focus to your learning. I find it hard to read through a binder or sift through pages of source code or documentation without having a way to apply it.
If you have a sandbox where you can play with changes that you've made without messing up the code base, that can be even more helpful.