在Gerry Weinberg的书《计算机编程心理学》中有一些非常好的建议——他的“无我编程”的整个概念都是关于如何帮助人们接受对他们代码的批评，而不是对他们自己的批评。

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

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

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

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

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

介绍代码标准的思想。关于代码标准最重要的事情是它提出了代码库的一致性(理想情况下，所有的代码都应该看起来像由一个人一次编写的)，这将导致更容易理解和可维护的代码。

这里的许多答案都与代码格式有关，但现在并不是特别相关，因为大多数ide将按照您选择的样式重新格式化代码。真正重要的是代码是如何工作的，海报是正确的查看全局变量，复制和粘贴代码，以及我的烦恼，命名约定。糟糕的代码是存在的，这与格式没有多大关系。

好的方面是，大多数情况下都有很好的原因，这些原因通常是可量化和可解释的。所以，用一种非对抗性的方式解释原因。在许多情况下，您甚至可以为作者提供问题变得明显的场景。

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

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