如何在具有历史意义的项目上生活和发展。是什么使开发人员有使用大型代码库的经验，以及为何即使您确实愿意，也无需尝试从头开始重写所有内容。
内容
我是Pavel Novikov，我参与了移动应用程序“ MyOffice Documents”和“ MyOffice Mail”的开发。这是一个用于与文档和电子邮件客户端进行协作的应用程序，该应用程序于2013年开始创建，因此可以称为具有大型代码库的项目，其中包含遗留物。
这里描述的经验不仅适用于移动应用程序，而且通常适用于应用程序开发。
小孩子的免责声明
在本文中，我根据迄今为止的经验收集了对自己工作的看法。任何此类文章始终都是高度主观的。我敢肯定有些人的经历与我的观察相矛盾。我很乐意在评论中讨论这些差异。
这是谁的文字
该文本适用于那些认为自己属于初级水平的人和属于中/高级类别的人。
在任何开发级别上使用长期项目都需要学习很多知识。要在理解级别上处于同一波长，请阅读Vastrika的帖子：Login和K-Team。我喜欢他对开发人员层的分类，将来我会坚持下去。
在下一个块中，我们将简要分析长期项目中每个级别的用途。
初级
初级开发人员的任务是最大程度地发展技术技能。一切都被使用：语言，框架，库，开发方法等。在拥有强大团队的任何项目中，您都可以学习解决不同的问题。
但是，对于成熟的项目，首先，您将有机会更深入地研究任何领域，其次，您将能够研究成功和不成功的决策的示例。向别人的错误学习是很昂贵的。特别是如果附近有经验丰富的同事可以向您详细解释这些错误的含义以及如何避免这些错误。
中间
中间开发人员的任务是增加自主权。您应该成为团队成员，该团队成员几乎可以信任项目上的任何任务。这意味着项目拥有的任务越多样化，您拥有的潜在增长领域就越多。
资深的
高级开发人员的工作是完全了解您不会因为代码而得到报酬，而是因为解决问题而得到报酬。有时（到目前为止，仍然更多）通过编写代码，有时通过管理其他开发人员，有时通过与非开发人员进行沟通来实现。成熟的项目只是可以而且应该解决的任务的仓库。
接下来，我将详细介绍可以从现有项目中学到的一些知识。
还有这里的遗产？
首先，您需要了解术语。“传统”的概念早在很早以前就已经有了负面含义，但是传统代码到底对什么有害呢？
R7K研究与传输公司的创始人Michael Feathers认为，遗留代码是测试未涵盖的代码。这种方法的优点是，乍一看，它声称是客观的。但实际上，可能有两种情况：
- 有测试，但是它们写得很差：混乱，脆弱，结构不清晰。
- 没有基准，但是代码设计得很好。这样就可以相对安全地进行更改，并且在这种情况下，您可以在将来快速编写测试。
再看看开发人员Dror Helper的遗产是什么：不再设计-不断打补丁并被黑客入侵。 ...
Web开发人员Nicolas Carlo认为遗留代码是不适合使用的代码。
从所有这些，我们可以得出结论，遗留是代码的主观特征。代码本身可能会起作用，也可能不会起作用，但是当开发人员出现而无法有效修改代码时，它将成为遗留的代码。
评估Legacy的另一个相对客观的特征是对以下问题的答案：“项目中是否存在不受支持的依赖项”。该代码只能由某些特定的过时编译器版本构建。或者作者自己修补了一些外部库，现在它已成为主要项目的一部分。实际上，在这种情况下，该项目变得很具体，需要更多的努力来支持它。
通常，如果该项目的成立时间超过六个月，则很可能会包含旧项目。
您可以从一个故事项目中学到什么？
因此，您做出了决定并在一家公司工作，而在那之前，您已经编写了代码，并且发生了许多其他事情。我要补充一点，您不需要去新地方即可升级您的个人资料。在每个项目中，最有可能出现遗留问题，您只需要知道如何对其进行评估即可。我所说的肯定可以应用于您现在正在研究的东西。
抽水在哪些领域对您和项目同样有用？在这里，您需要了解，在项目遭受伤害的地方进行开发的情况是相互成长的理想环境。因为如果您在一些左派工作上有所发展，那么这对您个人而言可能是一个加分项，但同时很难解释为什么公司应该为您提供帮助。
分析项目
您可以从遗产项目中学到的第一件事就是对其进行分析。假设您来到的项目中存在文档方面的空白，或者根本没有空白。在这种情况下，您将仅拥有项目的源代码，因此能够对其进行分析并快速了解其结构和本质至关重要。这很重要，因为您越早学会导航，您就越早开始受益于该项目。
为了更深入地了解项目分析，我可以建议的最重要的事情是阅读Michael Feathers的著作《使用遗留代码进行有效的工作》。她老而有名。它描述了使用遗留代码的大量实践。
另一个提示是访问“了解旧版法规”网站。... 这是一个致力于一个主题的博客-与遗留物打交道。您可以在那里订阅新闻通讯很重要。我敢肯定，许多Android开发人员都了解Android Weekly和Kotlin Weekly邮件。ULC通讯也非常有帮助。它不具有干扰性，提供有关重构和编码的操作方法文章。
重构
传统项目是练习重构技能的好地方。您来到一个最有可能出现问题的项目，不仅需要更改它，还需要改进，扩展和看到新功能。您重构的效率和效率（快速且几乎没有回归）将确定您对开发人员的有用和良好程度。
在具有健康工程文化的成熟项目中，重构应该是开发的持续过程。
您应该喜欢您正在开发的产品。如果您可以自己使用，那就太完美了。在这种情况下，您将有长期的动力去提高其质量。
设计和建造建筑
这一点是从前一个观点出发的-您将不可避免地需要进行软件设计和架构。有了正确的开发文化，您将不必在紧迫的期限内做出重大的架构决策。您将有时间设计体系结构，并且做好它是您的责任。我在这里总是推荐什么？看书。
我发现书籍与其他信息来源同样重要。您从书本中获得的经验越多，您就会越多，更快地了解如何解决常见问题。对于典型/典型问题，总会有典型的解决方案，可以在书中找到。处理任何遗留问题还涉及解决典型问题。
(Robert C Martin). « », « »
(Martin Fowler). «. »
UML — .
PlantUML (PUML) — , UML-. git, , .
当您使用不完全了解的产品时，您将需要学习如何评估要完成的工作。而且，您总会有一些您不知道的东西，有些陷阱。
将大型复杂任务分解为一组相互关联的小片段的能力是一项非常有价值的技能。开发它的一种方法是持续地回顾分解和估计误差。在分析过程中，您可以根据经常遇到的错误创建清单。将来，他将能够帮助您再次防止这些错误。
自动化并能够应用CI / CD
您需要了解从编写代码到到达用户设备的这段代码发生了什么。而且，您将能够自动进行CI和CD的定制，维护和改进。在没有专门的基础架构团队的公司中，这些操作可以并且应该（由我确信）由核心开发团队的成员决定。现代工具（云CI，Docker）并不是非常复杂，但是它们极大地简化了团队的生活。如果您掌握了这些技能，您将可以做很多事情。
交流
您承担的责任越多，与您沟通的人就越多。长期以来，软件开发已经不再是个人的工作了：几乎所有大型项目都是由团队完成的。同样，您越有效地与周围的人互动，您可以带来更多的好处。
您将必须与比您更聪明，经验更丰富的人交流。在大型项目中，总是有一些“老手”可以向他们学习很多。此外，您还会遇到比您笨的人。好消息是，您很可能在智力能力评估中错了-能够纠正这种感知错误非常有用。
我相信，发展沟通技巧可以减少为同理心。您越了解对方周围的人的动机和目标，就越能对他们有用。例如，在向企业解释重构和处理技术债务的好处时，应使用业务术语，而不是程序员术语。看似显而易见的主意，但我已经反复看到一些聪明人如何与其他聪明人进行交流并且彼此无法理解。
面试中要问什么问题
在这里，我将从我在进行一个我不太了解的项目之前会问什么问题开始。
工作流程如何工作以及确切为什么
通常，现在他们可以在Scrum或看板系统上工作。但与此同时，他们经常适应自己：“他们采取了最好的做法，而抛弃了不必要的做法。”问题是：他们到底扔了什么，他们留下了什么？因为构建开发过程所依据的Scrum指南具有一些非常有趣且有用的实践。
首先，有意识地应用它们，然后再进行所有应用，它们才有意义。因为它们构成了一个可自我控制的系统，使您不仅可以迭代地改善项目，而且还可以迭代地改善自己的流程。
例如，如果团队正在研究Scrum，我想问一下上次回顾中讨论了什么。团队在这次会议上有多活跃？提出的问题是否得到解决？
我对内部流程的另一个有趣的问题是：团队中的代码审查如何进行？是否有任何内部规则可以进行审核以减少审核时间？是否存在一个通用的知识库，在其中输入了各种错误的结果，以免每次都满足？
计划的工作方式，参与人员以及团队的活跃度
我想问这个问题，以了解团队内部的工程文化有多强。当只有团队负责人在计划并且团队在他身边时，这是一个选择。
另一个选择是整个团队都参与计划。并且，当任务来临时，将由对此有足够专业知识的人来进行绘画。然后他们都进行讨论并做出决定。这使团队更自组织，工作流程更有趣。
整个团队中有多少人
这里有两个极端。第一个极端是当您来到一个团队中，该团队在过去2-4年中一直致力于产品开发。如果同时团队没有太大变化，而只是扩大了规模，那么这很好，因为您总会有人向您求助。他们将能够提出一些建议，解释原因，告诉您项目的历史。了解上下文以及为什么一切都以这种方式安排而不是其他方式安排非常重要。
第二个极端是当您进入一个没有任何团队成员的团队时。例如，该项目被冻结，未冻结，并保留了大量代码库。您不能从头开始重写。因此，有必要恢复发展。也就是说，您获得了一个项目，在其中您将需要再次挖掘所有内容。
根据这些信息，您将能够就是否要去那里做出更明智的决定，并可能高估了您需要响应的提案的一些要求。
如何维护技术债务积压
任何项目中都有问题，了解团队如何与他们合作很重要。我写得很好，关于处理技术债务亚历山大列别杰夫文章中的“兰尼斯特斯总是偿还债务！（以及技术方面）”。
如果团队知道这些问题，但不知道如何系统地处理它们，那么这是一个不好的信号。但是，您可以将其视作一个机会，成为成为有助于解决这些问题的人的机会。
给刚开始使用遗留项目的人的提示
抵制诱惑，急于从头开始重写所有内容
常见情况：您开始在现有应用程序上工作，发现一切都做错了。有了这种“不是这样”，您需要进一步工作。在这种情况下，这是很自然的愿望-重新进行重新编写。这是正常反应。
我认为这是基于不愿为别人的错误回答的。毕竟，如果在修改后出现了新的缺陷，那么您就必须找出来。最好将其完全重写，然后一切都会好起来的。
如果您发现自己有这种想法，请问自己几个问题：
代码中肯定有足够的问题，或者您是否还不了解？
您确定您完全了解重写代码的所有集成点吗？
您是否对项目足够了解，可以正确预测即将到来的工作时间？
尽管我坚信立即着手从头开始重写所有内容的意图是一个坏主意。改进应该是迭代且可管理的。
当我看到团队说“都是废话，让我们重写”时，他们重写了六个月，却没有重写。结果，出现了一个相当有趣的情况，当该项目不得不从头开始时，要重新招募新团队，因为旧团队垮了。尝试消除这种完全自然的冲动，从头开始重做一切。
预测项目变更
您需要学习成为一个先知。与项目长期合作，您将学习了解其产品组成，了解业务，该项目的收益，生存方式。这将提供一个机会来评估您所做决策的长期前景。
这是一项非常有用的技能，因为当产品负责人来找您并要求您从他的角度做一些简单的事情时，情况很糟。例如，添加新条件以对列表进行排序。从您的角度来看，这意味着您需要重写整个组件。如果您事先想过，对列表进行排序的不同方法是完全合乎逻辑的功能，则不会发生这种情况。尽管一开始她没有被要求做。
只是不要走极端，尝试总是做出最普遍的决定。这是延长时间和解决此类问题的直接途径。这项技能的全部目的就是找到平衡。
做研究
当您从事一个长期项目时，业务对团队的信任程度很重要。在开发任何主要功能之前，我们一定会对主题领域进行全面的研究。这听起来像是一个船长的职务，但我知道有些情况下，人们立即冲着头进入大漩涡，看似简单的任务变成了长期的重构，如果在开发之前进行研究就可以避免。
花时间记录
记录您谈判的内容，记录流程，记录体系结构。在这里，我尝试坚持这样一种方法，即如果他们没有写下来，那么他们将不同意。因为在耗时半年以上的项目中，学会不丢失信息就变得至关重要。
当您做出架构决定时，对您来说似乎很明显。为什么以某种方式解释它？六个月或一年后，此体系结构解决方案出现了问题。您会想：“我为什么接受它？上下文是什么？”学习如何编写这些体系结构决策是一项巨大的投资，并且将来会发挥作用。
维护此类记录的一种方法是体系结构决策记录... 其主要思想是，对于每个非平凡的体系结构解决方案，您都需要创建一个包含以下元素的文件：标题，日期，上下文，解决方案的描述以及预期的结果。该文件与代码一起存储，创建后不会更改。它的主要价值在于，当需要更改此体系结构解决方案时，将更容易理解导致这种解决方案的动机。
简要地
- 如果开发人员不仅对编写代码感兴趣，而且对不仅有助于以程序员身份进行开发的任务感兴趣，那么具有历史记录的项目对于开发人员来说是一个成长的好地方。
- 在有背景的项目中，问题不是由代码引起的，而是由人员造成的，也就是说，当他们快速而持续地从您那里获取一些东西时（例如在游戏开发中），就需要进行这种管理。
- . , , , .
GDG.