如何解决同事的错误代码

您正坐在办公桌前，试图在报告的错误发生时“追踪” 它。狩猎将带您进入某种激发您进行双重考虑的方法。它大约有 1,200 行长，它有 switch 语句嵌套了三层，你认为（但你不确定）它无缘无故地连续做了两到三次同样的事情。您查看源代码控制历史，发现这是另一个“Bob special”。看到这个之后，你开始考虑终于要和 Bob 进行一次迟来的谈话，这样你就不必继续清理这些烂摊子了。那肯定不会是一个有趣的谈话。那么你如何处理它呢？

从哲学上讲

让我们先弄清楚一些事情。真正善于告诉队友他们的代码充满了问题，就像非常善于在将自己锁在车外后闯入你的车：这在当下的战术上很有用，但表明你需要一个更好的整体策略。你的目标不应该是掌握如何温和地告诉同事他们的错误代码，而是让掌握变得不必要。我说这不是某种元逃避，而是将您的策略置于上下文中，作为开始或进一步建立关系的尝试。

“真正善于告诉队友他们的代码充满了问题，就像非常善于在把自己锁在车外后闯入你的车一样。”
鸣叫这句话

当您是团队的一员时，如果您团队中有人犯了错误代码，那么团队中每个人的失败都是如此——包括您自己。因此，当您准备与相关人员一起计划的干预时，请记住您不是某种中立的犯罪现场调查员，不会对事物进行消毒评估。你是问题的一部分，你分担责任。 你的团队。你的代码。你的问题。

好消息是，如果您建设性地处理此对话，您就迈出了解决问题、代码和团队的第一步。所以关键是让它具有建设性。

不使代码批评具有建设性的 5 种方法

在详细介绍如何处理此对话之前，我将简要列出 5 件不要做的事情。

当您感到沮丧或生气时，不要进行对话。相反，等到你冷静和理性的时候。
除非有明显的问题，否则不要介入。如果你和他只是有不同的大小写偏好或其他东西，你造成的紧张可能会抵消标准化的好处。化妆品编码标准和其他相对次要的问题可以而且应该通过自动静态分析来解决。
不要以任何方式依赖资历或地位。没有比强迫人们做他们不同意“因为你这么说”的事情更容易滋生怨恨的方法了。
不要指望一次会面就能彻底改变某人的整个方法，并使谈话成为马拉松式的事情。你想要一个清晰且相对简洁的信息，这样你就可以在不让对方筋疲力尽的情况下表达你的观点。从长远来看，情况会有所改善。
最后，不要说代码是“”，那是一种无用的、主观的分类方式。软件中的一切都与权衡取舍有关，因此您要做的是向 Bob 表明，他正在为团队其他成员的快速和肮脏的编码以及令人头疼的维护问题付出代价。

建立建设性的代码策略和环境

通过阅读不该做的内容，您已经做好了一些准备，现在是时候补充 该做什么 了。此准备工作需要包含三个主要部分：

(1) 您想解决的差距
(2) 支持你的论点
(3) 你希望的结果。

这三件事将构成您打算进行的讨论。

差距是 Bob 代码中实际存在的特定问题。

你不想走到 Bob 的办公桌前，拉过一把椅子，向后坐下然后说，“所以，Bob，你在编程这件事上很糟糕……说得好！”您需要决定在此讨论期间要解决的有形项目。问题最严重的根源是什么？是大法吗？嵌套的 switch 语句？重复代码？选择其中的一两个来涵盖。正如你不想变得挑剔和模糊一样，你也不想变得挑剔和毁灭性地具体，像某种部门的马丁路德一样读出鲍勃最大的编码缺陷中的 95 个。 Bob 的代码可能有 95 个错误。但如果你想解决所有问题，为指导关系奠定基础很重要，因为你绝对不会在一天内解决所有问题。

建立支持：做你的研究。

假设您决定将方法长度作为要解决的主题。接下来要做的是为你的论点建立支持。在这个问题上引用一些支持性研究或广受尊敬的行业人物比向 Bob 声称他的方法太长要可信得多。为你想要涵盖的原则建立一个有证据的案例，然后在代码库中找到具体的、有问题的实例来讨论。你最不想做的就是对这个问题挥舞手——你希望能够指着它说，“例如，这就是一个非常大的方法。”

结果应该是可行的

在选择了你的问题并建立了一个案例之后，最后要做的就是选择一个引导对话的结果。因此，您向 Bob 展示了他编写的一个巨型方法，并使他相信巨型方法的弊端。 “呃，好吧，”他会说。 “所以现在怎么办？”提前决定您是要共同将方法分解为 X 个较小的方法，还是要让代码处于没有任何重构方法长于 Y 行的状态。不管是什么，选择一些可行的东西，这样你和鲍勃就可以以共同的胜利结束谈话。