上次，我谈到了如何准备与同事 就糟糕代码进行艰难的对话。 这包括了解不该说的内容，并针对要解决的具体缺点制定游戏计划，以及您希望从对话中获得具体结果。这一次，我要谈谈如何与你的队友“鲍勃”真正互动。
不是你 是否 要说什么，而是 如何说
提前建立案例后，是时候去和 Bob 聊聊了。你很冷静，你很理性，你有一个合理的论点，而且你都准备好进行建设性的对话……但是对话的引导可能会很尴尬。为了让谈话更自然，我建议做的是寻求他的帮助。 “嘿，鲍勃，我正在通过代码追踪缺陷，它让我想到了你的这种方法。乍一看有点难追，所以我希望我们一起追查？”现在您不是过来向 Bob 宣扬他的代码的弊端，而是请他帮助您解决问题。
一旦您一起查看屏幕并开始深入研究，我发现发现代码问题的最有效方法之一就是通过 苏格拉底方法 。与其告诉 Bob 该方法太长，不如提出一系列问题。 “哇，幸好你在这里——这是一个相当长的方法，有很多事情要做。你认为普通团队成员需要多长时间才能理解它？” “咦，哇，三四个小时，花在理解一个方法上，似乎是相当长的时间，你不觉得吗？” “如果再小一点呢？”
现在，这就是它开始变得有点棘手的地方。宣告事实或强烈陈述观点往往会使人们处于 防御姿态 。提出问题，即使是引导性问题，也不会让人们烦躁不安。他们倾向于以解决问题的方式加入你，而不是以辩论的方式反对你。尽管如此，以这种方式提问可能不会导致预期的结果，这就是您完成作业的原因。将话题从问题转向陈述你的经历和感受。这些是无可争辩的。
“我知道你认为分解方法只会分散复杂性，但我花了几个小时试图理解这一点。我在爱丽丝的代码中没有遇到同样的问题，她使用了很多小方法。”到目前为止，Bob 对此无话可说，因此这是号召性用语的良好前提。 “你可以在那里找到很多关于与较少错误相关的小方法的文献和研究，而且我知道我不是团队中唯一喜欢阅读和编写更紧凑代码的人。你怎么认为？我们可以尝试配对并稍微重构一下吗？它可能有助于减少源自您已实施的功能的缺陷数。”
最后一行是参与拼图中关键的最后一块。鲍勃可能无法反驳你经过深入研究的立场，他当然也无法反驳你的感受，但他仍然不愿改变他的方法。您需要关注新方法如何不仅有益于其他人或一般代码库，而且还特别有益于 Bob 自己。 没有人 愿意 编写糟糕的代码并承担后果，因此请帮助他们了解生活可以变得更好。
维持建设性关系
正如我所说的，你不会让一个写了糟糕代码的人一下子就扭转了整个局面。第一次接触是关于按照这些思路建立关系并为更多会谈奠定基础。要做到这一点，你必须做好准备并保持耐心，愿意温和但坚定地推动，并且机会主义地寻找能引起共鸣的推理路线。如果你能向 Bob 展示不同之处并让他相信采用新方法的好处，未来的协作改进会议将自然而然地开始。很多时候，它们会发生在 Bob 渴望学习的情况下。我个人曾在很多团体中以这种方式建立信任，导致主动要求审查他人的代码并提供反馈。如果发生这种情况，那么您就处在一个绝佳的位置。
随着时间的推移，您和 Bob 可以一起制定更广泛的代码改进策略。即使他在最初的对话中很容易接受并且很热心，但从“Bob 写的代码很糟糕”到“Bob 写的代码很干净”，这种持续的维护将是必需的。这将需要对好代码和坏代码之间的差异进行分类，跟踪它们，并有策略地与 Bob 一起工作，一次一两个，以帮助他变得更好。当他练习更简单的代码时，您可以逐渐介绍越来越多的代码，以轻轻地将他推出他的舒适区，转向更简洁的代码。
那么，最后，您如何告诉 Bob 他的代码很糟糕？
一两年后喝了一杯啤酒，当他惊叹于他的进步时：“当时我不想让你气馁，但你的代码真的很烂。你已经走了很长一段路。好工作。”
这是我们关于工作环境中不良编码系列的第 2 部分。要阅读第一部分， 请单击此处 。
如果您的开发团队的代码最近没有达到标准，请尝试使用 Collaborator，它是 SmartBear 的同行代码审查工具。