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

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

让有问题的人就他们编写的代表性模块的代码向小组的其他成员准备一份演示文稿，并让问答环节来处理(相信我，它会的，如果这是一个优秀的小组，它甚至不应该变得丑陋)。

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

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

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

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

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并没有带来足够的改进，并且它正在损害项目，并且/或对你造成了足够的影响，那么可能是时候在团队中开始建立/执行标准了。这需要管理层的支持，但只有从基层做起才最有效。

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

人们编写糟糕的代码只是无知的一种症状(这与愚蠢不同)。这里有一些对付这种人的技巧。

Peoples own experience leaves a stronger impression than something you will say. Some people are not passionate about the code they produce and will not listen to anything you say Paired Programming can help share ideas but switch who's driving or they'll just be checking email on their phone Don't drown them with too much, I've found even Continuous Integration needed to be explained a few times to some older devs Get them excited again and they will want to learn. It could be something as simple as programming robots for a day TRUST YOUR TEAM, coding standards and tools that check them at build time are often never read or annoying. Remove Code Ownership, on some projects you will see code silos or ant hills where people say thats my code and you can't change it, this is very bad and you can use paired programming to remove this.