没有人喜欢听别人说他们的工作很糟糕，但任何理智的人都会欢迎指导和避免不必要工作的方法。

有一种教学流派甚至说，你不应该指出错误，而应该专注于做对的事情。例如，与其指出难以理解的代码不好，不如指出他们的代码特别容易阅读的地方。在第一种情况下，你会引导其他人像蹩脚程序员一样思考和行动。在后一种情况下，你会像一个熟练的专业人士一样思考。

我不是我项目的首席开发人员，因此不能强加编码标准，但我发现糟糕的代码通常会迟早导致问题，当它发生时，我有一个更清晰的想法或解决方案。

通过在当时不插话，采取更自然的方法，我获得了领导更多的信任，他经常向我寻求想法，并让我参与项目的架构设计和部署策略。

他们可能也认为你的风格很糟糕。让团队一起讨论一套一致的编码风格指南。同意某事。这是否适合你的风格并不是问题，选择任何风格只要它是一致的才是重要的。

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

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

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

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

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

如果可能的话，确保他们明白你是在批评他们的代码，而不是针对他们个人。

在他面前重构他的代码，并显示两个版本之间的差异。他肯定会喜欢的。