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 回答