如何在没有过度工程的情况下开始在纸上设计我的程序？

Question

我有兴趣在开始编码之前开始在纸上正确设计我的软件。这是什么标准方法？

我正在考虑UML的一些内容，但我觉得这对单人项目来说有点过分了。

专业人士认为在开发爱好项目时最好做些什么？

预计投票将像往常一样关闭，这不是争论性的。这是一个明确的答案，我期待建立一些东西。 ：P

Answer 1

我尝试将问题分解为两个不同的问题：

• 参与的人（这是课程的好候选人）
• 正在发生的事情（类似地，这往往是很好的方法，也是人们可能想要关注的事情，以建立性能要求）。

例如：当在一组可能的汽车中搜索最便宜的汽车时，我会将“最便宜的”识别为可能想要成为单独功能的东西，因为我可能希望稍后更改条件，或者应用它对于SUV而言，“汽车”和“汽车套装”听起来像是我在问题领域需要的课程的好候选人。

建立那些：

• 在问题描述中搜索动词：那些制作方法
• 在问题描述中搜索名词：那些使类
• 找到约束，以及它们的相关性：是最便宜的某种属性，还是操作的结果？

最终，我将这些关系进一步绘制为伪代码和小型原型，以便了解问题描述中出现的其他未知约束。

Answer 2

对于这种事情，我通常会勾画出基本的用户界面，图表（纸上的方框）一个域模型和一个数据库模式。我总是从纸上开始然后如果我认为有必要我导出到visio / basalmiq。

Answer 3

对于简单的程序，我将使用纸和笔绘制其UI的草图，在其上做一些注释。它可以帮助我澄清我的想法并确认我的设计。

如果程序更大（更像是我所说的完整产品），您可能需要收集其他人的一些反馈，因为一个人的想法无法涵盖所有​​内容。手绘草图仍然有效，邀请更多人查看它并给你一些建议，因此你可以大大改善你的设计。但是，如果您的朋友不在身边，您可能需要将纸质草图传真给他们（或者扫描纸质草图并通过电子邮件发送）。

有一些工具可以帮助您创建UI原型，其中一些甚至允许您运行UI的模拟（如Axare和ForeUI），这对收集其他人的反馈非常有用。

Answer 4

在夹克口袋里面没有像迷你记事本那样的东西，为了尽快转储，我个人在迷你UML和点之间切换。快速，简单，始终可访问。

编辑：我总是有一个专门用于特定用例和操作的页面/区域。这允许我回来检查系统是否可以处理这些中的每一个。

Answer 5

这在很大程度上取决于事物的数量，而最重要的是你在做什么。

1）我的第一步是宣布你在做什么。听起来很简单？有时不是。列出您希望程序执行的操作。列出必须拥有的东西，什么是好的，什么是可以拥有的（包括在内的麻烦不多）。

2）第二步（最好）确定项目成功的最薄弱环节是什么。如果您正在编写WebDB，您应该担心的是Web UI（从页面转换到另一个页面）和数据模型。如果您正在编写游戏，游戏规则将非常重要。或者如果游戏具有高度的互动性，那么你应该考虑游戏流程的相互作用。

您在此处确定的是您应该花时间在纸上设计它。

由于识别可能需要经验并且您可能没有（如果您这样做，您将已经知道该做什么，正确:-D），您可能会在项目进展后一段时间回来查看它。

3）为了避免过度工程，专注于建模以便理解，而不是建模作为记录。

4）一旦你了解更多，尝试创建一个小程序来检查是否可能。如果你，找出其他关键但有风险的部分。

5）从小开始，但总是考虑扩展。对我来说，做大做是可以的，但做大做是冒险的。

这就是我的工作。希望它会给你一些想法。 :-D

Answer 6

我使用UML并不是因为它是事实上的行业标准，而是因为它可以帮助您在探索域名（无论是个人还是业务）时组织和记录您的想法。免费工具是ArgoUML。

我将UI作为另一个辅助工具，用于计算和传达您认为自己想要在系统中执行的操作。一个很棒的免费版本是Balsamiq Mockups。

我首先关注行为，最后关注数据。见Rebecca Wirfs-Brock的着作。

祝你好运！标记

Answer 7

我的一些“伎俩”：

• 我首先使用思维导图（例如MindMeister）。

• 然后，我找到可能的“困难点”并进行一些轻量级原型制作

Answer 8

我发现首先勾画出UI非常有助于找出所需的功能。然后我想为每个UI元素制作一个列表以及它应该做什么。一旦完成，我通常会写出一个数据库模式...

Answer 9

这是我做事的顺序：

1）用铅笔写一个伪代码。如果有必要，您可以在这里与自己和他人集思广益。

2）编写算法概述目标以及如何实现这些目标。

3）如果项目规模小，简单明了，您可以省略此步骤。否则，请绘制应用程序的流程图。

4）最后，使用您的算法和流程图作为指南开始编码。

Answer 10

在我看来，你应该坚持自己的最终目标。在大多数情况下，最终目标是将结果传递给您的客户，老板和同事。

所以你所要做的就是与目标保持一致。释放它并交付它。

我认为在纸上设计不是一个好主意，它让你懒得去做一些实际的工作。实际上大多数项目都进入编码阶段已经太晚了，许多愚蠢的设计师或建筑师都在争论几个星期以来在战争室里从未存在过的细节。他们推迟了这个项目。

实际上你应该学习更多关于测试驱动开发的想法，但这并不意味着你应该完全遵循这种模式，它是一种思想教你如何有效地承诺自己提供结果。

最后，我认为测试驱动是保持您的承诺为客户提供合格结果的最有效方式。

Answer 11

我非常喜欢使用SketchFlow创建线框和模型，这真的有助于整个网络/桌面应用程序的设计过程。您可以看到它并触摸它并证明您的想法确实有效。我也喜欢思维导图（MindMeister）提到的其他地方。最近我试着避免BDUF（大前设计）规格！

Answer 12

对于小代码项目，我喜欢进入并编写版本0，创建我认为我将需要的所有类，并试着让它们一起工作。然后我停下来，完全重新开始。这通常会创建一个更好的项目。

Answer 13

软件就像艺术，因为它具有创造性，在解决问题的方式上有无限的可能性。作为程序员，我们经常在设计之前跳入代码。在设计技术解决方案之前就已开始设计。这些是应该首先采取的一些步骤，以帮助限制设计的范围。

• 定义您的目标。这些可能是您自己的，也可能是业务经理/产品经理给您的。
• 确定资源限制。这可能是您可以使用的时间，金钱，硬件甚至编程语言。
• 研究来自您的软件所属行业或环境的环境约束。例如法规或用户愿意接受的内容。
• 担心未来（但不要让自己疯狂）。在您的能力范围内，使设计从软件级别和功能级别进行扩展。
• 然后开始迭代。重要的是尝试并开始迭代设计。你永远无法预料到一切，所以你要努力，然后继续前进。

我写了一篇博文，使用非常规字段中的示例更详细地描述了这些内容，但适用于软件：

Design like Einstein and Michelangelo