以一种非对抗性的方式提出一个更好的选择。

“嘿，我觉得这个方法也可以。你们怎么看?”[用手势表示屏幕上的代码明显更好]

进行代码审查，并从审查你的代码开始。

这将使人们在整个代码评审过程中感到轻松，因为您是通过评审自己的代码而不是他们的代码来开始这个过程的。从你的代码开始也会给他们提供如何做事的好例子。

Privately inquire about some of the "bad" code segments with an eye toward the possibility that it is actually reasonable code, (no matter how predisposed you may be), or that there are perhaps extenuating circumstances. If you are still convinced that the code is just plain bad -- and that the source actually is this person -- just go away. One of several things may happen: 1) the person notices and takes some corrective action, 2) the person does nothing (is oblivious, or doesn't care as much as you do).

如果#2发生了，或者从你的角度来看，#1并没有带来足够的改进，并且它正在损害项目，并且/或对你造成了足够的影响，那么可能是时候在团队中开始建立/执行标准了。这需要管理层的支持，但只有从基层做起才最有效。

祝你好运。我能感受到你的痛苦，兄弟。

这完全取决于你写作的文化。在一个自由软件项目中，你告诉他们他们写的代码不好，并给出积极的建议、改进方法和反馈。你也可以给他们的代码发送一个补丁。

一封友好的电子邮件也不会有什么坏处。

在Gerry Weinberg的书《计算机编程心理学》中有一些非常好的建议——他的“无我编程”的整个概念都是关于如何帮助人们接受对他们代码的批评，而不是对他们自己的批评。

提出问题，让他们意识到他们所做的是错误的。例如，问这样的问题:

你为什么决定让它成为一个全局变量? 你为什么给它起这个名字? 这很有趣。我通常这样做，因为[插入你更好的原因] 这样行吗?我通常[插入你会如何让他们看起来很傻]

我认为最理想的方法是巧妙地问他们为什么要这样编码。你可能会发现他们相信其他方法也有好处。除非我知道他们的编码风格是由于错误信息，否则我永远不会在没有充分理由的情况下判断我的方法更好。最好的办法就是问他们为什么选择那样做;一定要让自己听起来对他们的推理感兴趣，因为这才是你需要攻击的，而不是他们的能力。

编码标准肯定会有所帮助，但如果它是每个软件项目的答案，那么我们都只能在天堂的私人岛屿上啜饮鸡尾酒了。在现实中，我们都容易遇到问题，软件项目的成功率仍然很低。我认为问题主要是源于个人能力，而不是传统的问题，这就是为什么当问题浮出水面时，我建议大家一起解决问题。

最重要的是，不要马上认为你的方法更好。在现实中，可能是这样，但我们在处理另一个人的意见，对他们来说只有一个解决方案。永远不要说你的方式是更好的方式，除非你想让他们认为你是一个自鸣得意的失败者。