激励同事采用更好的编码实践？
在“ 处理我过时的同事”问题中，许多人讨论了与不愿将工作流与团队的工作流程整合在一起的同事打交道的策略。 我想，如果可能的话，学习一些策略来“教”一位不了解现代技术和工具的同事，并且可能有些冷漠。 我已经开始与一位程序员合作，直到最近，他一直在公司的不同部门进行相对隔离的工作。他具有丰富的领域知识，最重要的是，他展示出了很好的解决问题的能力，而这是许多候选人似乎所缺乏的。 但是，我看到的实际（C＃）代码是对VB6天的回顾。程序结构，匈牙利符号，全局变量（的滥用static），没有接口，没有测试，不使用泛型，抛出System.Exception...您就会明白。 这个程序员比我年龄大一点，至少从第一印象来看，他并没有积极寻求积极的改变。我不会说要抗拒变革，因为我认为这很大程度上是有关如何提出主题的问题，我想做好准备。 程序员往往是固执的人，大肆宣传，建立撕碎的代码审查和严格执行的政策很可能不会产生我想要的最终结果。如果这是一个新员工，一个初级程序员，那么我不会三思而后行地采取“导师”的立场，但是我非常谨慎地将有经验的员工视为无知的新手（他不是-他只是没有与该领域的某些进步保持同步）。 我如何通过柔和的说服力和非实质性的激励措施以Dale Carnegie的方式提高开发人员的代码质量标准？在不造成对抗性情况的情况下，进行细微，渐进式变化的最佳策略是什么？ 之前是否有其他人（尤其是首席开发人员）遇到过这种情况？哪些策略成功地激发了兴趣并创造了积极的群体动力？哪些策略没有成功，会更好地避免？ 说明： 我真的觉得有些人是根据个人的感觉来回答的，而没有真正阅读问题的所有细节。请注意以下内容，这些内容本应暗示，但我现在要明确指出： 由于年龄的原因，这个同事只是我的“高级”。我从未说过他的头衔，势力范围或在该组织的任职年限超过我，而实际上，这些都不是真的。他是一名LOB程序员，已经被主要开发部门所吸引。而已。 我不是新员工，也不是初级程序员，也不是其他幼稚的白痴，他们都计划在一夜之间将公司转型。我基本上负责软件过程，但是正如许多作为“潜在客户”工作过的人所知道的那样，职责并不总是与组织结构图完全相关。 我不是在问别人如何走我的路，来死还是要高水。如果我愿意，我可以这样做，最终结果是这个人会变得不满和/或辞职。请尝试了解我正在寻找一种社交，合作的方式来推动变革。 提到“ ...全局变量...没有测试...抛出System.Exception”是为了证明问题不仅是表面的或美学的。可能适用于相对较小的CRUD应用程序的做法不一定适用于大型企业应用程序，实际上，到目前为止，没有代码实际通过了集成测试。 请尝试从表面上看待这个问题，接受我实际上知道我在说什么，然后回答我实际提出的问题或继续前进。 PS对那些提供建设性建议而不是与前提争论的人，我表示由衷的感谢。我希望将其保留一段时间，因为我希望能从现实生活中听到更多。