许多人遇到了一个参加该项目的新来者，他说：“一切都需要紧急重做。” 有些人自己说或想过。 这就是“管道综合症”：行为表现为在进行新项目或转行新工作时渴望以自己的方式“正确”地做每一件事。 因此，现有代码，技术或工具需要重新编写，最好是“自己编写”。 如果这个主题在每个项目中都没有经常重复出现，并且每次招聘新员工，都会很普遍。
项目“生存”的时间越长，它积累的“历史的”，继承的代码就越多，满足受“综合症”影响的水管工灼眼的机会也就越大。 在这篇文章中，我想告诉您Parallels遵循哪些原则（立即，破坏者是“不伤害”的原则），以及如果我们决定“重做一切”该怎么做。 尽管总的来说，我们认为应该对这种综合症进行治疗，而且使用遗留物有时甚至是有用的，因为它使您可以按时发布产品，而不会浪费时间开发技术。
当您使用“长寿命程序”时，旧代码占其中足够大的比例。 例如，Parallels Desktop已经开发了15年以上。 团队不断扩大，每年都有新人来，看看所写的内容，然后宣布：“一切都是歪曲的，让我们从程序员的手中解脱出来，重写一切。” 熟悉的情况？
在开始说遗留代码是好是坏之前，我想先确定这是谁，以及这意味着什么。 通常使用两种定义：第一种是测试未涵盖的代码。 从自动测试的角度来看，测试未涵盖所有代码。 第二个旧代码是您继承的代码。 当您需要了解其工作原理时，无人问。 而且您必须自己动手。
赋予智慧
I.最好是善的敌人。 如果遗留代码或系统以可接受的质量执行所有必要的功能，则您无需对其进行改进，最好将沸腾的精力引导到更有用的功能上。
二。 从重要和新中选择重要，从平等中选择新。 如果遗留代码包含重要功能且未被测试覆盖，则无论是在处理代码还是在测试覆盖范围内，您都需要对其给予最大的关注。 如果旧代码和新功能的重要性相同，那么您应该关注新功能（开发和测试）。
三， 如果旧的不宜改进，则在附近建一个新的，然后丢弃旧的。 如果需要旧代码但无法更改，请使用旧代码，直到编写和调试新代码为止。 当新代码起作用时，旧代码可以被丢弃。
怎么办
步骤1.我们看看谁说1.
自由职业者 。 通常，那些没有从侧面加入大型项目经验的人会完全重做代码。 例如，我本人首先从事自由职业，从零开始编写项目，并且像许多类似的开发人员一样，我养成了一个相当稳定的习惯-完全按照自己喜欢的方式做。
2.没有
经验 。 有时这样的陈述表明该人本人在主题领域缺乏资格：他不知道该项目的历史，例如，这种（可怕的）（在他看来）的构造是人们在开发过程中绊倒外部错误的结果系统并开始解决它们。 结果，互连的修补程序和拐杖出现了一种意粉，用于解决这些错误。 从外部对人类所有现有陷阱的这种了解在原则上是不可能的。
3.
D'Artagnan 。 通常，这种情况发生在没有产品经验和没有大型项目经验，不了解所能获得的价格的工程师身上。 一个人用脚后跟打他的胸部，并说他将在一个星期内出色，新颖地做这件事，但是他可能会严重误解自己的能力，因为他完全错过了测试和集成到现有较大系统中的要点。
4.
高素质的专家。 尽管急于重做他的建议，但您应该听的唯一一种“申请人”，直到步骤2完成后仍然不值得。有可能我们得到了超一流的专业人员，他确实可以证明我们没有这样，可以做得更好。 但是事实是，我还没有见过这样的陈述。 当一个人成长到这样的水平时，他已经可以想象整个项目，并理解“革命”方法的所有缺点。
步骤2.进行论证一个人需要停止并分析其论点的第一件事。 该审判应由团队负责人发起。 需要注意的是，“管道综合症”并没有开始遭受一个自己来领导的人的困扰。 然后，对飞行进行分析是项目经理的工作，尽管坦率地说，成熟的团队负责人在没有认真争论的情况下永远不会进行彻底的变更。
什么参数将失败：“我们将与国际象棋和诗人一起写我们自己的书”通常，如果一种产品早已投放市场，那么它已经可以以某种方式起作用。 他已经表明，尽管引擎盖下的东西具有可怕的性质，但它仍在起作用。 例如，我们有Parallels Desktop（一种无需重新启动即可在Mac上运行Windows和其他操作系统的解决方案），有时您可以从初学者那里听到：“某种程度上您太复杂了，让我们编写我的虚拟机。” 而且，由于这种事情从原则上讲无法立即完成，因此当一个人这样说时，他要么不在话题上，要么不是自己一个人。 有必要给他提供该项目的初步经验，并了解为什么从一开始就如此实施。
“这很丑。”麻烦在于，一个人常常没有其他论点。 “技术不先进，”“有些垃圾”，“为什么用C编写，现在用Go编写很流行。” 这些不是重建系统的理由。 因为当您超出一段代码的范围时，您开始意识到您的重做可能比以前更糟。 它在内部看起来更漂亮，并且工作更慢，这对于产品而言是不可接受的。 我在Parallels中没有看到这一点，但是在以前的公司中，我们必须充分体验此步骤的所有后果。 我们决定丑陋地实施某些设备的驱动程序系列，并且我们需要更优雅和扩展的设计，以便于维护和为其添加新功能。 他们写了一年半的新书和漂亮的书，但最终结果却糟透了，没有带来任何好处。 事实证明，资源成本非常高：两名开发人员吞并了一家公司，并花费了半年的时间。
为什么最好不要接触大型项目的长期代码
你甚至可以杀死你的项目在哪里可以保证您可以再次写一些东西并且可以正常工作？ 毕竟，这还没有。 从业务角度来看，您需要活在当下并确保收入的连续性。
你可以拐杖在任何项目中，都存在诸如klurudge（俗称“拐杖”）之类的东西，还有许多未记录的东西。 是的，有这样一种开发方法，首先编写文档，然后严格遵循开发，但是在90年代，它仍然表现出对于业务任务过于惯性。 也许通过这种方式，您可以制造火箭，也就是说，在数十年的发展过程中，这样做是合理的，因为存在很大的偏离风险。 甚至在那里，您也必须在旅途中进行一些更改。
从软件的商业开发的角度来看，没有太多的时间首先考虑文档中的所有内容，然后再做。 事实证明，所有产品都具有大量未说明的数据。 遇到了某种环境问题，例如，一些铁制品绕过了规范，为此进行了工作。 在许多情况下，如果只是相对较小的更改，那么通常会忘记它并且不会在文档中反映出来。 不幸的是，它只是被插入到代码中，而且通常是带有一些理智的注释。
它开始了：让我们把所有这些拐杖都扔掉，因为还不清楚它会破坏代码。 他们不认为这会导致什么。 例如，当我们为Linux内核制作一个补丁程序时，在一处这样的拐杖就砰砰地跳了起来：它非常丑陋，同时描述得很差。 然后，他们在讨论中了解到：没有这个仓库的某些设备不起作用。 是的，它不再生产了，但是用户仍然可以使用并且可以使用。 失去对此硬件的支持与Linux社区的哲学背道而驰。 我必须重写我们的代码，以便此解决方法可以一对一保留，然后所有人都感到满意。
你会浪费资源上面给出了这种浪费资源的例子。 应当理解，任何革命都会导致内战，在一定时期内事态会恶化，在此期间什么都不会起作用。
您可能会失去发起人和项目水暖综合症主要影响新员工。 值得记住的是，这样的人有风险，因为他们可以在试用期内离开公司（他们说试用期不仅对个人而且对公司而言，都是没有道理的）。 该名男子被给予全权委托，他开始重做，然后宣布他不喜欢公司里的咖啡，就离开了。 这是非常危险的情况。 事实证明，没有新的东西，但是旧的已经被打破。 然后，某个人（绝不是发烧友）将不得不把它变成工作形式。
当决定不重做的决定很明显，并且该人正在“想一个主意”时该怎么办？
留出时间冷静思考您只需要花时间给参加大型现有项目的人加深了解。 因为当一个想法来自在公司工作了很长时间的人，特别是使用该产品的人时，那么他的倡议将被更加认真地对待，并将通过他的论点进行分析。 您需要向他解释，您不应该投掷一个您还不熟悉并且不了解当前情况的区域。 值得怀疑的是，刚到的人，只要看了一下代码，就能合理地解释为什么一切都不对以及为什么需要更改。
如果一个人拒绝这样的拒绝或提出很多建议，那么这是一个说明的机会，也许这个开发人员可能不准备在团队中工作，并且与他的沟通可能会出现困难（这对我们来说是非常重要的因素）。 从那时起，团队负责人将必须以“手动模式”单独工作。 也许这样的人应该重新考虑自己对职业的看法，并成为自由职业者，在那里您可以“按需”做所有事情。
将他的精力引向另一个方向由于一切都在外面发生变化，因此大多数大型产品总是会遇到一些瓶颈和问题，这些问题经常会出现。 尽管我认为，让新手进入代码直到他在调试小错误上工作了几个月，了解现有代码并证明自己的技能水平仍然非常危险。
可以从一些辅助项目中给他一个任务，这样他就可以将他的新东西放在那里，看看会发生什么。 这是因为资源有限，因为任务数量有限，在这里，与风险投资一样，我投资了100家公司并获得了回报。
当您仍然需要重做时
产品在现有条件下死亡重做的理由-如果外部环境已发生很大变化以致现有产品停止工作。 例如，当他们发布新的操作系统时，用户开始大量切换到该操作系统，但是在此OS中进行了一些更改，以便您的产品（在以前的版本下可以正常运行）停止运行，或者使用户使用起来非常不便。 或者，当平台消失时（例如，从一个旧的平台消失），您可以引用BeOS，在该平台下，BeOS与多媒体产品（例如作曲音乐）一起工作了很多。 该系统死了，并且由于它非常独特，因此来自该系统的代码实际上没有转移到其他系统。 操作系统BeOS本身也发生了同样的事情：有他们瞄准的Atom计算机，然后制造商停止发布这些处理器，为该计算机编写的人员几乎一无所有。 而且他们被迫紧急适应英特尔，这对他们来说很不利-利基被占领了，另一个操作系统统治了那里。 为了至少以某种方式延长寿命，他们不得不认真地重做它，以改善便携性等。
水暖综合症的工作：重塑阶段
在不中断系统的情况下，有必要进行渐进式并行处理。 变更的过程和阶段取决于我们要更改整个产品的整体还是重要的一部分。 如果是整个产品，那么这实际上是从头开始新项目的开始。 但是在大多数情况下，它们仍然会改变部分，因为在第一种情况下，新的代码库必须至少超过一年的时间才能达到新的代码库稳定并符合消费者质量的标准。
如果要更换组件，则建议这样做：如果外部接口不需要更改，则我们悄悄进行第二个实现。 建议立即找到分界线：这里是旧的遗迹，但是这里已经可以重做，找到入口点。 因此，保留界面，更改填充。
就像汽车一样，他们决定用电动机代替汽油发动机。 对于用户而言，几乎没有什么变化：相同的车身，四个车轮和方向盘仍然保留。 在幕后，其他一切都可以。
如果您设法找到这样的分割点，则可以逐步进行重做，并且站在该分割点的任何人甚至都不会注意到所做的更改（希望可以改善工作质量）。 然后在内部测试过程中切换并保存产品。 不幸的是，这远非总是可能的，然后更改可能导致灾难。
或使用此选项：接口是固定的，实现已完成，然后接口开始迭代更改。
在侧分支上进行认真的更改是有意义的，直到完成外观为止，它不会集成到主要产品中。 即使在子系统方面，如果以这个名字开始做一些全新的事情而团队破裂，那就更糟了，那就根本没有产品了。
而不是结论
一个男孩出生时带有坚果而不是肚脐。 然后他定期问他的父母为什么他在那里有坚果。 父母答应在他14岁生日时告诉他。 那家伙14岁了。然后他又去找父母，问他为什么要坚果而不是肚脐。 父母答应告诉他有关他何时18岁的信息。 18岁时，他再次问，然后他们告诉他，有一个热带岛屿，上面长着一棵棕榈树，在这棵棕榈树下埋了一根树干。 他的所有问题都有答案。 这个家伙积saved了很长时间，仍然在这个岛上毒死了自己。 我发现了一棵棕榈树，挖出一个装有扳手的箱子。 他毫不犹豫地用找到的扳手拧开了螺母，然后屁股掉了下来。 道德：有时候您只需要在第五点寻找冒险。