在一家小公司中进行编程/协作配对

我在一家小型开发公司工作，担任首席开发人员。我们还有另外两个开发人员，还有我的老板，他是一名开发人员，但实际上并没有做太多实际的编码。

我要克服的问题是多方面的。我们之间的趋势是所有人之间都没有太多合作就可以从事我们自己的项目。事实上，我（作为最高级的开发人员）比其他人更愿意寻求他人的意见/帮助，因为我重视外在的想法。

我想加强我们的合作，并向他们表达了这一点。在很大程度上，因为我想向他们展示一些有关如何成为更好的开发人员和遵循更好的做法的事情。但是考虑到我们其他开发人员的个性类型，我认为他们一个人工作更自在。

我一直在阅读关于结对编程的知识，并且我已经（在某些论坛中）读到，当您拥有一个开发人员比其他开发人员更先进时（我是），它不能很好地工作。但是，我觉得我们必须开始合作，以使我们的工作不会如此分散。

我的问题是，是否有人曾经遇到过类似情况，什么对他们有用？

我意识到这不是万能的，但我愿意尝试多种方法。

我们所有人都在一个公共区域工作，开发人员没有单独的办公室/隔间。

由于已经在其他答案中讨论了为什么结对编程不是您的解决方案，因此我将讨论我们目前正在尝试的结果，并对结果感到满意。

在我看来，您可以做的是加强协作，那就是每个项目需要两个人在一起。他们每个人都在项目的不同部分上工作，但是由于必须将这些部分集成在一起，因此两个开发人员必须进行协作。这还要求两位程序员讨论项目的体系结构（分层和接口），然后决定承担不同的角色。

而且，如果这种方法限制了公司一次可以处理的项目数量，则可以同时将此协作对分配给两个项目。

我们最近尝试了这种方法，让其中一个开发模型 +与api集成，另一个让程序员处理视图和控制器。我们发现此设置具有以下优点：

1. 与仅在项目的各个方面进行工作时相比，代码结构的结果要好得多。
2. 我们不必提醒他们有关将代码提交到存储库等的信息。
3. 他们必须付出一些努力来测试彼此的代码，而不是仅仅依靠我们专用的质量保证。

我认为，结对编程不是解决您所提出问题的方法。

一对编程中有两个不同的角色。该观察员是那里的审查和反馈由编写的代码驱动程序。如果您想传达想法以改善初级程序员所做的决策，我想知道您在发挥驱动程序角色时可能会发现他们批判性地查看正在编写的代码的能力有多有效。

没有这种动态性，结对编程的好处就会丧失。

作为高级程序员，我建议您考虑与老板一起制定更强大的员工培训和发展计划。应该给您的初级程序员一个框架，以提高他们的技能。通常，您可以使用诸如启蒙，编写编码标准文档，将自己的任务与自己的工作分开以及确保适当的代码审查过程等方法。

TL; DR：我认为结对编程不适合您。相反，您应该尝试让人们关注他们的代码的长期质量，并使他们想找到答案。这必须非正式地进行。

关于文化和品质

我觉得这个问题与编程方法无关，而与文化有关。以我的经验，可以指导文化，但是很少通过告诉人们它来指导。也就是说，试图将某些工作流程强加给没有自然进化的人或与现有实践相距太远的人，必然会带来负面影响。

换句话说，即使您最终还是不愿意，您也不希望看起来像是在四处流行最新流行语的西装。我认识的大多数程序员都会在心理上将您标记为背景噪音。不要成为企业的蜜蜂。

我认为，您应该问自己的主要问题是“我对组织发布的代码的质量和业务价值感到满意吗？” 如果答案是否定的，您应该问“我该如何解决？”。

最终，质量和价值是人为的定义，只有您或组织中的其他人才能（并且应该）考虑。

配对编程和微管理

因此，冒着听起来有些刺耳和刺耳的风险，在我看来，关于结对编程的阅读实际上使您考虑了某种形式的微管理，或者反过来。MM是疏远大多数人的必经之路。

捍卫结对编程：结对编程并不是要某个人看着另一个人的肩膀。这与管理层一样微。PP是关于使用两个头脑去思考在同一时间两个层次-有一个人交易的高层次，大画面的问题，而其他的需要照顾的螺母和螺栓需要生产工作的代码。以我的拙见，如果两个参与者不能切换位置，则效果极差。他们应该具有类似的经验，拥有相似的专业概念库和共享的专业词汇（我们之间没有思维联系，但是，穆哈哈哈）。

对于您的情况，我想说，因为您是一个小团队，而且您是唯一具有实际经验的人（这对您来说听起来很像我的意思），所以大多数时候对编程或检查大多数代码不会不行 您一天只有24小时。相反，您可以考虑一些解决方案：

• 鼓励他们以适当的语言标签参与SO，或在Code Review SE上发布一些代码片段以供审核。发起一场非正式的竞赛，讨论谁可以每周获得最高的SO代表积分。

  SO可以为新手开发人员带来奇迹，因为它不断提供反馈并遵循社区的心跳。

• 看一看他们检入的某些代码，并就其长期演进提出一些问题，以非正式的方式挑战它们。大多数初学者程序员根本不习惯于考虑使其代码具有可读性和可维护性。一旦这些问题引起了他们的注意，他们将自行从您或其他来源寻求更多信息。

我认为结对编程不会对您的环境有所帮助。并不是说这不会帮助缺乏经验的开发人员提高技能-甚至还有程序员与不同技能水平的工程师结对编程的问题。即使有诸如知识共享和减少错误之类的好处，结对编程也需要更多的时间投入。一个由三个开发人员组成的团队，只有四个具有开发背景/经验的人，维护一个配对编程例程似乎很困难。

我认为在您的情况下，更好的选择是代码审查，尤其是如果您适当地调整它们。代码审查可能包含以下任何内容：一个人查看一小段代码，并在一两个小时内向一个房间中的多个人（甚至整个团队）提供反馈，以查看整个组件的设计和实现。这些可以根据正在完成的工作而变化，尤其是基于团队的知识，经验和需求。您仍然可以通过让多个人参与审阅来发现问题，提供建议并通过阅读审阅的输出将评论纳入他们自己的工作中来获取知识，从而在他们进行审阅之前获得知识共享方面的知识。 。

我的问题是，是否有人曾经遇到过类似情况，什么对他们有用。

既然您邀请经验，这就是我所做的。我选择了低风险方法，并要求比我年轻几十岁的人一起度过一些时间。我们没有标记活动。除了我之外，没有人知道我们正在尝试一种新技术。

我不知道确切地涉及哪些细节，但是该过程运行得很好。他想受到指导，这是我事先没有暗示的。因此，它以非常积极的方式开启了双向交流。

事实上，我（作为最高级的开发人员）比其他人更愿意寻求他人的意见/帮助，因为我重视外在的想法。

听起来您可以将其视为当前正在做的事情的逻辑进展。

提出这个问题几个月后，我不得不说我对我们的结果感到满意。但这并不是我一开始就接受的。请记住，这是一个小团队，因此此解决方案并不适合所有人。

我发现最好让每个人都做自己的工作。随着时间的流逝，我们彼此之间建立了信任，如果遇到问题，我们就会寻求其他人的帮助。我认为没有人愿意和看着别人的人一起工作。我有时会坐在某人后面，有时会在不被要求的情况下帮助他们解决问题。有时我没有什么可补充的，也许让他们有些恼火。但是他们知道我不是在那里竖琴。我主要是在这里与我正在做的事情稍作休息，并介绍一些协作。

我发现，随着时间的推移，正确的人（在一个小型团队中）会与他人所做的事情保持同步。无需始终进行微观管理或告诉别人他们在做什么错。

时不时与某人坐下并解决问题，无论您是专家还是某人正在学习，或者两者兼而有之。解释为什么您会或不会以某种方式做某事而不是另一种方式。好主意通常会流行，而其他主意会落在后面。归根结底，您会有一群富有生产力，凝聚力的人，他们可能在做不同的事情，但有共同的目标。