12

我有兴趣在多开发人员团队场景中学习如何设计/规划 Web 应用程序开发。

假设“项目经理/负责人”的角色:

  1. 成功的 Web 应用程序开发需要哪些“文档”?
  2. 需要哪些 UML 图以及需要到什么程度?
  3. 在设计/计划阶段,是否需要根据用例对每个类进行图解?
  4. 类图应该有多详细(深度和广度)?

如果您有任何有用的书籍/网站推荐,请分享。


跟进(2009 年 11 月 18 日添加): 编码人员/开发人员在编码过程中使用什么作为指导,即创建类,以及它们各自的方法和属性?

如果没有完整的(但可变的)类及其方法和属性的列表,那么这种歧义是否会导致严重依赖每个编码人员的知识/经验,从而导致代码质量/可用性/可维护性的偏差?

4

5 回答 5

10
  1. 在任何情况下,您都必须拥有准确要求的全面和最新记录。这包括功能性非功能性需求。它可以是 Word 文档、电子表格或专门的需求系统。您只需要一些可以让您跟踪所有需求以及它们如何随时间变化的东西。 这是关于敏捷需求文档的信息和讨论的良好来源。
  2. 根据我的经验,用例图被证明很重要,组件图和部署图也很有用。类图和序列图也很有帮助,但在大多数情况下,我认为它们应该更多地用作基本的可变指南,而不是不可变的开发要求。类和方法通常会发生变化(尤其是在您使用 TDD 时),如果您真的想要图表,最好在开发代码后更新它,而不是硬塞您的代码以适应图表。
  3. 我不认为每个类都需要绘制图表。我认为模型类图对于跟踪数据的位置很有用,有时一些控制器和视图类图也很有用。但在我的大部分经验中,需求和测试用例一直是设计类的主要方向来源,并且随着系统的增长和变化,它们会被重构。
  4. 在模型类中,我认为通常不需要属性以外的任何东西。如果您正在对控制器类建模,通常明智的做法是同时包含主要属性和方法。
于 2009-11-18T00:48:13.390 回答
3

取决于 Web 应用程序的类型和大小。如果您正在做一个带有购物车的小型电子商务网站,那么您可能会在设计方面花费更多精力,而在“应用程序”功能上花费更少。相反,如果您正在构建一个包含许多数据输入屏幕的大型内部网站,那么您的大部分时间将花在业务逻辑和数据规则上。

就个人而言,我不相信严格的规范格式或流程。我会根据项目和客户进行定制,以便清晰地沟通。

假设需求已经记录在案,我总是试图为基于工作流的数据密集型 Web 应用程序生成两种类型的文档:

  1. 指示屏幕流程、状态变化和主要操作的高级工作流程图。作为充实应用程序中主要动作的第一步,我发现这非常有用。工作流通常与不同的用例相关。

  2. 每个输入屏幕的屏幕规格详细说明每个字段的格式和行为。通常包括字段类型、默认值、列表值、数据验证、可见性规则和可以触发的操作等。基本上是一个大表,确保开发人员知道如何构建屏幕。

我还在最近的项目中使用Balsamiq Mockups将 Web 应用程序屏幕组合在一起,屏幕模型已成为项目规范的重要组成部分——制作速度非常快,它们传达了很多关于屏幕应该如何工作的信息在文本文档中很难传达。

最后,Joel关于功能规格的系列是有用的阅读材料。

于 2009-11-18T01:06:07.367 回答
2

尽可能简单。

第一步是指定核心功能要求的文档。

就个人而言,由于 Web 应用程序几乎总是基于数据库,因此我开始根据功能需求对数据库进行建模。ERM图中的实体通常与UML图中的类1-1映射,并且已经显示了基本关系。

假设一个 MVC 体系结构和良好记录的代码,模型类将随着它们的发展而自我记录(例如氧气 phpdocumenter )。

我发现像 wiki 这样简单的东西最适合编写文档而不是正式文档,因为正式文档的编写时间比相应的代码要长,尤其是在敏捷环境中。

于 2009-11-18T18:18:46.527 回答
1
  1. 需求是一组文档,可以包括图形、Word 文档、电子邮件和其他记录事物的方式。开发环境(IDE、源代码控制、错误跟踪)、编码风格和指南中的内容列表是另一组文档,可用于建立成功的应用程序开发团队。有一个项目计划是一个大的甘特图和发布说明,这是我们创建的更多文档。
  2. 除了Gang of Four 在他们的网站上用来解释一些设计模式的东西之外,我还没有看到很多UML 图。
  3. 我们有待完成的项目积压,并估计每个故事的复杂程度。这可能与您使用的方法不同。使用我们的敏捷方法,可能没有您的情况那么多的设计/计划。
  4. 我们很少有类图,尽管 Visual Studio 确实有一个对象浏览器,可以方便地查看已经构建的内容。

在我工作的地方,我们倾向于成对工作来创建域对象及其成员、方法和属性。类是根据故事的需要创建的,或者如果我们正在清理或重构一组类。

没有完整的类列表,但有一些设计模式正在使用,例如 MVP,并且相信由于一对正在创建某些东西,因此代码将符合当前的样式和准则。随着需求的发展,课程会定期发生变化,但这对我来说似乎是一种自然的方式。

我所在环境的背景以防万一有人想知道:

在我工作的地方,我们目前有 5 名开发人员、一名 QA 负责人、一名业务分析师、一名团队负责人、一名架构师和一名项目经理作为项目的主要人员。我们在工作中使用 Scrum、结对编程和一些 TDD 理念。

我们正在使用 Visual Studio 2008、Subversion、HP Quality Center、ASP.Net 3.5、Sitecore 6.0 和 MS-SQL Server 2005。

于 2009-11-18T18:34:25.537 回答
0

所有用例必须非常详细,客户的持续合作将始终是一个加分项,但它仍然可能会出现无法预料的情况。

如果在不同时间轮询/推送消息的不同服务器之间开发交互,您肯定需要序列图

避免过度设计它,在类图中,不需要的类往往会迅速增加,减少它们,使用更多方法,跟踪每个类最终将运行的环境(一些将运行服务器端,一些客户端 - javascript - 一些将被安排作业并在真实服务器上运行,一些将被他的网络服务器封装并按需运行的cgi(或模块),一些将与数据库交互。

界定界限,明确界限。服务器端/客户端/数据库工作是不同的野兽,可能需要不同的时间和人员。

于 2009-11-18T01:26:57.633 回答