开发经理应如何处理代码“ Goal Tending”？

首先让我创造一个名词：

代码目标：早上检查代码，然后静静地检查其他开发人员前一天在文件中所做的所有更改（尤其是您最初开发的代码文件），并修复格式，逻辑，重命名变量，重构长方法等），然后将更改提交给VCS。

我已经确定了这种做法的优点和缺点：

• Pro：经常保持代码质量/可读性/一致性
• Pro：由于其他开发人员对原始代码不太熟悉，因此已修复了一些错误。
• 缺点：经常是那些追求目标的开发人员的时间浪费。
• 缺点：偶尔会引入一些错误，这些错误会引起开发人员的愤怒，他们以为他们前一天编写了没有错误的代码。
• 骗局：其他开发人员对过多挑剔的行为感到恼火，并开始不喜欢为目标投标人的代码做出贡献。

免责声明：公平地说，我实际上不是开发经理，而是实际上正在执行“目标管理”的开发人员。

在我的辩护中，我认为这样做是有充分理由的（为了使我们的超大型代码库保持良好运转），但我非常担心它还会带来负面气氛。我也绝对担心我的经理将需要解决这个问题。

那么，如果您是经理，您将如何解决这个问题？

更新：我并不是说这个问题太过本地化，但是有人问过，所以也许会有一些启发性的背景。三年前，我被分配了一个巨大的项目（200K LoC），直到最近（一年之前），该项目中才添加了其他开发人员，其中一些人不熟悉体系结构，其他人仍在学习该语言（C＃）。我通常必须回答产品的整体稳定性问题，当对代码库的核心体系结构部分进行令人惊讶的更改时，我尤其紧张。养成这种习惯的原因是，起初我对其他开发人员的贡献感到乐观，但是他们犯了太多错误，这些错误导致了严重的问题，直到几周后才发现。通常这些“

听起来您所做的工作基本上等同于代码审查，只是您要进行代码审查中建议的所有更改，而不是向开发人员提供反馈。几乎可以肯定，最好进行一次实际的代码审查，在该审查中，您（或其他人）向原始开发人员提供有关代码质量问题和明显错误的反馈，并请原始开发人员对其进行修复。这不仅可以提高代码质量，还可以帮助开发人员更加熟悉原始代码及其陷阱，并有助于改进将来的代码更改。另外，当错误被悄无声息的引入或引起其他开发人员以为他们在背后被谈论时，它也不会造成“惹人怒”的不利影响。

坦率地说，恕我直言，这是一个糟糕的主意。

我希望士气会下降，如果还没有的话。

公平地说，您确实承认这一点。

同行代码审查很好，它使开发人员的责任全部集中在一个层次上，而不是“他们与我们对抗”的情况。（他们是管理人员/潜在客户）。

也许有些开发人员可能需要比其他开发人员更多地关注，但是全面强制所有代码首先通过您是荒谬的。

尽管您认为自己有多好，但有时您还是错了，或者“挑剔”，这只会使情况变得更糟。

如果我是经理，请解决此问题：

• 与团队一起审查代码标准和实践，并将其交给代码标准的副本
• 定期进行同行评审代码，以加强将要遵循的标准和实践
• 使用自动化工具强制进行分类/格式化，以便开发人员被迫遵循标准
• 摆脱所有拒绝遵守标准的糟糕队友
• 不再是守门员

您的意图不错，但实施起来很糟糕，而且正如其他人所指出的那样，将导致团队成员士气低落和令人目结舌。

如果项目从没有任何标准开始，请尝试分阶段简化新标准，而不仅仅是切换开关。

坏枣

我不是开发经理，但如果我是我，我不希望任何开发人员接触不属于他们的缺陷或功能的代码。期。如果您发现其他人的代码有问题，则一定要引起负责开发人员的注意，但不要仅仅自己动手修复它，尤其是如果您没有与其他开发人员进行协调（ s）首先。

清理任务仅应在团队进行正式代码审查后才能执行，并且仅应由分配了这些任务的开发人员执行。

主动性总体上是好的，但有时它会伤到你。如果您在工作代码中引入任何错误，您可能会很快希望您选择了一条不同的职业道路。