我对在多开发人员团队方案中学习如何设计/规划Web应用程序开发感兴趣。
假设“项目经理/主管”的角色:
如果您有任何有用的图书/网站建议,请分享。
跟进(2009年11月18日添加): 编码器/开发人员在编码期间使用什么作为指导,即创建课程,以及他们各自的方法&属性?
如果没有完整(但可变)的类列表及其方法和属性,那么这种模糊性是否会导致严重依赖每个编码人员的知识/经验,从而导致代码质量/可用性/可维护性的偏差?
答案 0 :(得分:10)
答案 1 :(得分:3)
取决于网络应用的类型和大小。如果您正在使用购物车进行小型电子商务网站,那么您可能会在设计方面投入更多精力而不是“应用”功能。相反,如果您正在构建一个包含许多数据输入屏幕的大型内部网站,那么您的大部分时间将花在业务逻辑和数据规则上。
就个人而言,我不是严格规范格式或流程的信徒。我会根据项目和客户进行定制,以便清楚地进行沟通。
假设已经记录了需求,我总是试图为基于工作流的数据密集型Web应用程序生成两种类型的文档:
高级工作流程图,指示屏幕流程,状态更改和主要操作。 我发现这非常有用,作为充实应用程序中主要动作的第一步。工作流程通常与不同的用例相关。
每个输入屏幕的屏幕规格,详细说明每个字段的格式和行为。 通常包括字段类型,默认值,列表值,数据验证,可见性规则和可触发的操作等。基本上是一个大表,确保开发人员知道如何构建屏幕。
我还在最近的项目中使用了Balsamiq Mockups将Web应用程序屏幕组合在一起,屏幕模型已成为项目规范的重要组成部分 - 生成速度非常快,并且它们传达了大量有关屏幕应该如何工作,这在文本文档中很难传达。
最后,乔尔的series on functional specs是有用的阅读。
答案 2 :(得分:2)
尽量保持简单。
指定核心功能要求的文档是第一步。
就个人而言,由于Web应用程序几乎总是基于数据库,因此我开始根据功能要求对数据库进行建模。 ERM图中的实体通常使用UML图中的1-1来映射,并且已经显示了基本关系。
假设一个MVC架构和记录良好的代码,Model类将随着它们的发展而自我记录(例如,氧气phpdocumenter)。
我发现像wiki这样简单的东西最适合编写文档而不是正式文档,这些文档的编写时间比相应的代码要长,特别是在敏捷环境中。
答案 3 :(得分:1)
在我工作的地方,我们倾向于成对工作来创建域对象及其成员,方法和属性。根据故事的需要或者如果我们正在清理或重构一组类,就会创建类。
没有完整的类列表,但有一些设计模式正在使用,如MVP和信仰,因为一对正在创建一些东西,代码将符合当前的风格和指南。随着需求的不断变化,课程会经常发生变化,但这似乎是为我做事的一种自然方式。
环境背景,以防万一有人想知道:
在我工作的地方,我们目前有5名开发人员,QA负责人,业务分析师,团队负责人,架构师和项目经理作为项目的主要人员。我们在工作中使用Scrum,结对编程和一些TDD思想。
我们正在使用Visual Studio 2008,Subversion,HP Quality Center,ASP.Net 3.5,Sitecore 6.0和MS-SQL Server 2005.
答案 4 :(得分:0)
所有用例必须非常详细,来自客户的持续合作将始终是一个优势,它仍然可以发布无法预料的案例。
如果在不同服务器之间开发交互,在不同时间轮询/推送消息,您肯定需要Sequence Diagrams。
避免过度设计,在类图中,不需要的类往往会出现问题,减少它们,使用更多方法,跟踪每个类最终将运行的环境(有些将运行服务器端,一些客户端--javascript - 一些将是预定的作业并在真实服务器上运行,一些将由网络服务器封装的cgi(或模块)并按需运行,一些将与数据库连接。
定义边界,明确界限。服务器端/客户端/数据库工作是不同的动物,可能需要不同的时间和人。