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

与其让他们写代码，不如让他们维护代码。

除非他们不得不维护他们那堆冒着热气的意大利面，否则他们永远不会明白自己在编码方面有多糟糕。

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

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

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

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

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

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

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

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

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

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