我如何让人们停止骑车流洒（专注于琐事）？

我的任务是教其他团队一个新的代码库，但是我一直遇到问题。每当我真正与人一起阅读代码时，在整个练习进行到无谓骑车（组织成员对琐碎问题的重视不成比例）之前，我们就走得很近。由于他们不了解代码库，但是认为他们需要帮助改进代码库，因此他们将重点放在可以理解的方面：

Why is that named that? _{（2分钟以解释为什么如此命名，10分钟以内辩论一个新名称）}

Why is that an abstract base class rather than an interface? _{（2分钟的解释时间，超过10分钟的时间辩论该决定的相对价值）}

...等等。现在，请不要误解我的意思-好的名字和好的，一致的设计很重要，但是我们永远也不会讨论代码的实际作用或如何以任何有意义的方式设计系统。我做了一些会议裁判，以使人们摆脱这些切线，但是他们走了-对固定琐碎琐事的代码将会/应该的注意力分散了，他们错过了更大的前景。

因此，我们稍后再试一次（或在代码库的其他部分进行尝试），由于人们没有足够的知识来克服自行车脱落的影响，因此重复进行。

我试过更小的群体，做大组，密码，白板，Visio图表，文字的巨墙，让他们只是把它认为死刑，立即切断短...参数帮助一些比别人多，但没有任何作品。地狱，我什至试图让团队中的其他人对此进行解释，因为我认为这可能是我不善于解释事物。

那么，您如何对其他程序员进行足够的教育，以使他们不再专注于琐碎的事，并可以对设计做出有意义的贡献？

我认为问题是任务：“我的任务是教其他团队一个新的代码库”。

您被赋予错误的工作，或者可能是误解了您所获得的工作。

通过在代码级别进行演示，您可以邀请代码级别的思考。

从系统级别开始，介绍设计和做出的设计选择。不允许进行进一步的讨论：您没有对此进行审查。允许提出问题：您确实希望他们理解系统。如果人们“本来会做不同的事情”，那很好。也许同意。或不。但是继续前进。这就是现在的样子。

在达到代码级别时，您已经使用系统术语对其进行了准备。名称（我认为）会很有意义。与上述相同：无需进一步讨论，有待理解的问题。继续。

现在设置一些类问题来解决。我们如何制作增强X？选择一些与系统设计“齐头并进”的不平凡的东西，然后逐步进行更改。他们现在应该了解系统的原理。选择另一种增强功能，如果执行不正确，可能会破坏系统，并说明如何正确进行。对他们来说，那应该是个阿哈时刻。有些人甚至可以击败您！

这是一场艰难的演出，尤其是在经历了错误的开始之后。听起来您已经投入了大量的时间和精力，也许与他们相比，我和我之间会有一些共鸣。” Fess up，然后重新开始。我们假设他们是聪明的人。给他们更高层次思考的挑战。并通过为新会话选择不同的团队部门来分解现有的组。

“停放他们”。在课程开始时，请说明您要讨论的内容，并明确说明被认为是非主题的内容。如果被问到明显是OT的问题，请这样说并继续。如果他们回来了，请将问题写在白板上（这很关键），以便以后进行讨论并继续进行。在课程结束时，当他们自己而不是您自己的时候，请注意这些问题的解决速度。

正确设定期望，并诚实，开放和坦率。

确保您的目标是公开透明的。

从andy256（+1）推动的高级观点开始讨论，但也要确保包括目标，例如

“ ...当我们研究这个问题时，请确保我们不关注x，y和z。还请确保我们不在考虑实施细节，例如a，b，c或琐碎的细节例如j，k，l。我知道代码中肯定会包含很多细节，并详细说明了可以解决，改进或变得更加标准的事情，但让我们先来看一下它在更高层次上真正实现了什么”

那么，您如何对其他程序员进行足够的教育，以使他们不再专注于琐碎的事，并可以对设计做出有意义的贡献？

首先，不要将他们的担忧视为“琐事”或“废话”。那些是判断性的话，这是侮辱。他们的担心是正确的。目前，它们并不重要。

任何良好会议的关键是让每个人都知道：

• 为什么要开会
• 你希望摆脱它
• 应该持续多长时间

事先明确陈述这些内容并解释目标。

例如，您可能会说：“这次会议是给我的，以使您熟悉Foo软件​​包及其在报告模块中的使用方式。我的目标是让您对Foo有足够的了解，以便您可以进行即将出现的Bar Reports项目下周。我希望我们在接下来的90分钟内完成。”

然后，当一个话题出现时，它可能像这样：

新手：“为什么FooWidget被实现为外观模式？”

您：“嗯，我想是因为（设计决策的简短说明）”或“我不知道”。

如果答案足够，那就太好了。如果没有，则继续：

NP：“难道您不认为最好是单身吗？”

您：“我还没有真正考虑过，但是我想继续说明FooWidget的工作原理。”

NP：“但是，如果它作为一个单例完成，那么我们可以-”

您：“很抱歉打扰您，但我需要继续关注FooWidget的工作方式。本次会议仅安排到11:00举行，我们还有很多工作要做。设计讨论将不得不等待下一次。”

完成一两次之后，可以将其简化为“这不在本次会议的讨论范围之内”。

请注意，您并不是在说“不用担心，这很愚蠢”或“没关系”或“闭嘴”或“您太新了而无法输入”。您只是将会议集中在需要完成的事情和所涉及的时间上。

在某些组织中，您将永远无法实现这一目标。许多组织更重视政治斗争和爬梯方式，而不是智力，勤奋和忠诚。他们为什么不呢。爬梯子使人们处于权力位置，使他们能够以更多的可支配收入来改善自己的生活，并且永远不会过时。

与实际解决问题，抽象思维以及对棘手的问题做出决定（可能由他们负责以后的后果）进行对比时，许多员工在尝试骑自行车出行方面承担了沉重的负担。

我建议的唯一建议是，在组织范围内，如果可能的话，请使您明确表示这些参与者的个人命运取决于他们对要解决的实际问题的理解，贡献和努力。如果这是在-errant-codebase中表达的企业体系结构，那么它就是全部。清楚地告诉他们，他们必须提供大量的有意义的投入是。没有其他的随机性，恰好是高级人士或其他人的宠爱，通过与高级人士达成共识，他们将获得很好的布朗尼点。

这通常很难做到，因为高级人员通常不了解正在进行的技术，不感兴趣，并且不幸的是控制着原始成分：员工时间；认真地雇用和解雇，会议室政治，晋升等，等等。

您称之为单车棚骑行，我称之为将某人的思想流转化为我们自己的思想。通过讨论名称，模式，他们可以使用自己的术语来理解代码，并且没有任何方法可以阻止它。

此外，没有必要对整个代码库进行非常详细的演练，因为在开始进行操作之前，细节会被遗忘很久。

基于这两个想法，我建议将代码库分成单元，将学习者分成两人一组。对于每个代码单元，每个小组将有25分钟的时间（当然取决于LOC），可以在5至10分钟的时间内完成对其他代码的遍历。三分钟的问题，并与下一个单元重复。说明是关键词；他们必须确保其他人都理解了这一切。

您将只剩下时间来强制执行时间，没有离题的话题，无法充分掌握该单元的控制知识。他们将成为他们学习的参与者，并且将更加专注于向其他人解释而不是骑自行车。

您可能需要从他们那里获得代码单元的高级手绘模式，这些模式将被复制并保存在团队共享的文档中，因此将来有一定的参考意义。锚定记忆也很好。

抱歉，如果您已经尝试过...

您是否尝试过上课，让人们单独查看？

制作简短的视频或演示文稿，以说明内容，代码的工作方式或基本上所有您想教的内容，采用他们需要自己查看并学习要尝试教给他们的信息的格式。

然后，您可以使用基于团队的会议来讨论与内容相关的问题。您需要明确标识团队会议仅用于讨论和解决与内容相关的问题。

如果您以个人为基础向他人提供课程，则可以避免其他社会问题，因为一件事情可以成为集体作为集体的声音，并分散了课程的实际目的。

在开始查看特定示例之前，请尝试先教他们代码库的设计，并指导他们了解体系结构。这样，他们可能会看到您所看的代码示例如何适应更大的前景。考虑一下您的培训计划的结构。并包括设计背后的商业动机。

我花了几年时间培训其他开发人员，但在向他们展示系统如何组合在一起之前，我从未接触过代码。然后，当我让他们在框架中进行代码练习时，问题就变得结构化且具有主题性。