如何说服程序员遵守基本规则

我必须一直要求程序员经常遵循几个规则。他们为他们编写代码，如果可行，那么工作就完成了。最基本的规则可能是：

• 进行变更
• 不在View或Controller中编写模型问题
• 避免硬编码

能告诉我您的经历吗？您如何处理？

所有知识工作者都必须受到挑战才能进行高质量的工作。如果他们觉得受到时间限制，质量就会受到影响。当每个人都在关注满足规范和按时完成任务时，为什么不仅仅做“足够好”的事情呢？

您的投诉清单是一家公司的症状，该公司仅奖励达到短期目标而无意强调高质量的公司。您是在经营五星级酒店还是在卡车停靠站？

为了能够遵循基本规则，他们需要知道什么是规则，并且需要与他们达成一致。

处理此问题的方法是共同创建每个人都可以接受的编码指南文档。不要试图强加于他们，如果这样做会适得其反。

因此，请团队团结起来，开始研究基本规则的通用定义！

作为在车间里听到所有声音的研讨会来做。设置时间以避免无休止的讨论。您正在尝试汇集各种想法，因此您可能要以积极的态度为大家做好准备，即大家都应该尊重并保持开放的态度（代码编写是个人的……）。

每当团队认为需要添加或澄清某些内容时，这些准则就应该不断修改。

您的角色是什么？如果您只是对代码质量特别感兴趣的另一位开发人员，则您可能无权要求他们听取您的意见，也许您应该将这些想法提请管理层，以建立应该/必须遵循的代码标准。跟着。如果您是经理/团队负责人/架构师，并且拥有一定权限，则可以自己建立这些做法。建立标准文档和代码审查过程以清除这些问题。

您可以打开它不会是一个魔术开关；这将是一个缓慢的过程，而且永远不会100％完成。无论如何，这都是我的经验。

到目前为止，它必须是所有答案的明智组合。最后，当你在谈论一群聪明人（开发商），你必须给他们的原因的行为是很重要的，让他们在足够的控制如何行为是实现他们投资于这样做的权利。上面的任务通常对聪明的人来说太松散了，因为如果他们不同意问题是问题，那么他们可能会比执行规则花费更多的时间来执行任务。

这是我的一些战术：

提交更改：

首先，团队需要就何时承诺以及承诺什么达成共识。绝对必要的是有意义的构建设置，这样人们就不会因为不知道在哪里放置东西而推迟。关于何时/多久检查一次的共识。“不要破坏构建”是一个明显的好规则，但是如何检查它，以及谁被告知呢？另一个基准是“如果未签入，则不会完成”。

我认识的大多数开发人员都非常乐于签入IF代码：

• 签入过程很容易
• 同步过程很容易（将其他开发人员的更改考虑在内）
• 轻松查看更改并在版本之间移动

我最近注意到的一件事是，当我们倾向于使用新的CM工具时，签入变得更加频繁且痛苦更少。我们的团队是以前使用过Clearcase的Rational Team Concert的开拓者。我并不是要宣传工具，但是（对我而言）新的流式签入浪潮中包含许多小型，快速合并，这使得它更容易吸引人们早早签入。

让开发人员负责消除CM痛苦通常会增加这种情况下的签入量。

坚持架构-不在视图和控制器中编写模型问题

我将其放在“正确构建体系结构”的总体中。无论谁说同行评议，我都同意-同行的压力对此很有帮助。我通常会看到人们寻求这一领域最佳实践的一种方式是，当同龄人问他们为什么以另一种方式（不是那么正确的方式）这样做时。通常，“为什么”问题会引导人们沿着自己的道路去认识为什么他们应该做不同的事情。当人们对最佳实践有充分了解的原因时，遵守它会容易得多。

另外，如果有某种形式的流程将一个人链接到一个决策，那么在该区域分配错误可能会更容易...因此，如果一个人负责修复错误设计区域中的错误，则需要在解决之前进行正确处理他们可以继续前进一些新事物，而激动人心的事情可能是一个巨大的动力。

避免硬编码

我将从清晰的编码标准开始，然后将编码标准审查集成到同行审查中。硬编码是很容易成为同行评审议程中一个复选框的事情之一。

恐怕这种事情是我所看到的一件事，它已成为导致团队执行规则的角色。在我所运营的团队中，我们通常不会让某人继续前进，直到他们修复了来自其代码的同行评审的评论。而“没有硬编码”是同行评审的常见评论。

一般来说

凭借几乎所有最佳实践，我认为您必须选择自己的战场。没有团队会变得绝对完美。但是，您可以留意主要的痛点，然后开始集中解决。我认为真正了解团队的痛苦点与特定个人的烦人怪癖成为领导者的角色。

如果您的团队错过了做某项最佳实践的机会，我认为第一个问题必须是“这会造成多少损失？” 如果答案是“最小”，则可能不值得花时间。一些最佳实践与特定类型的系统最相关-尽管它们总体上不错，但对于不经常发生或不占系统主要部分的系统而言，它们可能不值得一战。

如果回答“多少钱？” 是“很多！！”，那么您可以开始构建一个案例，向团队展示通过解决最佳实践中的这一懈怠点可以消除所有这些痛苦和痛苦。大多数人都乐于避免痛苦和痛苦，并将对话从“因为我告诉过你这样做”改为“我们决定这样做是因为更好”。

代码审查。仅接受编写正确且没有错误的代码。

至少 ：

• 使他们更容易遵循代码行（如resharper，StyleCop之类的工具）。如果很容易，他们就更容易采用。

除此之外，还可以根据您的组织，开发人员和您在团队中的角色选择有效的方法。

• 让他们修复错误并定期更改请求
• 与经验丰富的开发人员配对程序
• 以建设性的方式进行代码审查
• 代码演练
• 开始培训，使用诸如《代码完成》和《实用程序员》等书籍。

我的角色是经理，但作为一个小团队，我确实会发展，而我更喜欢以教练的身份进行管理。

已经指出了连接到代码解析器的椅子上的电极，但是程序员似乎并不害怕。射击听起来不是一个好方法，因为这意味着失去有价值的资产。

我将看一看所有这些工具，并对您告诉我的任何其他工具保持开放态度。

我们通过3种方式解决此问题：

1. 静态分析源代码以检查编码约定问题。使用cppcheck之类的工具以及来自grammatech的工具。维基百科上有一个不错的列表：http : //en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis。通常，大多数源代码控制系统都会带有钩子，通过这些钩子，您可以在签入期间直接检查此类问题。对于CVS挂钩，请查看以下链接：http : //goo.gl/F1gd2。不遵守则意味着检入失败，而超过3次失败则意味着开发人员必须向团队解释自己。

2. 在编码过程中，它本身会将问题标记给开发人员。将自定义脚本与您选择的IDE集成在一起是一种很不错的方法。检查此链接：http : //goo.gl/MM6c4

3. 遵循敏捷流程，并确保代码审查是冲刺的一部分

这是我的三步计划：

1. 解雇程序员
2. 雇用一些软件工程师
3. ...
4. 利润！

：D

认真地说，如果他们不相信除了编写代码之外就要做任何事情，那么您需要一个更全面的团队。我所在的程序员在计算机上使用了不同的目录作为她的CM。我们与他们的程序员奋斗了近一年（因为更改会在复制和粘贴旧代码时引入错误）。我们最终只是解雇了他们。

1. 当它们违反基本规则时，要向他们指出。
2. 等待他们产生他们无法追踪的错误，或者由于代码不灵活而无法实现的功能请求。
3. 提醒他们您先前说的话。
4. 让他们淹死一会儿。
5. 花时间重构有问题的代码，隔离错误/提供基础设施以插入新功能。花一些时间来解释你做了什么。

另外，最残酷但非常有说服力的事情是，在时间表紧张的情况下，让他们保持极差的编写代码库。：D
然后，要进行更改，请让他们在时间表紧张的情况下维护编写良好的代码库。

通常，不愿意采用某些标准意味着缺乏团队合作经验。

最终，人们只能从错误中学习。永远不要解决基于别人的固执的问题。如果对项目确实至关重要（例如，如果您在N天内未交付，则将起诉您的公司），那么请先将其从该项目中删除。

我认为您的程序员不会改变他们对您提到的这些问题的态度，除非他们意识到这些事情将为他们带来好处或优势。尝试向他们解释为什么您要他们做这些事情。更好的是，让他们体验优势。

雇用一名专业软件工程师。然后火势最弱。然后慢慢替换那些不能采用的人。从长远来看，拥有这样的人有时带来的弊大于利。

这里的主要思想是，专业人员将开始做大多数工作，而解雇其他人不会减少宝贵的人力资源。

有点毛病，但是我将Code Complete留在了浴室几个月。不确定它是否有效，但在当时似乎是个好主意。

那么，不遵守规则会产生什么后果，而遵守规则则会产生奖励呢？如果答案相同-什么都没有-祝你好运。我建议采用分层方法。首先将他们聚在一起，讨论他们是否遵守规则。下一步是将它们包括在代码审查中。您也可以尝试胡萝卜和棍子。就像任何人在一夜之间离开档案的人一样，必须将甜甜圈带入下一次每周会议。胡萝卜可以是任何遵循整个月规则的人都可以在拉斯维加斯度过一个周末。两个。

或开除最严重的罪犯，让其余的人流汗。

通过使用这些规则，使他们忍受要避免的麻烦，这是他们真正了解您为什么要问的唯一方法，例如：制造一个小小的受控混乱，他们必须纠正。

如果这个工作人员确实在检查更改时遇到麻烦，坚持关注点的分离，而不是硬编码魔术常数，那么我将解雇整个工作人员，并用真正关心他们技能的真正程序员¹代替。是一次一个或集体我不能说，但这些笑话都得走了。

您所描述的编码类型适合一次性使用的一次性脚本。这不是构建真正的应用程序的方式。如果他们以专业程序员的身份获得报酬，那么了解这类事情就是他们的工作。

¹这通常是假想的人的笑话，他们直接用二进制或同样荒谬的方式编写代码。在这里，我不是在开玩笑。我是一个相当新手的程序员，不需要因为我在乎我的技能而被告知这些事情。这些不是您要处理的真正的程序员。

经理的工作不是成为员工的朋友，有时您必须成为坏人。强制执行编码标准和提交，拒绝遵循复杂的体系结构，不使用规定的工具等都是您不受欢迎的时候。

明确表达政策。进行正式的代码审查，并检查是否遵守政策。在裁定所有来自代码评审的问题之前，不要让他们转移到其他任务。

如果该策略涉及不提交代码，则当他们被要求这样做时，如果他们不能这样做，则要求发出书面警告。如果他们不提交代码，那么就您而言，他们还没有编写任何代码。

如果在获得合理的改善机会后仍未改善，请开除他们。无论他们编写哪种代码，非专业的开发人员都会拖累您的团队。他们缺乏专业精神正在影响他人，这是不容忍的。他们无论如何都不是好人。好的开发人员会提交他们的代码，好的开发人员会遵循体系结构的决定，即使他们不同意它们，并且好的开发人员也不会硬编码。通过摆脱牛仔编码员，除了头痛之外，您将不会错过任何其他东西。