我不知道，我被告知以前的开发人员在接受编码时没有遇到任何重大问题。我想知道我是否做错了，要求我的经理与这里的一些高级程序员进行一些简短的会谈。是否更加小心谨慎并完成这个时间敏感的追踪器，或者在截止日期前赶紧吃肉？
在旁注中，维护此应用程序的以前程序员在公司工作不到一年之后就已经消失了。不知道是否有任何关系。
答案 0 :(得分：10)
一年前有thread about this on Slashdot。在通常的Slashdot残骸中，有一些很好的答案;也许有人可以在这里提取它们。
一些好的是stepping through the program with a debugger，Doxygen（当然）（以及相关工具，如ctags / etags / GNU Global），giving up和a couple of books about exactly this topic： {{3 Michael Feathers和Diomidis Spinellis的 Working Effectively with Legacy Code 。。
我个人建议阅读Code Reading: The Open Source Perspective;如果没有，那至少是一个有趣的阅读！
答案 1 :(得分：5)
阅读单元测试。没有单元测试？写一些单元测试。
答案 2 :(得分：4)
您看到this question了吗？
那里的共识答案似乎是：
潜入并修复错误。选择一个仅限于代码库的一小部分。使用调试器很多。
答案 3 :(得分：3)
我有几个这样的工作，其中所有程序员离开了公司。我称之为红旗。
项目没有文件可能并非巧合，但很难判断那里是否存在因果关系。事实可能是以下任何一种情况：
熟悉代码的最佳方法可能是编写测试。使用可生成代码覆盖率报告的单元测试工具为您自己设置。编写运行所有代码的测试。代码覆盖可视化可帮助您发现尚未执行的边缘情况。在您完成此过程时，我保证您将学习很多有关代码如何工作的知识。作为附带好处，您将生成一个完整的单元测试套件。
另一个人提到，获取生成API文档的工具是另一种选择。这种文档仅供参考。这对于向您显示 best 如何或何时使用给定的类或方法没有用。
另一个练习是为系统的各个部分构建UML图。即使代码的面向对象架构存在缺陷，sequence diagram也很有用。
答案 4 :(得分：2)
我会说经过大量的测试，如果他们设置了某种单元测试框架，那么你很好，如果没有，那么你可能想要启动一个。因为当你试图修复另一件事时，几乎没有什么比打破某些东西更令人沮丧的了。
作为参考你可能想看看这个，这个家伙似乎比你更紧张：
答案 5 :(得分：1)
哪种编程语言？代码库有多大（1k，10k，100k行？）
无论如何，我建议使用Doxygen创建易于浏览的HTML交叉引用。
答案 6 :(得分：1)
如果它足够小，可以做到这一点（比如10,000行或更少），我已经在很好的老式床单上取得了相当程度的成功。打印出代码，获得一些荧光笔和那些彩色的便利贴标志，然后查看清单，涂写笔记，查找参考资料并将整体结构拼凑在一起。去一个安静的地方去做，只是花时间来检查代码。
如果它是用某些东西写的，你可以使用ctags或类似的东西，拿一台笔记本电脑，这样你就可以搜索代码。
答案 7 :(得分：1)
我经常做的第一件事（在VisualStudio中）是在解决方案中创建每个项目的类图。这让我看到了我正在使用的图形表示。
出于某种原因，我只是通过一个黄色的法律垫片来阅读主要课程，然后记下关于什么谈话的笔记。这似乎对我有用。不知道为什么，或者为什么它只是阅读代码更好。
此外，如果有令人困惑的代码，你不知道它应该如何工作，那么通过调试器运行它并逐步执行它。我总是试图保持调用堆栈可见，这样我就可以了解不同的代码路径。
最后一件事（这可能不会发生在每个人身上）是通过分析器运行的。您不一定要查找性能数字，但您对捕获的代码路径感兴趣。它实际上对于查看运行时实际发生的情况非常有用。