我不知道，有人告诉我，以前的开发人员在学习并直接进入编码方面做得很好，没有什么大问题。我想知道我是否做错了，我要求我的经理在这里与一些高级程序员进行一些简短的会议。是谨慎地完成这个时间敏感的跟踪器，还是赶在最后期限前完成？
顺便说一句，以前维护这个应用程序的程序员都在公司不到一年就走了。不知道有没有什么关系。
【问题讨论】：
标签： maintenance codebase
一年前有一个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：Michael 的 Working Effectively with Legacy Code Diomidis Spinellis 的羽毛和 Code Reading: The Open Source Perspective。
我个人推荐阅读The P.G. Wodehouse Method Of Refactoring；如果没有的话，它至少是一个有趣的阅读！
【讨论】：
阅读单元测试。没有单元测试？编写一些单元测试。
【讨论】：
你看到this question了吗？
一致的答案似乎是：
潜入并修复错误。选择一个仅限于代码库的一小部分。经常使用调试器。
【讨论】：
我做过几份类似的工作，所有程序员都离开了公司。我称之为红旗。
该项目没有文档可能并非巧合，但很难判断其中是否存在因果关系。真相可能是以下任何一种：
熟悉代码的最好方法可能是编写测试。为自己设置一个生成代码覆盖率报告的单元测试工具。编写运行所有代码的测试。代码覆盖可视化可帮助您发现尚未练习的边缘情况。当你经历这个过程时，我保证你会学到很多关于代码是如何工作的。作为附带的好处，您将生成一个完整的单元测试套件。
其他人已经提到，获取生成 API 文档的工具是另一种选择。此类文档仅供参考。它对于向您展示如何或何时最好使用给定的类或方法没有用处。
另一个练习是为系统的各个部分构建 UML 图。即使代码的面向对象架构存在缺陷，sequence diagram 也很有用。
【讨论】：
我会说有很多测试，如果他们设置了某种单元测试框架，那么你很好，如果没有，那么你可能想要开始一个。因为几乎没有什么比在你试图修复另一件事时破坏某件事更令人沮丧的了。
作为参考，你可能想看看这个，这个家伙似乎比你更紧张：
【讨论】：
哪种编程语言？代码库有多大（1k、10k、100k 行？）
无论如何，我建议使用Doxygen 创建易于浏览的 HTML 交叉引用。
【讨论】：
如果它足够小（比如 10,000 行或更少），我已经在老式列表方面取得了相当程度的成功。打印出代码，拿一些荧光笔和那些彩色的便利贴，然后查看清单、涂鸦笔记、查找参考资料并拼凑整体结构。去一个安静的地方做这件事，然后花时间检查代码。
如果它是用可以使用 ctags 或类似的东西编写的，请带上笔记本电脑，以便搜索代码。
【讨论】：
我总是做的第一件事（在 VisualStudio 中）是为解决方案中的每个项目创建一个类图。这让我可以看到我正在使用的图形表示。
出于某种原因，我只是带着黄色的便笺簿完成了主要课程，并记下了关于什么与什么对话的笔记。这似乎对我有用。真的不知道为什么，或者为什么它比仅仅阅读代码更好。
另外，如果有一些令人困惑的代码，您不知道它应该如何工作，那么请通过调试器运行它并单步执行它。我总是尽量保持调用堆栈可见，以便了解不同的代码路径。
最后一件事（这可能不是每个人都会想到的）是通过分析器运行它。您不一定要寻找性能数据，但您对捕获的代码路径感兴趣。它实际上对于查看运行时实际发生的情况非常有用。
【讨论】：