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

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

糟糕的命名习惯:总是不可原谅的。

是的，不要总是认为你的方式更好……这可能很困难，但必须保持客观性。

I've had an experience with a coder that had such horrible naming of functions, the code was worse than unreadable. The functions lied about what they did, the code was nonsensical. And they were protective/resistant to having someone else change their code. when confronted very politely, they admitted it was poorly named, but wanted to retain their ownership of the code and would go back and fix it up "at a later date." This is in the past now, but how do you deal with a situation where they error is ACKNOWLEDGED, but then protected? This went on for a long time and I had no idea how to break through that barrier.

Global variables: I myself am not THAT fond of global variables, but I know a few otherwise excellent programmers that like them A LOT. So much so that I've come to believe they are not actually all that bad in many situations, as they allow for clarity, ease of debugging. (please don't flame/downvote me :) ) It comes down to, I've seen a lot of very good, effective, bug free code that used global variables (not put in by me!) and great deal of buggy, impossible to read/maintain/fix code that meticulously used proper patterns. Maybe there IS a place (though shrinking perhaps) for global variables? I'm considering rethinking my position based on evidence.

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

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

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

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

我总是说‘这就是我要做的’。我不会试图教训他们，告诉他们他们的代码是垃圾，而只是给他们一个不同的观点，希望能向他们展示一些明显更整洁的东西。

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

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