如何转换复制/粘贴/意大利面条式编程器以查看光线？

这个问题的灵感来自于这一块。尽管其他问题被认为是本地化的，但我认为根本问题是我们行业中极为普遍的问题。我知道有一些开发人员会阅读这些内容，并认为我正在编造这些东西，然后他们可能会回答每个人如何关心自己的工作并想学习，但是只是看看其他Programmer SE的帖子（例如），我知道这并非普遍如此。

假设您的团队中有某个人（或可能是多数人），他们的标准操作程序是复制/粘贴，并且相信只要添加足够的函数调用和变量，一切都可以解决。这个人从来没有听说过TDD，DRY或SOLID，并且在忙于工作的40个小时之外，他们从来没有读过任何一本方法论/实践/设计书。

在过去，我（和其他人）曾问过，如何教OOD。但是现在我认为这不是正确的问题。真正的问题是，您如何与这样的人/团队打交道，并使他们对更好的做事方式感到好奇？您如何激励他们学习？没有这些，似乎所有的教学，会议，演讲，讨论都没有用，如果他们很高兴回到办公桌前并做他们一直以来所做的事情。

我和一群这样的人一起工作。他们实际上是非常聪明的人，但是当我听到“我已经完成编码，只需要重构并拆分成多个类以使DXM满意”时，我就会讨厌。它们不会重构更干净，可读性和可维护性的代码，而仅仅是因为否则它们会被责骂。我知道他们有学习能力，只是似乎普遍缺乏动力。

当我交付作品时，它的bug数量通常更少，而我拥有的作品从未成为5000行的怪异行为。其他人会发表评论，例如“您的代码比我们的代码更清晰易读”，因此他们看到了区别。但是与此同时，我觉得他们相信他们不管做什么都可以得到40个小时的报酬，因此他们实际上不介意他们是否花了整整3天的质量检查来寻找不应引入的错误。第一名。或者他们花一个星期来修改一个类，因为最终有太多的依赖关系。但是，“也许该类应该用不同的方式编写”似乎从未弹出。

在这些情况下可以采取任何措施吗？有人成功了吗？还是最好将这种思维方式隔离到项目的非关键部分，并最大程度地减少损失？

注意：当我说“缺乏动力”时。我不认为工作或干得好没有动力，因为他们只是停止了关怀。实际上，我们团队中的大多数人恰恰相反。他们绝对在乎产品。我们有会在晚上和周末工作的人。我要努力克服的部分是改善的习惯和技能，实际上他们不需要那么多的工作。我想“ 40个小时”的事情使这篇文章听起来有些消极。

您发现自己的原因：“我知道他们有学习能力，似乎普遍缺乏动力。”

有些人对他们的工作充满热情。还有其他一些人，有时足够胜任，只是为了赚钱而工作。他们知道自己的东西，但是不喜欢他们的工作。当快速而丑陋的骇客可以胜任这项工作时，他们将不会花费额外的时间进行额外的重构以使代码可读或解决一个有趣的问题。

这种现象存在于每一项工作中。只是有些工作不是特别令人兴奋（您见过一个喜欢他的工作并在他小时候就梦想过的会计师吗？），但是在编程中，有很多人真的很喜欢他们的工作（否则Programmers.SE将非常空白）。这意味着，作为每天与其他热情的开发人员交谈的热情的开发人员，我们有更多的机会惊讶于看到一个只为赚钱而编写程序的人。

我们能做什么？不会太多 在任何情况下，选择真正有动机的人都不是您，而是人力资源¹。并解雇不是的人。

您可以尝试自己激励同事，但这非常困难。如果您给他们看书，他们将在几周后未打开的情况下将它们退还。如果您给他们提供建议，他们不会听，因为他们不在乎²。

您可以：

• 说服老板在公司中设置一些严格的规则：样式准则等。这不会激励那些人做得更好，但是至少他们将无法提交不符合要求的源代码。

• 按要求工作，特别是非功能性要求。要求一个特定项目必须包含少于5000 行的IL代码（不，我不是在说无意义的LOC）³的要求怎么样？要求以圈复杂度或类耦合获得特定结果怎么办？

• 增加您在公司中进行代码审查所花费的时间。指定要检查的内容：如果有清单，则添加与重构，可读性，简洁有用的注释等有关的要点。如果没有清单，则必须。

• 使用[更多] 配对编程。它可能有助于提高代码质量，并激励不那么积极的同事。

• 使用与雾溪类似的补偿系统。

^{¹这就是面试的目的：在雇用您之前，人力资源不仅必须资产您的技术水平，还必须资产您的动力。可悲的是，有些公司忘记了采访的第二部分，而雇用了不太喜欢编程的人。幸运的是，在大多数情况下，这些公司的工作从来都不愉快，而Joel测验很少超过2。}

^{² 即使收入减少，他们也确实不在乎。我与一位客户（我是自由职业者）非常接近，他认为他的工作是为自己的客户开发网站。他也有一位设计师。我多次告诉他们提高生产率2倍或更多的方法。如果他们只是聘请有​​能力的人，他们的收入至少会增加3。但是，他们有足够的钱，而且不关心质量，也不关心无知的客户要花多少钱，相比那些有生产能力的人。}

^{³我的意思是您在Visual Studio的“代码度量”中看到的IL代码的行数，该度量实际上是有意义的。在真正的 LOC并不重要，你没有来衡量它; 这是有史以来最愚蠢的指标之一。强制执行IL代码行意味着开发人员将不得不实际重构代码，而不仅仅是将十行代码折叠成一条不可读的行。}

“我已经完成了编码，只需要重构并拆分成多个类即可使DXM满意”。

这种思路正确，任何团队都可能患上癌症，如果不立即采取行动，这将扼杀整个团队的动力。我当然指的是这样的事实，即通过资历和/或才能，您碰巧处于技术权威的位置，从而赋予您力量来影响和实现团队中的良好实践。

这一切都很好，但是，如果您的团队在这些流程中被明确出售，他们将不会在这样的陈述中单挑您，这些陈述清楚地表明您对流程缺乏尊重，并且对您缺乏尊重。他们仍然将这些最佳实践视为您造成的障碍，而不是团队拥有的可以捍卫自己优点的过程。

您在先前的评论中提到其他团队成员确实确实在遵循这些实践和标准并正确地应用它们。首先将注意力集中在加强他们的支持上，询问他们哪些有效，哪些无效，他们喜欢什么以及他们希望看到什么改变。如果您这样做并认真对待他们的意见，他们对标准的感觉就会大为不同，就好像它们是社区的决定，而不是上级下达的程序一样。

通过向团队指出他们如何改善了软件开发过程或软件质量，可以增强对最佳实践和标准的支持。

对这些问题进行表决以进行讨论并记录结果，理想情况下，出于合法性考虑，每个决定都应一致通过，但如果您与强硬阻挠主义者打交道，这可能是不可能的，并且可能会使每个问题停滞不前。在这种情况下，请使用多数表决。如果大多数人违反了您提出的标准和惯例，那么您已经失去了空间，请在此时放弃。

他们将拥有这些标准和程序并执行它们，因此您不必这样做。作为技术主管，您不必宣布法令和法令，而成为领导者是一种糟糕的方法。

一旦团队感觉好像他们拥有这些程序，那么开始为您贴上某些程序和最佳实践的团队成员便会认为是非法的。您的团队将帮助纠正其他人的这种态度。

好问题！我认为答案取决于人们为什么不想提高自己的技能。可能的答案是：

• 他们认为自己太忙而无法学习新东西，或者他们认为新的工作方式（例如编写所有这些测试）将花费更长的时间，而他们没有时间这样做。那么显而易见的答案是：给他们更多的时间。当您总是以不同的方式做事时学习或尝试像TDD之类的事情会在前几次花费更多的时间。如果您的程序员没有时间，您就不能责怪他们没有尝试。
• 他们对自己的技能有不同的看法，即他们认为自己是产生高质量代码的优秀程序员。这是困难的心理地形，因为粉碎这种信念可能会非常不利。也许某种形式的非正式竞争会有所帮助（谁在代码审查中产生的缺陷/特征最少，代码最短？WTF /分钟最少）？
• 可能存在实际的动力问题（即，他们只想“尽自己的时间，一个人呆着”直到结束时间）。幸运的是，这过于笼统/与编程无关，因为我真的没有答案。
• 他们是初学者，他们并不了解。在这种情况下，培训，代码审查可能会有所帮助，或者“读书俱乐部”可能需要团队成员每月讨论一本新的技术书籍。
• 他们之前看过银弹，（并感到非常失望），他们认为您要出售的任何东西只是另一个新的流行词，在理论上听起来不错，在实践中很少使用。在那种情况下，证明在代码审查和结对编程会话期间的优势可能有用。当您这样做时，请尽量不要一无所知。

最好的解决方案实际上取决于根本问题：例如，正式的编码准则，度量标准和评论可能对初学者有效，但是“对自己技能的理解有误”的人可能会与他们抗争或使用度量标准，因为他们看到了他们成为完成工作的适得其反的官僚障碍。

真正的问题是，您如何与这样的人/团队打交道，并使他们对更好的做事方式感到好奇？您如何激励他们学习？没有这些，似乎所有的教学，会议，演讲，讨论都没有用，如果他们很高兴回到办公桌前并做他们一直以来所做的事情。

而已！这确实是一个真实的问题。

为了提供一些背景信息，我们只是没有时间进行大量的正式培训 -但有时候，如果我这样做了-它仍然看不到亮点。我经常是见证人，他们几乎不教他们如何思考。

因此，我对他们提出的问题不是如何教他们 -而是如何使他们学习？差异是微妙的，但这将使所有差异变得如此。

我不知道我是否正确；但我经常相信电影与Matrix的对话-“这是驱动我们前进的问题！” 最重要的是让他们思考，让他们问为什么！当然，谁认为他们已经知道最一切的一些设计模式，因为他们得到了在大学课程好成绩-是最困难的存在。

您如何使他们成为这样的问题？我的一般方法是“如果您希望他们学习游泳，那就把它们扔到池塘里”。我同意人们可能会不同意；我很乐意同意不同意他们的观点。当您将它们扔到池塘里时，它们实际上并不会学会自动游泳。但它激发了使他们思考的生存本能-一旦发生这种情况，他们就会自然而然地想到HOW和WHY。

我给人们提供的一个实际例子是，将他们置于一个比他们希望实现的目标更复杂的项目中，让他们自己打仗。当他们开始分解代码并发现很难追踪它时，您意识到他们开始提出很好的问题。

这听起来可能有点极端，这可能会浪费资源。而且我敢肯定，还有很多其他人会给我建议不要这样做。但这对我有用！

无论您分配什么薪水包和HR标签，它都无法解决基本的动机问题。因为那是他们受到挑战的唯一途径。如果您激发了这种基本的人类精神，那么其他所有方法都将起作用。如果不能，那是一场宽松的游戏。

PS：顺便说一句，我在这里https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034发布了答案-我受到了所有的抨击；主要是大多数人认为，企业以某种方式承受不起浪费资源的负担！我敢肯定，这里的答案可能会得到类似的处理。但是事实是，让人们努力工作并让他们相信自己做得好是人类心理学关于如何制定课程大纲的主题。

无论如何，您在此描述的任务就等于激发内在的激情，以进行重大改变。越大的系统越困难。从年轻的家伙开始，他们仍然坚守“我不会做好工作”的精神，并挑战现状。

正如您指出的那样，它的动机。不要误认为他们不关心他们不知道。他们清楚地知道该怎么办。 他们只是不在乎。如果是这样，那么这里真正的问题是……您的管理层做错了什么，使他们如此缺乏动​​力？您是团队的最新成员吗？也许他们以前经历过所有这些，但这只会导致他们的管理出现问题。因此，他们只是坚持做保持工作所需的最低限度的工作，因为他们认为做更多的事情不会得到雇主的回应。

在我看来，这是一个管理和领导问题-如果它是您的团队，那么您可以努力使（个人和代码方面的）改进成为您团队的核心属性，那么问题将得到您的管理层的支持-因为您将需要做一些需要时间的事情（因为您应该减少新的技术债务并偿还现有的技术债务，因此他们将获得净收益）。

因此，您断言您希望团队进行改进，并征得他们的同意，这是一件好事（整个团队都在努力提高其代码质量），然后开始执行一个程序来实现这一目标发生-听起来很简单...我知道事实并非如此！

我认为这包括两个部分-教育和工作实践。

• 您可以每周开始一个午餐时间进行教育-每个人都一起吃饭，您可以通过问答进行20至30分钟的演示。您从所需的基础知识开始-SOLID可能会占用前2到4周的时间-随着时间的推移，您可以让团队轮流发言，并且可以确定如何确定谁在彼此之间进行对话。在工作中留出一些准备时间。除此之外，还鼓励本地用户群体参加（如果可能的话，至少使其成为部分社交活动）
• 工作实践……这取决于您现在所从事的工作以及所拥有的工具，但是您可能希望查看一致的编码标准，引入对等代码审查（是否可靠），进行单元测试（不一定要先进行测试） ，运行连续集成服务器并查看更多自动化测试（除单元测试外）。但是这些都必须经过同意/同意（而不是build / CI服务器！）才能引入，并且您必须希望以团队的形式推动质量的提高。总有一些事情可以改善（Kaizen）

同样值得一看的是看板（被视为变革/改进的驱动力）。

最后一个想法-我是一名职业程序员，我希望我的团队保持不变， 但每周工作40个小时以上并不是一件好事，因此，一个人的目标应该是拥有一支能够完成工作的团队有效和良好的每周正常工作时间内，并就这对于提高工作实践的观点是，它更可能如：添加单元测试，证明失败的情况下（前）bug修复让你的信心，这是固定; 拥有构建服务器使您对完全构建解决方案的能力充满信心-如果该构建还生成了部署程序包，则意味着大大简化了部署；根据定义，SOLID代码更易于修改；整体而言，您所欠的技术债务越少，您还清的债务就越少...

大约30年前，我偶然进入了编程领域。我被分配去维护/支持他人的代码，从而学习基本的软件工程原理。在这些作业中，我学习了代码阅读器如何体验代码-如何同情代码阅读器。我不想让我编写得不好的代码给别人带来痛苦！

指派新的程序员来维护/支持其他人的代码的这种做法并不是万灵丹，它的确提供了学习如何更频繁地生成可靠代码的动力。