Artifacts 你们生产什么基本的设计产品？

在软件开发生命周期的过程中，您会产生哪些基本的设计工件？是什么使它们对你的实践至关重要

---

我目前正在进行的项目已经投入生产8年多了。在此期间，此web应用程序得到了积极的增强和维护。虽然我们有基于CMMI的政策和流程，我们的实践部分得到了很好的定义，但设计阶段在很大程度上被忽略了。最佳实践，有人吗

工作代码…和白板图纸

---

：p

设计在开发过程中和开发之后都发生了巨大的变化，以至于我精心编制的大多数文档都会在源代码管理中腐烂，一旦代码投入生产，它们几乎就成了阻碍而不是帮助。我认为设计文档对于良好的沟通和在开发过程中澄清您的想法是必要的，但在这之后，需要付出巨大的努力来保持它们的正确维护

我确实拍摄了白板的照片，并将JPEG保存到源代码管理。这些是我最好的设计文档

在我们的模型中（相当特定于业务流程应用程序），设计人工制品包括：

• 域数据模型，对每个实体和属性都有注释
• 列出每个实体上的所有修改和创建触发器、计算属性、验证器和其他业务逻辑的属性文件
• 一组屏幕定义（视图模型）

然而，这些真的算是设计艺术品吗？我们的框架是这样的，这些定义用于生成系统的实际代码，因此它们可能超出了设计范围

---

但事实上，它们的双重职责非常强大，因为根据定义，它们是最新的，并且始终与代码同步。

过去曾参与过许多瀑布式项目，最近又参与了许多临时和敏捷项目，我喜欢创建许多设计工件，尽管我不能充分说明它实际上取决于项目的细节（方法/团队结构/时间尺度/工具等）

对于一个通用的、基于服务器的“企业应用程序”，我希望最低限度是以下几点：

• 详细的功能设计文件（又名规范）。虽然可能有一些UML用例图，但总体上与Joel s’的思路一致
• 软件技术设计文档。不一定要详细说明100%的系统覆盖率，但要详细说明所有关键领域，并包含所有设计决策。作为一个有点UML怪胎的人，看到大量的图片，包括包图、组件图、关键特性类图，可能还有一些序列图是很好的度量
• 基础设施设计文档。可能是概念设计的UML部署图，或者是更物理的网络图

当我说文档时，上面的任何一个文档都可能被分解成多个文档，或者存储在wiki/其他工具上

至于它们的有用性，我的理念一直是，开发团队应该始终能够将应用程序移交给支持团队，而不必交出他们的电话号码。如果设计工件没有清楚地指出应用程序做什么、如何做以及在哪里做，那么您知道支持团队将给予应用程序与狂犬一样的关心和关注

---

我应该提到的是，我并不是在证明一旦软件完成就将软件从开发团队移交给支持团队的做法是正确的，这会引发各种有趣的问题，我只是说，如果管理层愿意，这应该是可能的。

这本身不是一个设计文档，但是我们的单元测试具有双重目的，即“描述”它们测试的代码应该如何运行。这一点的好处在于，它们永远不会过时，因为我们的单元测试必须通过才能使构建成功。

我认为任何东西都不能取代好的老式设计规范，原因如下：

• 它是一种向他人传达您将如何构建应用程序的方式
• 它可以让你从头脑中获得想法，这样你就不用担心同时跟踪一百万件事情
• 如果你不得不暂停一个项目，然后再回到它，你就不会重新开始你的思考过程

我喜欢在设计规范中看到各种信息：

• 对您应对当前挑战的方法的一般说明
• 您将如何监控您的应用程序
• 安全问题是什么？如何解决
• 流程图/顺序图
• 公开问题
• 已知的限制

---

单元测试虽然是应用程序开发中一个非常重要的项目，但并没有涵盖所有这些主题。

对于采用JIT设计的敏捷交付方法（如SCRUM），您的答案是否相同？你有什么要补充的吗？你想移除什么？