激励同事采用更好的编码实践？

在“ 处理我过时的同事”问题中，许多人讨论了与不愿将工作流与团队的工作流程整合在一起的同事打交道的策略。

我想，如果可能的话，学习一些策略来“教”一位不了解现代技术和工具的同事，并且可能有些冷漠。

我已经开始与一位程序员合作，直到最近，他一直在公司的不同部门进行相对隔离的工作。他具有丰富的领域知识，最重要的是，他展示出了很好的解决问题的能力，而这是许多候选人似乎所缺乏的。

但是，我看到的实际（C＃）代码是对VB6天的回顾。程序结构，匈牙利符号，全局变量（的滥用static），没有接口，没有测试，不使用泛型，抛出System.Exception...您就会明白。

这个程序员比我年龄大一点，至少从第一印象来看，他并没有积极寻求积极的改变。我不会说要抗拒变革，因为我认为这很大程度上是有关如何提出主题的问题，我想做好准备。

程序员往往是固执的人，大肆宣传，建立撕碎的代码审查和严格执行的政策很可能不会产生我想要的最终结果。如果这是一个新员工，一个初级程序员，那么我不会三思而后行地采取“导师”的立场，但是我非常谨慎地将有经验的员工视为无知的新手（他不是-他只是没有与该领域的某些进步保持同步）。

我如何通过柔和的说服力和非实质性的激励措施以Dale Carnegie的方式提高开发人员的代码质量标准？在不造成对抗性情况的情况下，进行细微，渐进式变化的最佳策略是什么？

之前是否有其他人（尤其是首席开发人员）遇到过这种情况？哪些策略成功地激发了兴趣并创造了积极的群体动力？哪些策略没有成功，会更好地避免？

说明：

我真的觉得有些人是根据个人的感觉来回答的，而没有真正阅读问题的所有细节。请注意以下内容，这些内容本应暗示，但我现在要明确指出：

• 由于年龄的原因，这个同事只是我的“高级”。我从未说过他的头衔，势力范围或在该组织的任职年限超过我，而实际上，这些都不是真的。他是一名LOB程序员，已经被主要开发部门所吸引。而已。

• 我不是新员工，也​​不是初级程序员，也不是其他幼稚的白痴，他们都计划在一夜之间将公司转型。我基本上负责软件过程，但是正如许多作为“潜在客户”工作过的人所知道的那样，职责并不总是与组织结构图完全相关。

• 我不是在问别人如何走我的路，来死还是要高水。如果我愿意，我可以这样做，最终结果是这个人会变得不满和/或辞职。请尝试了解我正在寻找一种社交，合作的方式来推动变革。

• 提到“ ...全局变量...没有测试...抛出System.Exception”是为了证明问题不仅是表面的或美学的。可能适用于相对较小的CRUD应用程序的做法不一定适用于大型企业应用程序，实际上，到目前为止，没有代码实际通过了集成测试。

请尝试从表面上看待这个问题，接受我实际上知道我在说什么，然后回答我实际提出的问题或继续前进。

PS对那些提供建设性建议而不是与前提争论的人，我表示由衷的感谢。我希望将其保留一段时间，因为我希望能从现实生活中听到更多。

起点是了解您的听众。您似乎已经了解了这一点，因为您知道指导初级同事和影响高级同事之间的区别。

您仍然需要弄清楚是什么激发了这个特定的人。适用于一个旧geezer（如我）的内容可能不适用于您的旧geezer。

如果他喜欢指导/教别人，您可以问 “为什么要这样做”这样的问题来解决这个问题。这样可以进行对话，您可以要求他评估更新的方法并给出他的意见。

如果那不起作用，您可以指出可以通过使用您希望他采用的实践或样式来避免的错误。这需要做更多的工作，因为您必须查找错误并说明想要鼓励的行为将如何帮助您。

如果他似乎愿意帮助别人，您可以诉诸他帮助新手的愿望。解释说“今天的孩子”并不习惯于看到他的编码风格，因此更有可能破坏他的代码。

有时您可能只需要面对他并强迫问题。您需要仔细挑选这些战斗。确保您从一个主题开始，在此您可以向他证明自己有更好的方法。

我认为您的态度正确。只要确保指出您已经说过的所有好话-出色的解决问题能力，对业务的精明掌握等，然后请他花一点时间向他展示该小组的当前标准并给他机会问一些有关他们的问题。

当您聚在一起时，给他喝杯咖啡或其他东西，让他知道按照标准进行工作将使他更容易支持您现有的代码，并且如果有人愿意帮助他，也将使他更容易获得帮助，这将使他受益。被工作掩盖（对一直孤立工作的人来说是一大好处），等等。

确保他参与并获得很好的解释，以解释为什么您要做自己做的事情，而不是专注于为什么他不应该做自己正在做的事情，如果需要的话请其他人让他们向您解释。如果他有任何疑问和后续行动，请在之后的几个地方让自己有空，他可以参考一些地方作为您的标准示例。

如果此后他不感兴趣，那么您可以参考您链接的第一个问题。

确实是您经理的工作

1. 意识到公司必须具有编码标准。不论公司规模大小，每家有些专业的公司都拥有这个。
2. 让大家坐在一起，开始制定标准。这样，每个人都可以发表自己的意见，然后他们会更有动力去遵循标准。

如果您的经理自己没有意识到这一点，那么他们就没有工作资格。如果是这样，您应该在上述两个方面给他们一些微调。拥有一种编码标准的优点是如此之多，实际上并没有反对的理由。（如果某些程序员认为他们是“艺术家”，不应受到专业精神的限制，那么他们应该找一份从事美术的工作。）

编码标准本身应该首先集中于禁止危险的操作和危险的库功能。努力使您使用的语言更安全，更纯正。保持编码标准不受“编码样式”的影响，因为编码样式很难达成共识，而且不那么重要。公司决定制定编码标准，然后立即陷入关于{}括号放置位置的激烈讨论，这是非常经典的。

作为参考，请查看如何编写MISRA-C / C ++和CERT C / C ++ / Java标准。

首先，您需要澄清为什么要更改此人的工作方式。如果仅仅是出于美学原因，我认为您应该重新考虑，因为这个人已经证明了他的工作方式确实有效。

但是，如果有技术原因，则应考虑通过以下方式与所述人员联系：

我对如何为您节省繁琐的时间和为公司节省金钱提出了建议。你感兴趣吗？

请注意，这应该是低落的果实，因为它们很可能需要改变现有的习惯，而这总是需要额外的努力。

即使您有成千上万的建议，也只需选择一两个，然后证明这将是一个更好的改变。

要么行得通，然后询问您是否有更多建议，否则将不行，然后将损害限制为一个或两个建议。

请注意，成功并迅速完成非常重要。

另外，您需要小心。有可能是非常做事他们这样做的方式很好的理由，但你是太新，所看到的原因。因此，请尊重您的长者，并在您认为您的建议更好之前先提出询问。您可能会学到一两个东西。

我要严重劝阻您不要面对他，因为这会使情况迅速恶化。我意识到它是作为最后一种措施提出的，但是根据我的经验，在这一点上，开发人员已停止参与功能。

强迫问题可能会使个人变成敌人，他们将在您采取的所有行动中进行战斗。这确实会对团队产生负面影响，并且直到有人退出或被解雇才结束。

如果此人确实拥有您需要/想要的领域知识，则请他们记录该知识。

从轻轻地给他打断开始：我不知道您在提供反馈方面有多丰富的经验和精通。您可能已经知道，雇用甚至拒绝了以下内容，但是无论如何都可以进行。有一些准则可以在您要更改某人的行为时提供反馈。我一直在考虑以下对话结构，并且在我想提供反馈（因为它们起作用）的情况下仍然尝试使用以下结构：

1. 描述您看到的行为。这必须是具体的行为。示例：“我发现您在代码中使用了很多静态变量”
2. 描述这对您/您的团队有何影响。示例：“我发现这样的代码难以维护”
3. 提供合理的解决方案。（其他答案中提到了可能的解决方案，稍后我将自己涉猎到该答案中。）
4. 给他机会讨论解决方案。问他对解决方案的看法。以他的回应为荣。您已经给了他您的意见，他可以自由地接受或拒绝。*

例如，可以在http://managementhelp.org/communicationsskills/feedback.htm上找到有关反馈的快速资源（尽管网络上有大量这类东西）

现在在解决方案部分，根据我在您的回答中看到的内容，我发现他非常聪明，并且心态正确，但是在现代良好实践中他仍然落后。除了首先了解它们之外，这些还需要时间和精力来掌握，因此您必须为他提供这样做的机会。这可能意味着收集学习资源（网络，杂志，书籍等）作为起点，并为他提供空闲时间进行学习。我可以想象每个星期五下午都给他，以拓宽他对编程风格的了解，他可以做任何他认为可以促进实现这些目标的事情。人们天生希望提高自己。提供材料和时间，他们将充分利用它。

可能最重要的是，不要指望一夜之间就能改变。他做了很长一段时间的事情，并且可能已经做得很好。在一种新的做事方式上变得很出色将需要一些时间，而且有一段时间，他可能不会在新的方式上看到太多的价值，因为在开始时，没有任何价值。他的旧方法可能会在一段时间内更有效。

*注意：关于对话的有趣之处在于很难建模。他们有自己的生活，因此尽管在纸上看起来不错，但往往会有点混乱。

在项目开始时，请让他进行工作，向其解释您希望如何完成工作，并向他展示如何与您为该项目做出的设计和建筑选择一起工作。一对一地（私下）坐下来，并解释您在他以前的编码中看到的问题，以及为什么它们是该项目的问题。问他要变得更好需要什么，但要明确指出，不变得更好是不可行的。

然后使用代码审查作为一种工具，让他调整自己的工作方式。为第一个计划好一段很长的时间，然后真正谈论为什么你更喜欢这个，然后让他解释他的理由。确保真正听到他的声音，当人们感到自己的担忧已解决时，他们更容易改变。在您的计划中期望（但不要告诉他）对第一个任务进行重做，并且在达到您的团队标准之前不要接受它。一旦他知道了您的期望并且您不会为了时间利益而让它滑倒，他很可能会改变您的工作方式。但是您可能不得不将代码审查作为教育工具进行多次迭代。您不必讨厌在工作达到标准之前不接受工作，但您必须坚定并保持一致。不要

$ 64,000的问题是他是否按时交付项目并满足功能要求。如果是这样，他做对了。在软件开发中，没有客观的对与错。最终，它与解决问题有关。并且，如果解决了客户/客户满意的问题，那么根据定义，软件开发就可以正确完成。

如果他的项目没有完成，这当然将变成完全不同的问题。此时，您的主管可能需要进行更改，也许需要您的输入。但是，仅仅因为他违反了您对代码美学的个人观念或当今的传统观念，并不意味着他正在做的事情是“错误的”。您不是“好代码”定义的提倡者。毕竟，他可能对您的代码不满意。

所以...除非他的工作确实有问题（您尚未指出有问题），否则请不要做任何事情。成为一名成功的开发人员的一部分是学习将您的代码与其他开发人员的样式合并。

毕竟，他可以在这里发表一个类似的问题，即与经验不足的开发人员打交道，后者比起完成项目更关心赶时髦。这全都是关于视角的。

作为初级开发人员与高级开发人员进行交流，您尝试以比他自己的想法更好的想法来接近他的风险太大。

解决此问题的最佳方法是尝试说服您的老板更好的做法，并查看他/她是否会下令所有代码必须遵循特定标准并通过对等代码审阅来强制执行这些标准。

即使他们完全不了解自己的潜意识动机，也有相当一部分人（即使在潜意识层次上）是斗气，自负和防御的，如果您试图改变他们或暗示自己在错误中是错误的，他们将受到攻击。任何方式。

指挥链是最安全的方法，因为他必须听老板的话，也不必喜欢他。让老板当坏人，这就是他的目标。

如果您不能卖掉老板或他是老板，那么只需处理他的错误，而是以您的代码中的示例为先导。

你不能

您不能激发人们去做他们在软件开发中不知道的事情。我的经验是我在职业生涯中经常尝试这样做的结果，每次最终结果都是我的地位在公司眼中消失；一无所获，我什至被解雇或沮丧，仅仅是因为试图将我周围的发展文化改进为现代实践。

如果您的同事不懂事，可以给他们看。但是，由于它们无能为力，因此您无能为力，因为它们没有能力或对软件的工艺水平缺乏足够的重视，无法尝试采用更好的编码实践。如果您尝试的话，他们可能会忽略它，或者在没有真正理解的情况下搞乱，从听起来这就是他们已经在做的事情（“尝试和错误开发”，即只是在代码中乱搞，直到错误停止为止） 。