与不遵循团队定义标准的队友合作的想法？
在团队环境中工作，您将如何处理拒绝遵循团队定义的标准的开发人员？
开发人员处于初级水平
开发人员处于同行水平
开发人员处于高级水平
我知道这是主观的，但我认为这将使开发人员更加专业，从而使他们受益。
Working in a team environment how would you handle a developer that refuses to follow team defined standards?
Developer is at a junior level
Developer is at a peer level
Developer is at a senior level
I know this is subjective but I feel that it would benefit developers by making them more professional.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
1）开发人员处于初级水平
- 导师;友善&温和的。解释一般标准的需求，然后解释未遵循的特定标准的需求。以开放的心态去做这件事；如果你不能证明该标准的合理性，那么它也许不应该成为一个标准？
2）开发者处于同行水平
- 这应该很容易 - 如果你能保持技术性并且不让它陷入个性冲突。再说一次，如果你能证明它是合理的，它可能应该成为一个标准，但如果他有同样令人信服的反对理由，那么也许就不是。但是，不要认为不应该有标准。请他提出一个建议的标准来替换他不喜欢的标准。如果他不遵守，那就升级。如果您不喜欢它，请对其进行投票/升级。尽量避免升级，但尽量确保有一个标准。
3）开发人员处于高级水平
尝试讲道理。仔细听，他也许是对的。如有疑问，请进行投票/升级。
警告：标准很好（在我看来，绝对是必需的，但是ymmv），但除非达成共识，否则很难“执行”。
例外：“牛仔程序员”需要被重击；没有期望。
不要因为向老板“流言蜚语”而感到难过。当谈到牛仔编码员时，请遵循牛仔座右铭“这个团队对我们俩来说还不够大”；要么他停止牛仔，要么你们中的一个人必须离开道奇。
1) Developer is at a junior level
- Mentor; be kind & gentle. Explain the need for standards in general and then explain the need for the particular standard which is not being followed. Do this with an open mind; if you cannot justify the standard then perhaps it ought not to be a standard?
2) Developer is at a peer level
- this ought to be easy enough – if you can keep it technical and not let is dissolve into a clash of personalities. Again, if you can justify it, it probably ought to be a standard, but if he has an equally compelling argument against, then maybe not. However, do not accept that there ought to be no standard. Ask him for a suggested standard to replace the one which he does not like. If he will not comply, then escalate. If you don’t like it, then put it to the vote/ escalate. Try to avoid escalation, but try to ensure that there is a standard.
3) Developer is at a senior level
Try to reason. Listen carefully, he may be right. If in doubt, then put it to the vote/ escalate.
Caveat: standards are nice (imo, absolutely required, but ymmv), but they are difficult to “enforce” unless reached by consensus.
Exception: “cowboy coders” need to be slapped down hard; no expectations.
Do not feel bad about “tattling” to the boss. When it comes to a cowboy coder then follow the cowboy motto “this team ain’t big enough for both of us”; either he stops cowboying or one of you has to get the hell out of Dodge.
结对编程可能是我最好的建议，因为这可以帮助确保每个人都达到相同的水平，并有助于培养团队内的社区意识。这确实在某种程度上转移了责任，但其想法是让某人尝试让另一个人按照其他人的方式做事。 如何赢得朋友并影响别人有以下几点，尽管这些是一般性的，但可能适用：
Pair programming may be my best suggestion as this can help ensure everyone gets up to the same level and help foster a sense of community within the team. This does shift responsibility to some extent but the idea is to have someone try to get the other person to do things the way others do it. How to Win Friends and Influence People has the following points that may apply though these are general:
如果有标准文件，则只需指向该文件并告诉他们需要遵守该标准。如果没有适当的文档，并且它是一种临时的“这就是该团队事实上的编码方式”，那么组织一次会议，就团队标准应该是什么达成共识，并创建一个标准文档。我认为为了可读性和可维护性而需要一致的风格是相当困难的，并且当有规则说“这样做”时，偏离它比它更难只是既定的惯例。
If there is a standards document in place, then simply point to the document and tell them that they need to adhere to the standard. If there is no document in place and it is sort of ad-hoc "this is de-facto how this team has been coding", then organize a meeting to create a consensus on what the team standards should be and create a standards document. I think it is fairly hard to argue with the need for a consistent style for the sake of readability and maintanence, and when there are rules in place saying "do it this way", it is much harder to diverge from it than if it is merely established practice.
我们使用 TFS 和代码签入策略作为执行代码标准的一种方式。对于其中的人员部分，我完全同意其他答复。对于某些编码标准（例如变量命名标准），您可以花费一点时间（也许相关开发人员可以编写这些）并编写它们。如果将它们合并到构建过程中，那么构建验证的一部分涉及检查源代码是否正确。我们将 MSBuild 与 Visual Studio 2008 结合使用，效果非常好。当开发一个系统来执行标准时，这会有所帮助，因为有时很难与构建系统争论。此外，它有助于构建将这些违规视为 Visual Studio 中的错误，而不仅仅是进一步执行的警告。最重要的是，标准的“原因”部分对于任何级别的开发人员来说都是最重要的。如果他们了解标准为何有用并了解正确的论坛/机会（每月开发会议？），他们可以在其中针对特定标准提出推理，希望他们可以开始与成功的团队一起遵循这些标准。
We use TFS and Code Check-in policies as a way to enforce code standards. The other responses I agree with completely for the people part of it. For some coding standards like variable naming standards, you can spend a tiny bit of time (maybe the dev in question can write these) and write these. If you incorporate them into your build process, then part of the validation of a build involves checking the source for correct code standards. We use MSBuild with Visual Studio 2008 and it works great. That will help somewhat when a system has been developed to enforce standards as it's harder to argue with a build system sometimes. Also, it helps to have the builds treat those violations as errors in visual studio rather than just warnings for further enforcement. Above all, the "why" part of the standards are most important for a developer of any rank to udnerstand. If they understand why standards are useful and understand the right forum/opporunity (monthly dev meeting?) where they can voice reasoning against a particular standard, hopefully they can begin to follow them alongside the successful team.