Why is that named that? （2分钟解释了为什么这样命名， 10分钟以上讨论一个新名称）
Why is that an abstract base class rather than an interface?（2分钟解释，10分钟以上讨论该决定的相对优点）...等等。现在，请不要误解我的意思-好的名字和好的，一致的设计很重要，但是我们永远也不会讨论代码的实际作用或如何以有意义的方式设计系统。我做了一些会议裁判，以使人们摆脱这些切线，但是他们不见了-当他们的宠物琐事固定后，代码会/应该是什么分散了他们的注意力，他们错过了更大的前景。 />，所以我们稍后再试一次（或使用代码库的其他部分），由于人们没有足够的知识来克服自行车脱落的影响，因此重复了。
我尝试了较小的小组，更大的团体，代码，白板，visio图表，巨大的文字墙，让他们只是争辩不休，立即缩短论点……有些帮助比其他帮助更多，但无济于事。地狱，我什至试图让团队中的其他人来解释它，因为我认为这可能只是我在解释事情上很不擅长。琐碎的事并且可以对设计做出有意义的贡献？
#1 楼
我认为问题在于任务：“我的任务是教其他团队一个新的代码库”。 br />通过在代码级别进行演示，您可以邀请代码级别的思考。
从系统级别开始，介绍设计和做出的设计选择。不允许进行进一步的讨论：您没有对此进行审查。允许提出问题：您确实希望他们理解系统。如果人们“本来会做不同的事情”，那很好。也许同意。或不。但是继续前进。这就是现在的样子。
进入代码级别时，您已经对它们有了系统术语的了解。名称（我认为）会很有意义。与上述相同：无需进一步讨论，有待理解的问题。继续。
现在设置一些类问题可以解决。我们如何制作增强X？选择一些与系统设计“齐头并进”的不平凡的东西，然后逐步进行更改。他们现在应该了解系统的原理。选择另一种增强功能，如果执行不正确，可能会破坏系统，并说明如何正确进行。对他们来说，那应该是个阿哈时刻。有些人甚至可以击败您！
这是一场艰难的演出，尤其是在您经历了错误的开始之后。听起来您已经投入了很多时间和精力，也许我和他们之间还是有一种对我的感觉。 ” Fess up，然后重新开始。我们假设他们是聪明的人。给他们更高层次思考的挑战。并通过为新会议选择不同的团队部门来分解已经存在的小组。
评论
首先，我做了一些高级设计指导，并提供了一些新的/不熟悉的技术（IoC容器，动力学）方面的培训来帮助您进行准备。训练进行得很顺利。这是一个很好的提出。
– Telastyn
13年11月21日在3:49
+1不会尝试与“精神骇客”之类的人打架，例如“我会在和您的时间回答您的非主题问题！”而是改变观点
– Buksy
13年11月23日在12:05
很棒的答案。我特别喜欢这样的建议，即使焦点成为“它做什么”，而不是“它的内部组件是什么命名”。
–丹尼尔·霍林拉克（Daniel Hollinrake）
13年11月27日在14:38
#2 楼
“停放他们”。在课程开始时，说明您要讨论的内容，并清楚地说明什么是非主题。如果您被问到明显是OT的问题，请这样说并继续。如果他们回到问题上，请在白板上写下问题（这很关键），以便以后进行讨论并继续。在课程结束时，当他们自己而不是您自己的时候，请注意这些问题的解决速度。评论
+1这样，人们就会觉得自己没有被忽略。
– andy256
13年11月21日在3:44
我同意这一点。如果问题讨论无关紧要的时间太久了，那就不要讨论无关紧要的事情...
–克里斯
13年11月21日在9:31
也许不是让大家在白板上写OT问题，而是让提问者记录下来（在指定的Wiki页面上，JIRA问题无论在哪里）。
– LarsH
13年11月21日在16:55
我认为花点时间在白板上写下问题的实际举动清楚地表明了发问者您正在推迟他们的问题（而不是忽略它），并且向正在询问所有问题并因此而延迟的其他听众展示进展。
– JBR威尔金森
13年11月21日在17:15
@LarsH-完全是。通过穿上白板，所有人都可以看到，对话停止了。如果再次出现该问题，则讲师会指向该问题并说：“我保证我们会再次提出。”
–mattnz
13年11月23日在6:41
#3 楼
正确设置期望，并诚实，开放和坦率。请确保您的目标是公开透明的。 1），但还要确保包括您的目标，例如
“...。在我们研究此问题时，请确保我们不关注x，y和z。确保我们不会查看诸如a，b，c之类的实现细节或诸如j，k，l之类的琐碎细节。我知道代码中肯定会包含很多细节，并且这些细节都可以解决，改进或提高了标准，但是让我们先来看一下它在更高级别上的真正成就。”
评论
前2个句子+1。但是，告诉人们不要思考某些事情并不是让他们不要思考的好方法。 “无论做什么，都不要考虑粉红色的独角兽。”在我提到粉红色独角兽之前，您是否在考虑它们？可能不会。如果相反，我说“不要让想象中的动物分散注意力，而要专注于澳大利亚的动物”，那么您可能会遇到考拉和袋鼠，但可能不是粉红色独角兽。
–迈克尔·肖（Michael Shaw）
13年11月22日在4:14
好点子。但是，真正的目的不是要阻止人们思考（而不是说），而是要避免人们陷入那些遇到杀手和士气低迷的旷日持久的对话。人们总是会想到很多没有说的东西。没关系。在专业的业务环境中，有些事情会说，有些则不会。
–迈克尔·杜兰特（Michael Durrant）
13年11月22日在4:23
#4 楼
那么，您如何对其他程序员进行足够的教育，使他们不再专注于琐碎的事，并可以对设计做出有意义的贡献？ ”。那些是判断性的话，这是侮辱。他们的担心是正确的。目前，它们并不重要。
召开任何会议的关键是让所有人都知道：
为什么要开会以及
希望摆脱困境
应该持续多长时间
明确陈述这些内容并解释目标。例如，您可能会说：“这次会议是为了我要让您熟悉Foo软件包及其在报告模块中的用法，我的目标是让您对Foo有足够的了解，以便您可以在下周进行的Bar Reports项目中工作。接下来的90分钟。”
然后，当一个话题出现时，它可能是这样的：
新手：“为什么FooWidget被实现为外观模式？”
您：“嗯，我想是因为（设计决策的简短说明）”或“我不知道。”
如果答案足够，那就太好了。如果没有，那么它会继续：
NP：“难道您不认为单身做会更好吗？”
您：“我还没有真正考虑过，我想继续说明FooWidget的工作原理。”
NP：“但是，如果它是单例完成的，那么我们可以-”
您：“很抱歉打扰，我需要把重点放在FooWidget的工作方式上。本次会议只安排到11:00举行，我们还有很多工作要做。设计讨论将不得不再等一次。”
之后您只需经历一两次，就可以将其简化为“这超出了本次会议的范围。”
请注意，您并不是在说“不用担心，这很愚蠢”或“没关系”或“闭嘴”或“您太新了而无法输入”。您只是将会议集中在需要完成的事情和所涉及的时间上。
评论
很容易看出主持人何时对反馈真正不感兴趣。那些会议进行得很快。没人在乎。
–chux-恢复莫妮卡
13年11月22日在4:47
#5 楼
在某些组织中，您将永远无法实现这一目标。许多组织更重视政治斗争和爬梯方式，而不是智力，勤奋和忠诚。他们为什么不呢。爬梯将人们置于权力的位置，使他们能够以更多的可支配收入来改善自己的生活，并且实际上永远不会过时。在棘手的问题上做出决定，他们可能会为以后的后果负责，许多员工在尽可能多地骑自行车的方面承受了沉重的负担。我建议的唯一建议是，在组织范围内，如果可能的话，您应使自己清晰明了，这些参与者的个人命运取决于他们对您遇到的实际问题的理解，贡献和努力正在尝试解决。如果这是在-errant代码库中表示的企业体系结构，那么它就是所有错误。向他们明确表明，他们必须对此提供实质性的有意义的输入。并非其他任何随机性，碰巧是某人或某人的宠爱之物，通过与上述某人达成共识，可以使他们获得不错的布朗尼点。由于高级人员通常不了解正在进行的技术，不感兴趣，并且不幸的是，他们控制着原始成分：员工时间；认真地雇用和解雇，会议室政治，晋升等等等，等等。
#6 楼
您所谓的Bikeshedding，我称之为将某人的思想流转化为我们自己的思想。通过讨论名称，模式，他们可以按照自己的术语来理解代码，并且没有任何方法可以阻止它。整个代码库的非常详细的演练，因为在开始使用代码之前，细节会被遗忘。基于这两个想法，我建议将代码库分解为多个单元，并且将学习者分为两人一组。对于每个代码单元，每个小组将有25分钟的时间（当然取决于LOC），可以在5至10分钟的时间内完成对其他代码的演示。三分钟的问题，并与下一个单元重复。说明是关键词；他们必须确保其他人都理解了所有内容。他们将是他们学习的参与者，并且将比Bikeshedding更加专注于向其他人解释。
您可能需要他们提供代码单元的高级手绘模式，这些模式将被复制并保留团队共享的文档，以便将来有实际的参考。锚定记忆也很好。
抱歉，如果您已经尝试过...
#7 楼
您是否尝试过让人们单独看课的课前课程？制作简短的视频或演示文稿，以解释其内容，代码的工作方式或基本上所有您想教的内容，使他们以自己需要自己查看和学习信息的格式来学习正在尝试教他们。
然后，您将使用基于团队的会议来讨论与内容相关的问题。您需要明确标识团队会议仅用于讨论和解决与内容相关的问题。
如果您单独向人们提供课程，则可以避免其他社交活动。一个问题可以成为小组集体的声音，并分散课程实际目的的问题。
评论
Nooo .......，不是视频.....“ Death By Powerpoint”已经被更糟糕的命运所取代……，尽管它将具有阻止问题的预期效果-威胁他们更多需要10分钟才能解释30秒钟内就能读懂并在几秒钟内就能理解的视频。
–mattnz
13年11月21日在3:38
+1 mattnz单向交互无法解决通信问题。
–迈克尔·杜兰特（Michael Durrant）
13年11月21日在3:41
即使在视频中，我也不想被暂停！哪种视频格式/编解码器禁用暂停功能？ :) :) :)
–卡兹
13年11月21日在6:23
#8 楼
在开始查看具体示例之前，请先尝试教他们代码库的设计，并指导他们了解体系结构。这样，他们可能会看到您所看的代码示例如何适应更大的前景。考虑一下您的培训计划的结构。并包括设计背后的商业动机。我花了几年时间培训其他开发人员，在向他们展示系统如何组合在一起之前，我从未接触过代码。然后，当我让他们在框架中进行代码练习时，问题就变得结构化且具有主题性。
评论
我讨厌这么说，但是听起来像是这种现象说明了代码库比新手更多的问题。您是否尝试过将问题推迟到最后？ “再等几分钟，我可以在后面解释”，然后继续浏览其余内容。也许其中一些问题会回答自己
@NickC，我认为代码是否好与您如何理解它，如何设法清晰地了解它无关。从一开始就浪费时间在小细节上而不花时间来获得最初的大印象是不好的，而且永远无助于修复潜在的错误代码。
教别人代码库的目的是什么？也许您可以更清楚地传达该目标及其重要性，以便他们看到辩论某个对象的新名称会分散该目标的注意力，应该保留给另一个会议。
这些答案中有很好的建议。我将简要补充：考虑使用“过程”作为您的盟友。当有人说“此设计不理想”时，正确的回答是“非常好，我很高兴您注意到这一点。在这次会议之后，请在跟踪数据库中输入一个错误，并详细说明问题和建议的修复。将审核您的提案，将其与其他工作项目优先排序，并在所有优先级较高的项目都修复后将其分配给适当的开发人员进行修复。