在团队环境中工作，您将如何处理拒绝遵循团队定义标准的开发人员？
开发人员处于初级水平
开发者处于同等水平
开发者处于高级水平
我知道这是主观的，但我认为这将使开发人员更加专业，从而使他们受益。
【问题讨论】：
1) 开发人员处于初级水平 - 导师;善良温柔。解释对一般标准的需求，然后解释对未遵循的特定标准的需求。以开放的心态做这件事；如果您不能证明该标准的合理性，那么也许它不应该成为标准？
2) 开发者处于同等水平 - 这应该很容易——如果你能保持技术性，而不是让它陷入个性冲突。再说一次，如果你能证明它的合理性，它可能应该是一个标准，但如果他有同样令人信服的反对理由，那么也许不是。但是，不接受不应该有标准。要求他提出一个建议的标准来替换他不喜欢的标准。如果他不遵守，那就升级。如果您不喜欢它，请进行投票/升级。尽量避免升级，但尽量确保有标准。
3) 开发人员处于高级水平 试着讲道理。仔细听，他可能是对的。如果有疑问，则将其付诸表决/升级。
警告：标准很好（imo，绝对需要，但是 ymmv），但除非达成共识，否则很难“强制执行”。
例外：“cowboy coders”需要被打倒hard；没有期望。
不要因为跟老板“闲聊”而感到难过。当谈到牛仔程序员时，请遵循牛仔座右铭“这个团队对我们俩都不够大”；要么他停止牛仔，要么你们中的一个人必须摆脱道奇。
【讨论】：
结对编程可能是我最好的建议，因为这有助于确保每个人都达到相同的水平，并有助于在团队中培养社区意识。这确实在一定程度上转移了责任，但其想法是让某人尝试让对方按照其他人的方式做事。 How to Win Friends and Influence People 有以下几点可能适用，尽管这些都是一般性的：
处理人的基本技巧
- 不要批评、谴责或抱怨。
- 真诚地表示感谢。
- 唤起对方的渴望。
让人们喜欢你的六种方法
- 真正对他人感兴趣。
- 微笑。
- 记住一个人的名字对他来说是最甜蜜和最重要的 任何语言的声音。
- 做一个好的倾听者。鼓励他人谈论自己。
- 从对方的兴趣出发。
- 让对方觉得自己很重要，并且真诚地去做。
让人们接受你的思维方式的十二种方法
- 避免争论。
- 尊重他人的意见。永远不要告诉别人 他们错了。
- 如果您错了，请迅速而坚决地承认。
- 以友好的方式开始。
- 从其他人会回答是的问题开始。
- 让其他人说话。
- 让对方觉得这个想法是他/她的。
- 尽量诚实地从他人的角度看待问题。
- 同情对方。
- 诉诸崇高的动机。
- 戏剧化你的想法。
- 拒绝挑战，当对方处于不利地位时不要说消极 缺席，只谈正面。
成为领导者：如何改变 没有冒犯的人或 引起反感
- 从赞美和真诚的欣赏开始。
- 间接引起对他人错误的关注。
- 先谈谈自己的错误。
- 提问而不是直接下达命令。
- 让对方挽回面子。
- 表扬每一项改进。
- 给他们一个不负众望的美誉。
- 通过让他们的错误看起来很容易纠正来鼓励他们。
- 按照您的建议让对方高兴。
【讨论】：
如果有一个标准文档，那么只需指向该文档并告诉他们他们需要遵守该标准。如果没有适当的文档并且它是一种临时的“这实际上是这个团队一直在编码的方式”，那么组织一次会议就团队标准应该是什么达成共识并创建一个标准文档。我认为为了可读性和可维护性而需要一致的风格是相当困难的，而且当有规则说“这样做”时，与它背道而驰要困难得多。只是既定的做法。
【讨论】：
我们使用 TFS 和代码签入策略来执行代码标准。对于其中的人，我完全同意其他回答。对于变量命名标准等一些编码标准，您可以花一点时间（也许有问题的开发人员可以编写这些）并编写这些。如果您将它们合并到您的构建过程中，那么构建验证的一部分涉及检查源代码是否正确。我们将 MSBuild 与 Visual Studio 2008 一起使用，效果很好。当开发一个系统来执行标准时，这将有所帮助，因为有时很难与构建系统争论。此外，它有助于让构建将这些违规行为视为 Visual Studio 中的错误，而不仅仅是进一步执行的警告。最重要的是，标准的“为什么”部分对于任何级别的开发人员来说都是最重要的。如果他们了解标准为何有用并了解正确的论坛/机会（每月开发会议？），他们可以在其中针对特定标准提出推理，希望他们可以与成功的团队一起开始遵循这些标准。
【讨论】：