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

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

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

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

我建议对这个问题采取积极的态度。与其指责你的同事使用糟糕的风格，不如就风格和评论准则提出一些建议，让你的整个团队都能遵循。

例如，如果你主要是一个。net商店，建议坚持微软的c#风格和注释指南，因为这将使你更符合社区的标准实践。

您还可以指出一些遵循统一代码风格的例子——例如，如果不熟悉代码库的人查看了它，他们就不必破译多种风格。可以这样想:如果你正在读一本书，很容易看出每一章都是由不同的人写的，你会在读了几章后感到困惑吗?

我认为重要的是不要用消极的方式批评你的同事。最好是向人们推销改变的好处，这比说服他们写的是糟糕的代码要容易得多。

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

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

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

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

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

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

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

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

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

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

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

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

坦白地说，我相信当某人的代码更容易修改、调试、导航、理解、配置、测试和发布时，他的代码就会更好。

也就是说，我认为不可能告诉某人他/她的代码不好，而不先让他/她解释它是做什么的，或者任何人应该如何增强它(比如，创建新功能或调试它)。

只有到那时，他们的大脑才会崩溃，任何人都能看到:

全局变量值的变化几乎总是不可追踪的 庞大的函数很难阅读和理解 模式使您的代码更容易增强(只要您遵守它们的规则) (等)

也许一段结对编程就能达到目的。 至于执行编码标准——这是有帮助的，但它们离真正定义什么是好代码还很远。