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

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.

开始进行代码评审或结对编程。

如果团队不愿意这么做，那就尝试每周设计回顾。每周开一个小时的会，讨论一段代码。如果人们看起来很有戒心，那就选择那些没有人在情感上依恋的旧代码，至少在一开始是这样。

正如@ jesere所说，关注代码，而不是编码员。

当你看到一些你认为应该不同的东西，但别人不这么看的时候，那就开始问一些导致缺陷的问题，而不是指出它们。例如:

Globals:你认为我们还会想要更多这样的东西吗?你认为我们会想要控制它的使用权吗?

可变状态:你认为我们想要从另一个线程操纵它吗?

我还发现关注自己的局限性很有帮助，这可以帮助人们放松。例如:

长功能:我的大脑不够大，不能一次容纳所有这些。我们怎样才能做出更小的我能处理的东西呢?

坏名声:在阅读清晰的代码时，我很容易感到困惑;当名字被误导时，我就没有希望了。

最终，你的目标不是教会你的团队如何更好地编码。而是在你的团队中建立一种学习的文化。每个人都向他人寻求帮助，成为更好的程序员。

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

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

根据我的经验，曾经有一段时间，我们想要将一个windows应用程序更改为一个web应用程序并进行优化，因为它更容易更新和维护。但由于我的朋友是windows应用程序的主要贡献者，他不允许更改，然后剩下的就是历史了。

寓意:为了代码优化和更好的维护，在任何编程环境中，重视组织的目标都比重视个人的目标更重要。

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

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

这取决于程序员。有些人实际上喜欢听到“这太糟糕了”，因为他们知道代码很臭，但不知道为什么。

其他程序员需要更多的照顾。我发现告诉他们坏事是好的;“这不是写代码的好方法”，然后是一些指导“这里，看看我们是否这样做，它更可读/更少警告/诸如此类”。建设性的批评是有帮助的;如果你不能说到做到，最好不要评论，即使你知道这是不好的。

唯一一个两种方法都失败的人是一个固执的行政助理，他用VBscript写了大量的宏，一切都是逆向的。她竟然厚颜无耻地告诉我，我对计算机编程一窍不通，我可以向她学习。