如何在团队中应对不同的开发风格（自上而下与自下而上）？

假设您刚开始在一个非常小的团队中从事{目前相对较小，但希望以后会更大}的项目。请注意，这是一个旨在供现实世界中的其他开发人员使用的实际项目，而不是一些打算在学期末取消的学术项目。
但是，该代码尚未发布给其他人，因此尚未确定任何决定。

方法论

你们中的一个喜欢在开始编写代码并使各部分组合在一起之前，必须对所有组件的交互方式（自下而上的设计）有个清晰的认识。你们中的另一个人喜欢先进行整个设计，然后在编码解决方案之前确定所有组件和通信的细节。

假设您正在开发一个新系统，而不是模仿现有系统，因此，正确的最终设计应该是什么样子并不总是显而易见的。因此，在您的团队中，不同的团队成员有时甚至对最终产品所需的要求有不同的想法，更不用说如何进行设计了。

当自下而上的开发人员编写一些代码时，尽管该代码可能会解决手头的问题，但自上而下的开发人员还是会因为设计中可能会遇到的未来问题而拒绝该代码，并认为正确设计更重要在尝试编写解决方案的代码之前。

当自上而下的开发人员在开始编写代码之前尝试设计出完整的设计和设想的问题时，自下而上的开发人员会拒绝它，因为自下而上的开发人员并不认为实际上会出现某些问题，并认为，当要求和约束变得更加清晰时，将来可能需要更改设计。

问题

这导致的问题是自下而上的开发人员最终浪费了时间，因为自上而下的开发人员经常由于设计缺陷而决定废弃自下而上的开发人员编写的解决方案，从而需要重新设计。 -编写代码。

自上而下的开发人员最终浪费了时间，因为自上而下的开发人员现在经常坐下来与自下而上的开发人员一起制定正确的设计，将两者序列化到甚至更快的程度比2人多做1人。

两位开发人员都希望继续合作，但似乎合并实际上并没有帮助他们中的任何一个。

目标

显然，共同的目标是最大程度地提高编码效率（即，将时间浪费最小化）并编写有用的软件。

问题

简而言之，您如何解决这个问题并应对这种情况？

我能想到的唯一有效的解决方案不会浪费时间，就是让每个开发人员都遵循自己的设计风格。但是，这比您进行代码审查并实际上需要批准彼此的更改以及尝试设计一个供他人使用的一致框架时听起来的困难。

有没有更好的办法？

显然他们都是错的。

自下而上的家伙正在破解代码，并且永远不会产生应做的事情-由于确定了未知的要求，这将是一个持续的失败。

自上而下的家伙可以花相同的时间在构想上，而没有做任何有成效的工作。

但是，中间立场是理想的-如果您知道要实现的目标（可以从广泛的设计工作中获得目标）并继续进行编码（无需任何详细的计划），那么您将从中获得收益既有组织又有效地发展。

顺便说一句，它被称为敏捷（不是某些人实践的BS版本的敏捷，其中过程比工作软件更重要），而是真正的敏捷，可以朝着通常描述和理解的最终目标努力。

要解决此问题，请尝试一种敏捷方法（看板可能是最好的方法），这既会迫使自上而下的人做一些工作，又会迫使自下而上的人对他要实现的目标进行计划。

两家开发商需要相互尊重。

自上而下的人需要尊重一个事实，即自下而上的人可能提出了切实可行的措施。正如我的一位“定量”教授告诉我的那样，“一种工作模式值得一千个猜测。” 如果是这样，自上而下的人应该考虑重新做“设计”以适应自下而上的人的工作。

自下而上的人还应该尊重自上而下的人的“框架”，并意识到这样做可以避免浪费的精力，解决错误的问题，摆脱困境等。自下而上的编码者至少应该记住什么自上而下的人正在尝试做，并且至少要解决框架中表达的自上而下者的担忧。即使自下而上的人不同意框架本身的某些部分，这也是正确的。

如果将大型任务分解为多个较小的且更具针对性的任务，则可以最大程度地减少每个开发人员所花费的时间。让他们紧密合作，以使他们都不至于遥遥领先。短距离的冲刺和小的可交付成果将大有帮助。解决小错误比大错误更容易。

看起来与您的目标相反，但结对编程有效。有些事情您有时甚至数小时甚至数天都不会马上被自己发现。如果无法直接一起处理任务，则整个星期中应更频繁地尝试代码复审/合并。

让所有人知道！

如果您发现开发人员因为他们不在自己的世界中而抛出了代码，那么您需要尽快高效地捕获并解决冲突。您的老板会很感激的，而团队会感激不必花一个星期的工作，因为他不知道对方在做什么。

您还应该看到他们一起工作是一种祝福。他们正在共同努力并不断修正错误，这是一个好兆头。我在您发帖的半途中想到了“这两个人可能彼此讨厌...”，令我惊讶的是，您说他们想继续合作。

我认为此报价适合您的情况。

“如果两个人在所有事情上都达成共识，那么其中一个是不必要的。” 〜一些老家伙

对我来说，这实际上听起来是一个理想的方案。再说一次，我是这两个开发人员。我喜欢以注释的形式草拟“全局”，最终将它们引入问题跟踪器中。然后，我从头开始思考实现细节。当我更好地理解各个部分如何组合在一起时，全局就发生了变化，随着需求的变化和我有了新的想法，各个部分也就发生了变化。

也许这是多脑的好模型。

我认为，它们是相辅相成的配置文件，可能最终会做得很好。编码和设计都是编程中必不可少的阶段，并且您不想成为一个没人愿意做X的团队，您所需要的只是一点组织性（请参见我也可以大胆地说！）

正如其他人指出的那样，这可以通过监督来完成，但更好的是，通过就何时设计和何时进行编码的迭代计划达成共识，并总体上避免对当前正在设计的内容进行编码。

值得庆幸的是，只要将项目放入较小的模块中，自上而下的程序员就可以设计自下而上的程序员当前不从事的工作，从而使二者都可以按自己的意愿进行工作。但是，这意味着当需要将所有内容放到一起时，他们两个都有进行必要调整的能力。

一记：你说

假设您正在开发一个新系统，而不是模仿现有系统，因此，正确的最终设计应该是什么样子并不总是显而易见的。

这是问题的一部分：除非您正在为一个已经解决的问题而从事一个很小的项目，否则实际上并没有正确的最终设计。有很多可能的设计。请记住，除非您由于代码的优美性而这样做是为了提高自我，否则最终目标是一个有效的应用程序。而已。到达那里的方式无关紧要，让这两者快速发展的最佳方法是以互补的方式让他们一起工作。

就像其他人所说的那样，两种观点在某些方面都是正确的。两个开发人员在实践上存在分歧是很正常的，特别是对于像设计和开发过程这样的主观事物。您在这里有两个人，他们对自己的工作充满热情，并且对如何做非常了解：拥抱它！

这里有很大的潜力让您允许两个人以自己的方式工作，并且仍然可以拼凑起来以得到可行的应用程序。

1. 我让他们两个坐下来讨论，鼓励他们从对方的角度来看。

2. 在讨论之后，您可以开始讨论计划：应该以团队的形式进行，但要理解的是，两者都不必“让步”，但需要做出折衷。有很多方法可以为代码库计划体系结构，从而可以在不引入大量额外代码的情况下轻松地对其进行扩展。

3. 一旦让他们陷入停战状态，就让他们疯狂吧！让“自上而下的家伙”推动高级架构，接口，层次结构等的规划。让“自下而上的家伙”参与进来，一旦计划了几个模块，便开始编写代码。让他们正式同意接受其他人的方法对整个项目也是如此：计划允许将来进行轻松的更改是好的，但是不必立即进行编码。创建接口并存根方法以获得代码的结构，并接受在将来需要时才编写大量的将来代码。

4. 让他们经常一起审查设计和代码。遍历各个周期，在这些周期中，您将深入了解体系结构的某些部分，进行更详细的计划并编写这些部分。

5. 这可能是最重要的一点：在周期中的便利点，他们只谈论过程，而不是正在完成的工作。反思正在建立的动态：您应该问四个问题。我们应该继续做的什么顺利？我们应该停止做的不好的事情是什么？我们缺少什么？对于丢失的东西，我们该怎么办？

这将需要一些工作：您必须让他们同意以他们自己的方式一起工作。对于某些人来说，承认没有一种单一的正确的做事方法并不容易。重要的不是您的工作方式或最终的代码是什么。重要的是，这两个技术娴熟，知识渊博的人将学习如何共同努力。您不能只告诉他们这些。您所能做的就是引导他们完成一个学习如何自己做的过程。就像没有正确的设计一样，人们也没有一种正确的工作方式。

通常，根据我在职业生涯中的经验，前期设计不足。而且确实发生在前面的设计是低质量的。这不好。主要是因为结果（或多或少）将泥浆扔在墙上并看到粘住的东西。从一开始就承担了技术债务。

自上而下通常优于自下而上。尽管我不排除完全自下而上的可能性。其原因是自上而下迫使您更广泛地思考问题并提出更好的问题。这加强了上面的第一点...导致了更高质量的设计，通常会严重影响许多较低级别的工作。这样可以减少大量的返工，而如果首先构建较低级别的组件，通常这是必需的。

如果先构建自底向上的组件，则开发压力会试图将业务需求塑造为已设计的组件，这具有不小的风险。这也是不好的。业务需求应该驱动设计，而设计应该驱动实施。任何其他方式都会导致较差的结果。

两种方法都不够。似乎他们每个人都很聪明或经验丰富，足以意识到另一种方法的缺点（也许他们被烧死了？），但看不到他们自己选择的方法的缺点...

事实是，必须采用混合方法：

• 几乎不可能预先提出“正确的”设计；必须进行一定程度的实验才能确定痛点，瓶颈……（提示：它们永远不会在您认为的地方出现）
• 仅仅通过“走”去任何地方几乎是不可能的，比起任何事情，您更有可能在不想去的地方结束，或者只是绕圈跑

但是，将两者混合使用，您可以：

• 粗略地给出方向和基础架构的骨架
• 并开发符合这一愿景的组件

由于不存在满足该目的的现有系统，因此预先意识到以下几点很重要：

• 实验/原型制作是必要的
• 因此，迭代是必要的

因此，应该强调尽快到达“工作”系统，即使这意味着忽略角落情况等。这是“薄垂直切片”的概念：而不是建立房屋的基础，然后是墙壁，然后是屋顶结构，...只在最后获得可用的东西（或者永远得不到，或者它根本不可用）...最好先建一间设备齐全的房间，像洗手间 它立即可用，可用于收集反馈。

但是，为了使反馈有价值，最好首先处理核心部分。

那么，与您的同事怎么办？

首先，第一件事是他们俩都必须了解合作的需要和就前进的道路达成共识的需要：像他们一样，不断地被责备必定会引起您的紧张并影响一个人的动力。我在上面介绍了我发现在多个项目中可以很好地实践的内容，您可以将其用作建议。

然后，他们需要就谁在做什么达成共识。注意，在上面强调的中间立场方法中，他们两个都应该完成他们赞赏的任务。

请注意，最好以增量方式来构建骨架和构建砖块。

1. 他们两个都应该大致了解骨架，然后共同决定首先要关注哪个“薄片”
2. 自下而上的家伙应该开始研究最了解的“薄片”
3. 自上而下的家伙应该开始充实骨骼，理想情况下，首先处理最块状的块以完成切片

冲洗并重复，直到切片起作用为止。在进行调整的过程中积累反馈。

当心：这是一个原型，都需要准备好丢弃它，并从头开始进行完全不同的设计。

您需要的是一位了解软件开发的领导者（或主管），并由他来决定在项目中应使用哪种方法。如有必要，领导者将指导开发人员以特定方式工作，而不管其个人喜好如何。

我能想到的唯一有效的解决方案不会浪费时间，就是让每个开发人员都遵循自己的设计风格。

实际上，这可能是非常低效的……因为很有可能会出现很多冲突和返工。更糟糕的是，您可能最终会导致整个项目失败。