当我们开始从事真实的软件项目时，您将加入的团队很可能将拥有现有的源代码，而不是从头开始一个项目。
每个源代码都具有自己的一套技术，模式，实践和策略，这就是我们遇到这样一个问题的原因，即不知道从哪里开始或如何理解该代码在做什么，特别是如果它是大量的源代码。
通常，文档将不可用，如果可用，则文档可能已过时或在整个项目中未完全遵循或未实现的高级设计。
您拥有的唯一实际且真正可靠的文档是代码本身，以及编写该代码的人员（如果还存在的话），而其他所有信息充其量只有50:50的机会。
因此，如果您发现自己处在这种情况下，该怎么做才能理解您正在从事的项目？ 您如何才能最大程度地减少学习曲线并最大化对项目的贡献？
在过去的15年中，我学到了一些东西，我认为在以下情况下可能会使您受益：
域优先（大盒子）
您应该做的第一件事是花费大部分时间来了解业务正在试图通过该软件实现的目标。 牢记此概述将极大地帮助您。
了解域将帮助您确定代码的最终目标，这将极大地帮助您确定哪些现有代码可以保留，以及从高层角度可以彻底删除哪些代码。 这在降低代码的复杂性方面应发挥重要作用，并使它更易于理解。
了解域将有助于您对代码进行区域化，也就是说，能够将较大的代码区域视为可以移动的大块，并查看每个区域之间的关系。
建筑（乐高积木）
除了对领域的了解之外，您还应该将大部分精力集中在查看代码遵循的流程上以实现其目标。
从体系结构的角度来看，某些源代码比其他源代码更难理解，尤其是在体系结构不是很熟悉或不常见的情况下。 最好的选择是找到最初设计该软件的架构师，以从最初的意图中学到东西。
了解该体系结构将极大地帮助您了解代码遵循其原始设计的位置以及代码偏离正常目标的位置以完成某项工作。
能够查看代码在何处违反了其高级设计，这将帮助您看到实际上遵循规则的代码组件之间的凝聚力，甚至可以使您更好地了解如何带回非设计组件纳入原始设计，最终将有助于提高源代码和整个项目的质量。
分配时间来重构和重建“正常工作”的现有组件是一个完全不同的主题，我在另一篇文章中已经讨论过。
模式（小乐高积木）
编写软件的方式有很多不同，包括创造式，结构式，行为式和其他方式。
了解代码正在或试图遵循的模式将帮助您在类到类级别上了解如何在代码中构建功能。
这将帮助您按照一致同意的模式编写具有凝聚力的代码，最终将导致更少的代码审阅注释，以及更快的交付功能和解决缺陷的能力。
它还将帮助您再次查看违反这些模式的代码部分，因此您将了解哪些是为了保持一致性，而哪些是为了重构而哭泣。
编码准则（精巧）
在大多数团队中，您可能会遇到编码准则，这是团队同意遵循的一组规则，以创建易于阅读和理解的具有凝聚力的类级代码。
如果要加入的团队没有标准的编码指南，则应参考所用编程语言的通用编码指南，并确保团队中的每个人都在同一页面上。
从低层次的角度来看，可读的内聚代码在您了解事物的发展方向时起着很大的作用。
有人可能会问，我们从哪里可以获得有关领域，体系结构，模式和指南的所有信息？
您可以遵循的方法很少，我建议您对这些方法进行多样化处理，以使您获得了解某个项目所需的所有信息：
1.查找所有可能的文档（即使文档已过时），并围绕团队用来引用系统中某些功能的常用术语，缩写和概念建立知识库。
2.建立知识库后，您现在可以与计划经理进行交流，并让他们参与有关软件从业务角度来看要做什么的领域讨论。
3.与架构师和团队负责人就软件遵循的高级架构进行沟通。 然后阅读或观看有关该体系结构及其最佳实践的尽可能多的教程，然后讨论您认为违反标准体系结构的内容，以更好地了解系统的设计方式。
4.确保与团队中的开发人员和工程师进行交流，以了解遵循了哪些模式以及实施了哪些编码准则以维护代码，然后再次返回以研究这些模式并进行比较以找到最适合的模式遵循模式并执行准则。
5.开始进行一些清理工作，并修复潜在的缺陷，以便在代码级别上有更深入的了解，以深刻理解团队如何通过代码审查传达他们的想法，并充分理解他们为更好的清理工作程序所提出的建议。
重构始终是让团队参与讨论最佳实践，应重新审视哪些准则以及应执行哪些其他准则的绝好机会。
6.与团队共享您的发现和文档，将其收集在会议中，并继续让他们参与有关业务，体系结构，模式和代码本身的建设性讨论。 定期执行此操作不仅可以帮助您提高知识，而且可以在整个团队中提高知识水平，因为尽管团队成员已经存在了一段时间，但总会有不为人知的一件事。
遵循这些步骤不仅可以帮助您了解正在使用的新代码，而且还是向自己的新团队介绍自己，向他们学习和与他们合作并为他们努力取得更高成功的最好方法。
在某些情况下，您会遇到障碍，难以与他们沟通的人，可能会阻碍您了解系统的工作安全问题，在这种情况下，我能给您的最佳建议是尝试寻找其他机会去你想去的地方。
如果没有门，则继续创建一扇门。 不要太早放弃，并且要知道，恢复一个垂死的系统比为一个完美设计的系统工作会带来更多的经验。
