敏捷 / XP 和分层方法 [关闭]答案

【问题标题】：Agile/XP and Layered approach [closed]敏捷 / XP 和分层方法 [关闭]
【发布时间】：2010-12-07 17:42:42
【问题描述】：

敏捷/XP 可以与分层方法一起使用吗？

敏捷/XP 应该与分层方法一起使用吗？

将源代码分层需要额外的工作，从而显着增加开发时间。

注意：“层”是指带有 POCO、DA 等的单独程序集。

【问题讨论】：

【解决方案1】：

敏捷/XP 是一种管理项目活动、可交付成果和时间表的方法。

分层（N 层）应用程序是一种提高可维护性、可扩展性和团队成员分离责任领域能力的方法。

它们之间没有太大关系，只是如果您不熟悉它们，它们都需要额外的时间投入。与传统的替代方案相比，如果使用得当，两者都将有助于提高项目的质量。

【讨论】：

层和层是不同的概念。
我想这取决于你问谁。你觉得有什么区别？
好吧，如果你问知道区别的人，他们会认为它们是不同的概念 :-) 层：en.wikipedia.org/wiki/Abstraction_layer 层：en.wikipedia.org/wiki/Multitier_architecture
来自您的链接：“层和层的概念通常可以互换使用”。与我一起工作的人也倾向于互换使用这些术语，并在进行区分时谈论逻辑与物理模型。所以是的，这取决于你问谁。
术语过多，对不同的人有不同的含义是不争的事实。是的，这让事情变得比他们需要的更难，并导致混乱。但是，除非您可以指出一个被广泛接受的标准，该标准将“分层方法”定义为始终表示抽象层而不是分层架构，否则我无法同意您的观点，即“大多数答案”对该术语的含义不正确。

【解决方案2】：

两者完全正交。

在 XP 中，您逐个功能地开发系统功能。当您添加功能时，您会不断重构系统以确保其实现尽可能清晰。层通常会脱离该重构。如果该架构合适，层或其他大型架构结构（例如 SEDA 或 REST）也是如此。

【讨论】：

【解决方案3】：

在我看来，敏捷警告“你不需要它”并不是要完全避免复杂性，而是要避免增加不必要的复杂性。确实，单元测试的好处之一是建立了一个学科，您可以在其中无所畏惧地重构，以使内容最终到达它所属的地方，而不是它可能开始的地方。

所以重点不是要避免层（或层，如果必须的话）——重点是要避免糟糕的层。

【讨论】：

【解决方案4】：

我认为他们真正的问题是应该让开发人员在团队中按层划分 - 如果你有一个 html 开发人员、一个 js 开发人员、一个中间层人员、一个消息系统人员和一个 dba 一起工作来构建CRUD 表单，或者您应该按功能构建并让一个人拥有线程。后者在敏捷中更可取——专精通才优于专家。

【讨论】：

【解决方案5】：

让多个团队一起参与敏捷项目是否明智？是的：我参与过一个大型项目，有 15 多个团队的 200 多名开发人员。总共大约有 20 或 30 个服务。

这可以通过专门的团队来完成吗？并不真地。

团队成员可以有专长吗？是的，但是您确实需要在某些领域具有优势的通才，而不是只知道一件事而不会触及其他任何事情的人。

【讨论】：