对于许多团队来说，重构是很痛苦的。 因为如果您进行重构，就不会开发主要产品，而如果不这样做，项目的技术负担也会增加。 在某些时候，团队想到：“让我们区分重构和开发，并分配例如20％的工时，其余时间我们将继续从事开发！” 这个想法不错，唯一的问题是，每100个开发小时，您将永远不会获得20个纯粹的重构小时。 因为“开发”不仅适用于代码。
如果我们谈论的是成熟的团队，而不是将微型团队压缩为3至5人的物质点，那么“开发”除了编写代码外，还包括许多其他团队活动。 在“开发”中，您可以写下许多人不喜欢的会议，使用文档，在任务管理器中维护报告等。 所有这些消耗了我们分配给开发部门的手表的约30％。 不知何故，事实证明，与“ 80小时的代码，20个小时的重构”这样的画面相比，我们直接为重构本身得到了约13个小时的难看数字，因为其他所有事情都被其他活动吸收了。
下面我们将告诉您如何将开发与重构相结合，以使项目的技术负担不会像滚雪球一样增长，而且还会讨论时间的正确分配和优先级。
重构为什么会引起很多问题？ 首先，由于团队无法充分评估自己的资源并将此过程与开发相结合的事实。 在人们看来，如果每天的工作时间为每天8小时（每周40），那么他们应该从事的全部40小时都属于开发工作。 事实并非如此。
整个开发过程可以分为两个部分：这些是边际活动，以及与代码直接相关的所有内容。
这是我们其中一个开发团队的时间分布情况。读者可能有一个合理的问题：“您是如何构建此图的？” 现在我们将尝试给出答案。 数据并非取自最高限额，而是基于我们的内部统计数据。 我们的开发人员会跟踪他们在Jira的活动。 每个这样的个人工作日志都包括四个部分：代码审查，技术讨论，特定的故障单和“其他所有内容”。 由于这种相当简单和透明的分类，我们对团队在开发的各个方面花费了多少时间进行了分析。 如果所有工作时间的三分之一都花在开会，起立和评论上，一切都在正常范围之内。 如果在这些活动上花费了超过33％，则团队存在问题，需要解决。
似乎没有任何收获，一切都是合乎逻辑的，但是我们如何使重构适合这个故事呢？ 声明“重构之月”并在开发上得分？ 但是，任何商业产品都有其自己的时间表，这是非常不可取的。 重构仍然像是一个泥潭：如果您开始处理它，那么就很难停止，您将陷入困境。 重构使团队的注意力转移到了自己身上，并且我们对在已编写的代码中“按顺序放置东西”产生了巨大的偏见，而不是将项目移向更光明的未来。 那么如何分配时间呢？
以下幻灯片给出了一些答案：
保留时间日志，这非常有用会议和审核保持不变，因为我们认为这些活动已尽可能优化并保持在最低水平（那些参加会议和代码审核花费70％的时间的团队的人会证实我们的话）。 因此，我们花时间重构开发中的代码和错误修复。 在这里，我们再次采用“三分之一和三分之二”方法，将我们收到的工时分为“重构”和“错误”，从而将这些概念清楚地分开了。 这种模型是可行的，并且至少在不增加技术负担的情况下，您可以找到时间来恢复项目的订单。 如果我们浪费太多的“开发”时间，该项目将停滞不前。
我们正确地进行重构过程
假设您决定重构而不是从头开始重写项目。 但是在这里，您无法像在部队中那样抢到第一个，并“从这里到午餐”进行重构。 由于我们的资源有限，并且我们的目标是阻止技术债务的增长（理想情况下实现技术债务的减少），因此我们必须明智地处理这一任务。
最好的解决方案似乎是允许团队负责人或其他开发经理确定工作范围，分配任务并继续进行重构。 但是这种选择有一个严重的缺陷。 蒂姆利德（Timlid）是我们团队的指挥家，但是指挥家并不总是很清楚当地音乐家的问题。 如果您是僵硬的垂直平台的支持者，并且由一个人来决定如何进行重构的模型，那么您会自愿坐在燃烧的KAMAZ中，刹车失灵会从山上冲向深渊。
我们的经验表明，事件开发的可靠版本是各种重构方向的统一定义，也就是说，开发人员应参与编制未来的工作清单。 只有该代码的直接作者才能诚实地承认此部分是否已充分关闭或由于时间不足，在那里堆积了各种拐杖。 此外，正是开发人员处于技术的最前沿，并且能够明智地评估项目中哪些要素需要重构，哪些要素不应该涉及。
对于我们自己，我们想出了这种方法：每个开发人员都记得项目上的薄弱环节，并写了一张卡片，说明需要做些什么才能使其变得更好。 然后将在这些卡上确定任务。 没错，这是有细微差别的：在收到第一张以“做得好”的方式获得的卡片而没有任何上下文之后，我们开始以压缩形式要求这种上下文。
相同的卡但是，定义任务不足以开始执行它。 因此，应该为每张这样的卡编译一份清单，以回答一系列简单的问题，例如“我们是否需要并行处理？” 或“是否有任何因素使我们无法完成此任务？” 在填写了这样的清单之后，开发人员会收到一份准备清单，其中列出了在准备工作阶段需要解决的所有可能出现的问题和阻止程序。
另一个强制性步骤是确定谁最了解项目的哪个领域。 这将优化重构过程，并为团队成员提供他们最能证明自己的领域中的任务。 没错，有一天我们遇到一种情况，一个半人通常理解该项目的一个方面，但是即使这个问题也可以解决。 为了消除信息真空，仍然在团队其他成员通过的区域“摸索”的开发人员应该分享他们的知识。 这可以是文档，也可以是一些小型演示，甚至可以是包含代码说明的视频。 向同事传达信息并确保尽可能少的暗点非常重要。
最后，团队必须明确回答以下问题：“我们的技术债务规模是多少？” “ C级”，“合格”，“十分之五”，“可以居住”等等级不再起作用。 以前，对于一个项目，我们从服务站回答了类似的问题，答案是“十分之五”，当我们将技术债务的金额转换为数字时，我们得到了650个小时。 真尴尬。 只有明确回答该问题，才能明智地评估即将开展的工作的范围。 这一点也很重要，因为“无尽”的任务会扼杀团队成员的动力，并激怒企业：开发人员和管理人员都应该看到团队将努力追求的切实目标。
优先次序
在定义了工作的前沿之后，我们需要将重构与开发结合起来。 显然，我们无法在项目的不同部分中停止要素锯切或为此事件分配一些特殊时间。
这是最困难的部分开始的地方。 开发团队应该明智地确定在哪个时刻开发更重要，在哪个重构中很重要，尤其是当此时在代码中正确地看到某些功能时。 也许在重构之后，进一步的开发会变得更加容易，并且在某些情况下，我们可以完成功能并进行重构。 我们与产品进行交流，就决定进行辩论并就订单内容达成一致。 例如：“我们首先进行重构-不仅是因为我们感到满意，而且因为最终的总期限会减少。”
最重要的是不要忘记我们的目标是开发产品，而不是为了完美的代码或完全消除技术债务而编写完美的代码。 在这方面，开发应该完全足够：如果现在进行重构会损害我们的业务开发任务，那么我们将完成一段新代码的编写，然后我们才对旧代码进行更正。 如果情况表明重构该部分对项目有利可图（无论工作的前端看起来多么怪异），因为进一步的工作将变得更加简单和有趣，那么我们就需要重构。
这种方法非常不适合垂直管理模型，有时您会遇到必须在客户面前捍卫自己的决策的情况。 但是除此之外没有。
结果是什么
通过所描述的方法，我们将重构过程有机地集成到当前的开发中，减少了技术债务的规模（或停止了增长），所有这些都没有造成重大人员伤亡。
是的，为了进行重构，您将不得不减少开发新功能的时间，这将增加时间，但是选择很小：您要么与开发并行进行重构，要么迟早会遇到大量的拐杖，问题和错误，这样将更容易从头开始重写项目。 因此，如果您重视团队的工作，那么您仍然应该考虑重构，而不是将来重写。
有用的材料：1.阿列克谢·卡塔耶夫（Alexey Kataev）的重构报告：更多实际示例，以及经理格列布（Gleb）的一个令人震惊的故事，他不愿重构。
2.
我们的任务讨论规定3.
我们的清单代码审核