Architecture 敏捷和以体系结构为中心的软件开发之间有什么区别？

从我所读到的内容来看，“敏捷”似乎只是一个委婉的术语，用于黑客和刀砍式开发。换句话说，以体系结构为中心的开发是基于设计文档的，敏捷开发本身没有“设计”，代码只是被拼凑在一起，直到通过测试。我真的希望不是这样。如能澄清，将不胜感激。谢谢。

我不知道您是从哪里获得信息的，但这不是来自任何一个正确实施敏捷开发团队的人：）

敏捷并不意味着没有设计文档。相反，设计文档会随着时间的推移而迭代发展。我们的想法是，在任何人都没有任何经验之前，项目的一开始就是创建具体和详细设计的绝对最糟糕的时候。变量太多了。相反，创建了一个高层设计，该设计考虑了这些变量，并预先解决了这些不确定性将被及时发现的问题

作为一个基本场景，在一个项目开始时，我们会给出关于该项目规模的高水平估计，而没有任何具体数字。“这部分是小的，那部分是中等的，那部分是超大型的”等等。业务部门据此设定优先级。说他们最初想要超大件，但现在他们知道这比中号件要费劲很多，所以他们宁愿先要中号件，只是为了把东西推向市场。剩下的留着以后用

这为他们节省了为超大零件创建大型详细设计的时间，而事实证明，这并不是目前对业务最有利的。在更紧迫的优先事项完成后，可以重新评估和解决这一问题

而且，非常重要的是，根据软件的性质，在开发过程中对中间部分所做的更改完全可能会对超大部分的设计产生重大影响。如果它都是预先设计好的，那么重新设计和调整以适应这些变化将花费更多的成本

---

还应该注意的是，开发人员可以在任何开发环境中“一起破解代码以通过测试”。这与敏捷关系不大，与草率/懒惰的编码实践关系更大。开发方法不会产生好的或坏的软件，开发人员是这样做的。

就有组织的正式度量而言，敏捷开发可以是非常“架构化”的。敏捷更多的是与短期的、迭代的生命周期有关，这些生命周期允许项目快速增长并适应客户或团队可能遇到的任何变化。敏捷不是“牛仔编码”，因为这一点，然而，大多数敏捷团队使用真实的，甚至是严格的过程来完成他们的工作

我正在学习这门学科，所以我想我可以有所收获

敏捷和以体系结构为中心的方法都涉及到体系结构的开发，然而，在敏捷中，它并不像看上去那样无组织（正如Jesse也提到的），软件体系结构指的是通常被称为体系结构尖峰的东西，即一个孤立的体系结构，必须包含在更大的体系结构中，以便进行体系结构控制。 以体系结构为中心的方法依赖于体系结构控制中的一切，因此，失去了灵活性，因为通常需要大量文档来生成不希望的工作量开销

敏捷很少分析问题，但也有大量的解决方案设计，但在迭代过程中产生更多的孤立解决方案。以体系结构为中心具有这两者，但部署工作软件可能需要很长时间。伟大的目标是实现两者之间的平衡，可能使用更有效的解决方案，将两者结合起来

---

因此，敏捷最适合于小型企业，而以架构为中心更适合于大型企业或工业开发。

请参阅关于这一主题的优秀文章。敏捷最大的问题是其流行语很容易被滥用；基本原则是最重要的：Berten在“设计”和“架构”之间也有重要区别；我完全同意您不应该预先做一个大的SDE设计-但是-这并不排除首先布置一些架构-这应该与产品所有者对解决方案的总体看法大致相同。即使在早期阶段，也应该有足够的方向来确定主要的建筑方向。欢迎来到SO社区！