重写其他团队成员代码的不成文规则

我们正在练习集体代码所有权。据我了解，这意味着任何开发人员都可以更改任何代码行以添加功能，重构，修复错误或改进设计。

但是，如何从仍在团队中的开发人员完全重写代码呢？我应该先问他吗？最佳做法是什么？

我认为良好的交流始终是最佳做法。与开发人员联系，看看是否有理由按原样进行编码。可能是因为他们很久以来一直打算重新构建它，或者是出于非常充分的理由以这种方式进行了重构，或者可能是你们俩都可以从对话中学到一些东西。

在没有事先通知的情况下进入和重写是病态的秘诀。

这个问题的前提对我引起了很多关注，我认为现有的任何答案都无法充分解决。让我在这里问一些后续问题：

1. 您是否绝对肯定地在谈论重写而不是重构？根据定义，对代码样式或结构的更改会导致改进的（或完全不同的）实现，而无需更改外部行为，这是重构，而不是重写。将一个整体的500行例程分成一组50个子例程可能涉及编写很多新代码，但这不是重写。重写一词意味着丢弃整个产品或功能，并从头开始。这不是掉以轻心的事情。

2. 如果原始代码的行为是错误的，或者实现存在问题，需要进行全面的重写，那么为什么它没有被您的团队的过程所捕获并在适当的上下文中解决（即从技术上而不是从社会角度）​​？错误或可疑的代码应该通过测试，代码审查，设计审查等快速地暴露给健康的团队。您有这些吗？

3. 经理/技术负责人是否了解问题，如果没有，为什么不知道？无论您采用哪种流程，代码质量通常都是开发经理的责任。他或她是您首先要问的人-显然不是在“某某人写的废话”的上下文中，而是“我认为我在这里看到一个主要问题，我们可以谈谈重写吗？” 如果不保证进行此类讨论，那么也许也不保证进行重写？

4. 如果有问题的代码的大小和范围足够大，足以引起对重写的认真讨论，那么为什么它仅由一个开发人员拥有？在我看过代码并以为“重写”的大多数情况下，即使不是在大多数情况下，代码也遭到了十几个人的践踏，而糟糕之处则是样式不一致，错误的或更改的假设以及过时的经验积累的直接结果。老式的骇客。正是由于代码的共享所有权，代码才随着时间的流逝而荆棘。

   我的意思是，一个人在假定实行集体所有权的环境中拥有如此大量的代码，这很奇怪。其他人是否害怕触摸此开发人员的代码？他们害怕提出这个话题吗？您的小组动态，或者特别是这位开发人员，可能存在潜在的问题；如果有，请不要忽略它。或者，也许这是你第一次在做这个项目，如果是这样，为什么你在游戏中这么早想重写？关于这种情况，我似乎并没有加起来。

5. 问题在第一段中指出any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs。重写会不会做这些事情？还是会做一些额外的事情-如果是这样，那又是什么？从根本上说，什么是你的原因，想要做一个重写，而你是如何确保他们将受益产品或团队？您不需要为我回答，但是如果您选择与团队讨论时，最好有一些客观的观点。

我确实感到这个问题涉及大量的上下文，如果不非常清楚该上下文，就不能回答。“正确”的答案完全取决于您的团队，您的产品，您的组织，您的个性，您的过程，原始代码的范围，更改的范围等等。IMO，这是您绝对需要与团队一起解决的问题，而不是在线问答网站上。

为什么要编辑代码？

有bug还是更根本的设计缺陷？

在前一种情况下，我担心重写以修复可能只是代码中的小错误的问题。

在后一种情况下，尽管我希望大家警惕地指出“我的”代码可能会被重写，但我对它的实现感到非常满意。

这就是集体代码所有权的重点-如果有更好的东西，您编写的代码将被修改甚至替换。

通常，如果大家都同意对代码负责，那么可以改进任何代码。首先与其他开发人员进行讨论。以某种方式编写它可能有正当理由。在个人层面上，许多开发人员在他们的产品上投入了情感投入，并且正如其他人所说，您不希望有恶意。

具体而言，它在某种程度上取决于团队的动力。打算重写初级开发人员代码的高级开发人员可能应该在对其进行重写之前对他们进行代码审查（我的网站）。这样，初级开发人员就可以从情况中学习。

原始开发人员是否在团队中，即使您是原始开发人员，也并不重要。出于以下原因，您的团队应完全重写任何共享代码：

• 这需要大量时间。如果其他人正在进行相关更改，则您不想浪费他们的时间。
• 其他人有不同的看法。即使您已经编程20年了，其他人也可能知道与您很少接触的代码进行交互的知识。
• 其他开发人员是源代码的“客户”。源代码是供其他开发人员阅读的。他们可能有他们在该代码中想要的但没有时间的体系结构要求，样式输入或功能请求。您不想仅仅为了发现另一个开发人员需要以其他方式重构而完成重构。

正如Matthew Flynn所说，有必要先与开发人员交谈。最初的开发人员可能会告诉您有关功能的重要信息，并说明为什么要提供此解决方案。

但是在重构或重写代码之前，请备份或包含该代码的分支。如果旧代码运行良好，则仍有可能被恢复。

如果您有一个源代码控制系统（我想您已经拥有），那么，如果可能，请重构整个代码，然后等到确定它可以正常工作后，再进行检入。

不要删除旧代码，至少在确保新代码可以正常工作之前，不要删除它。但是，将旧代码永久保留在那里也不是一件好事。我建议您稍后再删除代码，例如在通过测试后的一个月内。

它的范围是什么？

• 如果您要重新整理几行以提高效率，那就去做。也许问您是否有消除细微行为的危险。完成更改后，请在Scrum期间或通过电子邮件报告更改，除非更改确实很琐碎（修正拼写错误）。

• 如果您要重做一个体面大小的类，则可能应该要求确保您了解设计/行为。让人们提前知道，以便可能在同一地区工作的任何人都可以了解您并与您进行协调。

• 如果您要重新设计大型系统，则绝对应该与您的团队合作，使他们知道更改并计划设计。

如果您的原始作者在那里，请与他们交流。如果您不了解情况，这并非只是为了吃方餐，而是提供其他信息。有时，他们会告诉您一些有价值的东西。

我们有糟糕的代码控制。我目前有很多东西需要审查和维护，甚至没有人可以进行代码审查。以前的作者（除了moi）没有费心去评论任何代码。而且，他们已经离开公司。没有人要问代码。

当我重写时，我将其注释掉，并注释掉它，以及日期和名称/缩写，以及为什么将其注释掉。我用名称或缩写，日期，添加原因等注释新代码。

在包头（通常是er）附加注释，指示什么功能/ procs / SQL / etc。更改了日期。这样可以轻松查找已更改的部分，并且这些部分具有完整的文档。

评论很便宜。日期将指示更改的内容，并且在x天数（天/修订/新雇用/退休）之后，可以清除代码中的旧注释，而其余的则是新的基准。

根据我的观察，一般做法是：永远不要删除代码。只是注释掉并保留它。

我的做法是在替换它时将其注释掉。（主要供参考。）然后在工作更改的最后一次提交时将其删除。（这需要版本控制并了解如何还原更改。）

当我找到旧的注释代码时，我尝试在带有适当注释的单独提交中将其删除。这样可以更轻松地还原或检查所需的更改。

对于所有更改，您都应该能够使用修订历史记录来确定创建代码的开发人员。（带注释的修订历史记录对此有帮助。）如果可能，请与他们联系以查看代码的原样。在许多项目中，清理时间根本没有发生，事情变得落伍了。检查错误跟踪器以查看是否有必要清除的记录。有时需要在一两个版本中清除更改。

如果要更改代码，则应该使用该代码是有原因的。请与原始开发人员联系，以查明代码为何如此。如果有正当理由不予修复，请添加注释以解释为什么未修复或为何不应该对其进行更改。这样可以节省下一位开发人员的时间。

诸如FixMe，ToDo，Bug和Hack之类的标记可用于指示可以在以后更改的代码。（将限制标记为Bug并接受，如果在要求的条件下不会触发它们，则不进行修复是可以接受的。）如果房屋会计程序溢出2000万美元，则可能是Bug，但是我不会浪费太多时间进行修复它。

如果适合修改代码，则应由原始开发人员进行代码检查更改。

这可能取决于为什么需要重写。如果是因为编写的内容存在问题，并且始终存在问题，那么仅是为了最大程度地减少将来需要修复代码的频率，就必须谈论它。

在这种情况下，我的建议是在修复代码时配对。这样，它提供了中间状态的一个很好的示例，并（希望）提供了一些有关重写代码为何更好的上下文。另外（如果仅作为个人练习），请尝试重构代码以使其更好，而无需完全重写。这会比较困难，但是对您有好处。

另一方面，还有其他一些时候需要重写：

• 自编写代码以来，团队已经学到了很多东西，编写该代码的开发人员现在即使没有您的输入也将以不同的方式编写它。

• 新的功能要求改变了情况，因此有针对性的小型重写是合适的。

在这些情况下，我可能不会理会对话。

考虑一下，在我看来，代码在那里存在的时间越长，进行对话的可能性就越小。

我认为@aaronaught提出了一些要点，这确实引出了我想给出的答案，这实际上取决于谁在进行更改（以及为什么进行更改）以及谁编写了代码。

根据我的个人经验，通常会更改代码，因为它要么无法按预期工作，要么只需要扩展其实际功能即可。

在Team开发环境中，您不必（也可能无法）与原始编码器对话，所有内容都应从代码中清除。

这就引出了一个问题，它消耗了我的大部分时间，这就是原始程序员的意图，也是那个问题最经常导致代码被删除，也是我们为什么要注释所有内容以及经验不足的初级程序员的原因所在。经常犯规。

出于礼貌和实践的考虑，任何更改他人代码（重构）的程序员实际上都应该复制已经存在的代码的相同编码样式，并首先采取步骤确定原始代码的工作方式以及所尝试的方式达到并实际上要实现。通常，它本身可以识别错误，但是可以肯定，它迫使人们忍受下一个人查看您的代码的痛苦。

在我的团队中，任何人都可以删除，重构或重写任何内容，而且我认为“所有权”是一种使懒惰滋生的做法，好像一定会向某人通知任何更改，为什么他们需要使代码可读。

简而言之，不，您不必询问代码的原始作者，并且如果您查看代码，那么这表明他的代码不够可读，或者您需要改进你的技能。但是，我发现保留原始代码是一种很好的形式，已注释掉，直到您完全确定在重写过程中没有意外删除必需的功能。没有人是完美的。

通常出于某种原因以某种方式编写代码。将更改传达给作者始终是最好的。