在尝试理解新软件时您寻找的东西

Question

我想知道当你开始研究一个现有的系统时，你会寻找什么样的东西？假设系统非常大（无论对你来说意味着什么）。

确定的一些事项是：

1. 调用特定子例程或过程在哪里？
2. 特定功能的参数，结果和谓词是什么？
3. 控制流程如何到达特定位置？
4. 特定变量集，使用或查询的位置在哪里？
5. 声明的特定变量在哪里？
6. 访问（即创建，读取，更新或删除）特定数据对象在哪里？
7. 特定模块的输入和输出是什么？

但如果您寻找更具体的内容或任何上述问题对您来说特别重要，请与我们分享：）

我对可以在动态分析/执行中提取的内容特别感兴趣。

Answer 1

我喜欢使用“用例”方法：

1. 首先，我问自己“这个软件的用途是什么？”：我试图确定用户如何与应用程序进行交互;
2. 一旦我有了一些“用例”，我就会尝试了解更多涉及的对象以及它们与其他对象的交互方式。

一旦我这样做，我绘制了一个UML类型的图表，描述了我刚刚学到的内容以供进一步参考。之后会发生什么取决于我已经分配的任务，即修改代码，记录代码等。

Answer 2

我有什么动机来学习新系统：

1. 错误修复/次要增强 - 在这种情况下，我可能只关注执行需要更改的特定功能的系统部分。这是一种打破庞大系统的方法，但也是一种识别问题是否可以修复的方法，或者是否是我必须交给我们正在使用的软件的现成公司的方法，例如。 CRM，CMS或ERP系统可以是定制的现成系统，因此有很多部分。

2. 项目工作 - 这是另一种情况，我可能会尝试在30,000英尺左右建立自己的视图，以了解什么是高级组件以及系统的哪些区域项目影响。这方面的一个例子是我加入一家公司并从现有代码库中解脱出来，但我没有像前一个案例那样拥有小焦点的奢侈品。该视图的一部分是在命名约定，项目结构等方面查找代码中的任何模式，因为一旦我开始更改系统中的某些代码，这可能很有用。我可能会对系统进行一些跟踪，并试着看看代码中哪些部分更加丑陋。丑陋的意思是那些像kludge一样的部分可能有一些意大利面条代码，因为这在第一次写作时很匆忙，现在正在重新加工。

在我看来，另一种看待这个问题的方法是我是否要花费数天或数周的时间来围绕像第二种情况那样的系统，或者这应该是一个希望只需要几个的情况小时，乐观地说，是为了让我的立足点做出必要的改变。