Answers:
我从代码开始。单独的设计文档（如果有的话）很可能是错误的或被误解的。因此，我首先尝试通过代码跟踪一些简单的流程；例如，如果是Web应用程序，则可以是一个请求或一系列请求。完成此操作后，我便有了一种骨架，可以多加理解。然后，我可能会回去阅读设计或其他文档，但是到那时，我有一些具体的东西可以将它们关联到并进行验证，以便可以检测到Duff信息。或者我可能只是继续阅读代码或测试用例等。
我首先建立一个开发人员系统。我使用记录的程序。这可以让猫从书包中脱颖而出，了解有多少文件与现实同步。
它还告诉我什么是依赖项。这很重要。
现在，我已经完成了开发人员的设置，（并且我在进行更正时将设置文档标记为正确的内容），现在可以构建一个版本。在这个阶段中，我最终都会提出问题。
现在它已经构建好了，我将根据用户手册进行介绍性练习。这大致告诉了我系统的实际功能。
现在，我对系统有了部分线索，我阅读了设计文档，而我相信这些文档与到目前为止文档的错误程度成正比。
一旦获得了实际的行为文档，我就可以开始研究代码并查看其中的实际内容。他们从来没有排队，但我现在知道有多少要相信。
然后，查看IDE输出的“ todo”和“ fixme”注释。像“ 2.0版中的修复”之类的东西也是小费。
因此，所有这些都是关于学习准确性的，并且正如人们指出的那样，单独的设计文档很少是最新的或正确的，但是它确实告诉您人们在某个时间点的想法。当然，这些人可能不在周围询问。
对于复杂的软件，我会大致将其视为新开发项目。从大的想法开始，即远见，背景，范围，利益相关者。通读一些用户文档，并了解其用法。如果可能（或适用），请对该软件进行一些用户培训。然后开始研究需求和设计文档，以大致了解其工作原理。与设计师保持联系。从不同的角度来看系统架构。从那里开始，深入研究核心功能并查看一些代码，然后根据需要返回需求和设计。在查看代码时，请运行软件以查看其运行情况。一直以来，请编译一些摘要文档以备将来参考-您拥有Cliffs Notes。进行分支，直到您对所有组件的工作方式和组合方式有了很好的了解，然后专注于将要使用的部分。到目前为止，您已经对整个系统或至少适用于您的部分有了从上到下的理解。
当然，在现实世界中，您可能没有时间在必须开始动手之前，特别是在大型项目上，没有时间去完成所有这些工作。但这是我该怎么做的。
您应该在代码本身和任何设计文档之间来回工作。
您可以从代码或设计开始，这并不重要。阅读代码，直到您完全感到真正的困惑为止，然后查看设计文档。或者，阅读设计文档以获取高级图片，然后查看代码以查看外观。只要您正在处理代码，就可以无限期地重复。
请注意，设计文档几乎总是过时的，并且在许多方面都不正确。但是，只要牢记这些要点，过时的文档仍然可以帮助您了解过去某个时候的作者的想法。许多高级问题和疑虑仍然有效，即使您对作者最初认为它将去向何处的日期都留有陈旧的印象，您也很可能能够更快地了解代码到达何处。走。
在研究代码和设计时，请创建自己的文档来描述您对当今代码的理解。也许这些文档只是一两个简单的草图，也许它们是Wiki中的文字，也许它们是其他东西。不要太复杂：没有30页的word文档。写下您的想法，这将大大阐明您自己的想法。
我从设计文档开始。尤其是规范-告诉人们所看事物的意图。
如果可能的话，我将查看设计说明和文档，以大致了解其完成方式，思考过程，有关人员的风格和性质。
然后，如果可能的话，我会与研究它的人交谈-它是做什么的？怎么样？为什么？尸体埋在哪里？
开发人员中有一种倾向使用代码：“让我向您展示此代码”。这对他们来说很好，但往往会劫持我的需求-这是为了理解高级内容，从而为低级内容提供上下文。
它使用大量的脑力，在完整的上下文中查看少量代码，并理解任何有意义的内容。因此，如果可能的话，让开发人员讨论原理，结构，单元，模块，无论什么都会引起对任务的赞赏。
只有这样，才值得尝试进入代码。
在大型方案中，查看代码就像查看一个充满0和1的页面。有含义，但要花很长时间才能弄清楚。了解外观以及有意义的部分有助于缩小搜索空间。
话虽如此，当没有doco，没有人，只有代码时，除了查看代码之外，别无所求。
在那种情况下，我通常不会尝试通过缓慢的深度阅读来理解它，而是快速浏览并略读所有内容。有时，这只是打开的文件，然后按向下翻页键。通过这样做，您可以对全局有一个惊人的欣赏。（在某些情况下，我什至将字符串可执行文件转储并拖曳它们，以寻找签名和模式。在过去的20多年中，这卓有成效。）
然后，我看一下开发人员的README，TODO和Changelog。如果我不明白为什么要编写软件，如何编写软件以及软件的去向……我不会使用它。
首先设计，然后编码，如果需要的话，请自上而下进行设计，因此我了解必须工作的每个层次的上下文。
但是，如果我必须做一个非常具体的更改，例如修复报告或计算，我就去看看代码。
更具体地说，我的“设计优先”方法是这样的：
我首先从de domain模型开始，如果没有，则至少建立一个基本模型（一个很好的起点是数据模型）。它定义了应用程序的“词汇表”以及对象（类）之间的关系。
它通过应用程序描绘“处理了哪些对象”。
然后，我寻找用例模型来找出应用程序“完成了哪些流程”，尽管我更喜欢一个流程图，如果该流程图是一个，则显示了流程序列。
在那之后，我应该对应用程序有一个很好的了解，然后就可以设计更改了。
顺便说一句，以上答案是在业务应用程序的上下文中。
代码没有说谎。首先了解项目概况，以了解什么是个好主意它。但是，如果您的任务是要详细了解项目的工作原理，那么至少对于我来说，看代码就像逐块看拼图一样，只是您要看的每个类都在添加另一个一块拼图。如果代码结构合理，您甚至可以在不调查类功能的情况下看到由类名称形成的模式。在许多情况下，您可以从代码中获得提示和线索，这将进一步为您提供帮助。
最后，您将了解程序的功能，这是一个完整的拼图游戏。文档可能不完整或不准确，但是代码永远不会说谎。您可以完成所有这些操作而无需弄清楚每种方法的作用。并非每个人都可以通过这种方式了解项目，但是如果您经常这样做，对您来说会变得更容易，更不用说您可以在几个小时的学习中获得中型应用程序的要旨。虽然我认为这一切都归结为偏好。
在看到最关键的模块/应用程序点的代码之后：看到代码，我可以验证设计的优点。
例：
您必须从事有关财务报告的Web应用程序的应用程序管理。
在我阅读了有关消息的代码，启动和结束应用程序（用于db中可能的锁定），创建数据的主过程（必须报告的内容）等之后（例如，在储气中，主过程与计算具有供应和注入的客户存储区域中的天然气存量；第二步是关于先前计算出的该数据的账单）