我和和我一起工作的人有类似的情况。他们不像我那样接触编码，但他们在编码方面仍然很有用。

而不是我让他们做他们想做的然后回去编辑整篇文章。我通常只是让他们坐下来，告诉他们两种做事的方法。他们的方式和我的方式，从这里我们讨论了每种方法的优缺点，因此对我们应该如何进行编程有了更好的理解和更好的结论。

这是真正令人惊讶的部分。有时他们会提出一些连我都不知道答案的问题，经过研究，我们都对方法论和结构有了更好的概念。

讨论。 告诉他们为什么 甚至不要认为你总是对的。有时甚至他们也会教你一些新东西。

如果我是你，我也会这么做

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

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

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.

通过例子。告诉他们正确的道路。

慢慢来。不要因为他们的每一个小错误就立刻痛斥他们，要从真正重要的事情开始。

我和和我一起工作的人有类似的情况。他们不像我那样接触编码，但他们在编码方面仍然很有用。

而不是我让他们做他们想做的然后回去编辑整篇文章。我通常只是让他们坐下来，告诉他们两种做事的方法。他们的方式和我的方式，从这里我们讨论了每种方法的优缺点，因此对我们应该如何进行编程有了更好的理解和更好的结论。

这是真正令人惊讶的部分。有时他们会提出一些连我都不知道答案的问题，经过研究，我们都对方法论和结构有了更好的概念。

讨论。 告诉他们为什么 甚至不要认为你总是对的。有时甚至他们也会教你一些新东西。

如果我是你，我也会这么做

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

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

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

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