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

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.

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

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

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

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

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

首先，我会注意不要太快下结论。有些代码很容易被认为是坏的，尽管可能有很好的理由(例如:使用带有奇怪约定的遗留代码)。但让我们暂时假设他们真的很糟糕。

你可以建议建立一个基于团队输入的编码标准。但是你真的需要考虑他们的意见，而不仅仅是强加你对好的代码应该是什么样子的看法。

另一种选择是把技术书籍带进办公室(《代码完成》、《有效的c++》、《实用的程序员》……)，并主动把它借给别人(“嘿，我用完了，有人想借吗?”)

重要的是激励和指导人们，即使有人明显犯了错误，也要表现出尊重。但是，不仅要有指导的方法，而且要有说明错误就是错误的方法。糟糕的代码应该做得更好。这不是可选的。从主管的角度来看，员工应该知道哪些代码是可以的，哪些是不可以的。它仍然应该以尊重和激励那些负责任的人来改善。

我很喜欢代码，在我的生活中从来没有上过任何与信息学相关的课程，我一开始很糟糕，开始从例子中学习，但自从我读了“四人帮”这本书以来，我一直记得并一直在我的脑海中:

“每个人都能写出机器能理解的代码，但不是所有人都能写出人类能理解的代码。”

考虑到这一点，在代码中有很多事情要做;)

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

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