4

即使您正在使用敏捷，在开始实施项目之前，您也需要一个高级架构。

通过高级架构，我的意思是将项目分成小部分，基础设施，分布式/基于网络/厚客户端等......

有没有关于这个主题的书籍/文章？

4

5 回答 5

4

我不止一次和 Kent Beck 争论过，他会说你错了，你不需要做出这些架构决策，或者更确切地说，你应该选择可能的最简单的东西工作并从那里开始。

我看到的问题是，在您发现 STTCPW 实际上不起作用并给您留下大量返工之前，您可能会走很长一段路。现在，如果您正在逐步正确地做事，或者使用风险驱动模型做得更好，因此您首先检查风险最高的决策，那么希望您能相对较早地发现这些事情，但肯定不能保证。

另一方面，很多敏捷项目都处于大多数架构都是预先确定的环境中，例如 Ruby on Rails 或 J2EE。这些系统大大降低了风险，因为你有一个确定的环境。

尽管我正在考虑写一本，但我不知道有关该主题的任何特定书籍；这在敏捷社区中仍有待商榷。

可能我最喜欢的论坛是Martin Fowler 的 blik i 和InfoQ，但需要注意的是我即将开始在 infoQ 上发帖，因此可能会受到偏见。

于 2008-12-20T00:29:10.183 回答
3

关于该主题的一篇好文章是“谁需要建筑师？” 通过马丁福勒。

我个人的看法是，您可能需要预先做出的架构决策比您想象的要少得多。如果你做的足以得出合理的估计，你应该做得很好。

不过，您需要密切关注设计力量，并擅长重构。你会想尽早开始练习。没有预先提出架构应该会给你很多机会。;)

你会做出错误的决定吗？是的。改变架构是否需要时间。当然。

但是你也节省了很多时间，因为你不试图预先构想一个架构。而且，因为在项目开始时您拥有的信息量最少，所以无论如何，前期架构不会真正“正确”。运气好的话，它“只是”有点矫枉过正，更有可能的是，还会做出一些你最好稍后再改变的决定。

关于风险，请记住您应该首先开始开发最重要的功能。这样，您的架构实际上将构建为最好地支持最重要的功能，这正是它应该的方式。

您可能会喜欢的一本关于该主题的好书是 Robert Martin 的“敏捷软件开发 - 原则、模式、实践”。

于 2008-12-21T01:39:29.777 回答
1

在一般架构上，您有例如：

  • Fowler：企业应用架构模式
  • Hohpe：企业集成模式
  • 扎克曼框架_
  • 开放组架构框架

而且您有特定于平台的书籍，例如Java：

  • Sun 认证 JEE 架构师学习指南
  • Broemmer：J2EE 最佳实践

维基百科有一个相当全面的软件架构指针列表。

于 2008-12-20T00:27:28.283 回答
1

这是敏捷的关键问题，我认为还没有人解决它。最初的架构决策对成功至关重要，正如 Kent Beck 所说，理想情况下，您应该推迟它们，直到您有足够的信息。

当然，他能这么说很大程度上是因为他可以选择他的客户，并要求那种程度的自由。项目进行三个月后，更改实现语言对他来说可能没问题，但对我们大多数人来说，这不是一个选择。我们必须尽早做出一些决定，而且它们必须是正确的。我们必须在信息不足的情况下工作，并尽可能有效地利用我们的经验和智慧。

大多数建筑文本都有一个过程，从表达所需功能的英文句子开始，然后将名词和动词分解成分类器的语义表示，最终变成实际的代码行。

我们不能在敏捷中轻易做到这一点——用户故事不适合分解，因为它们不够详细，而且我们没有任何其他功能需求来源。

我建议避免使用 UML 之类的东西（至少保留自己的笔记除外），直到您至少编写了发布计划，并且您对哪些故事可能在哪个迭代中实现有所了解。此时您可以开始详细的架构工作。

在此之前，您必须做出一些决定，我认为您能做的最好的事情就是尝试确定您可以做到的细节：

  • 非功能性需求可能是什么，
  • 您必须遵守哪些标准，
  • 您必须与哪些现有系统及其 API 进行交互，
  • 部署平台将是什么，
  • 目标运营团队具备哪些技能，

之类的东西。通常，这些约束可以充分限制您的预期交付，您可以对高级组件以及它们将驻留的位置充满信心。

我强烈建议在用户界面上进行信息架构工作。UI 很脆弱且更改成本很高，并且线框表示与完成的文章足够接近，可以与利益相关者讨论并获得有价值的答案。

但是，您需要一个优秀的信息架构师，并且您需要定期挖掘 IA 中的用户故事更改，以确保其中的所有内容都得到适当的估计。

对于非 UI 工作，请仔细考虑解决方案中的一些核心概念——通常可以非常清楚地识别和陈述事务边界和事务安全要求等内容，即使您不知道每个内容具体包含什么交易类型。就交易和数据安全的约束和成功标准做出一些陈述，并得到利益相关者的同意。

最后，在每次迭代开始时，您可以进行一些详细的建模和架构工作，因为这是真正的功能分解发生的地方。我强烈建议为这项工作投入时间预迭代。在迭代的实际编码开始时，您应该清楚地了解您将要创建的每个类、它将存在于何处以及它将与什么对话。如果没有这个，就无法协调开发团队。

于 2008-12-28T10:47:53.050 回答
0

听起来您正在讨论功能分解。

有自下而上和自上而下的方法。我喜欢从双方考虑一个项目。这一点尤其重要，因为当您从底层开始时，您可以考虑类及其方法。当您从顶部开始时，您可以考虑程序将如何流动。

尝试：

John Lakos 的大型 C++ 软件设计（Addison-Wesley 专业计算系列）（平装本 - 1996 年 7 月 20 日）

于 2008-12-20T01:33:18.743 回答