我有兴趣在开始编码之前开始在纸上正确设计我的软件。这个的标准方法是什么？
我在想一些类似 UML 的东西，但我觉得这对于一个人的项目来说有点矫枉过正。
专业人士认为在开发业余爱好项目时最好做哪些事情？
预计投票将像往常一样结束，这没有争议。这是一个明确的答案，我期待一些确定的东西。:P
问问题
3242 次
13 回答
6
我尝试将问题通常分为两个不同的问题：
- 谁参与（这是上课的好人选）
- 正在发生什么（类似地，这往往是很好的方法，也是人们可能想要关注以确定性能要求的事情）。
例如：在一组可能的汽车中搜索最便宜的汽车时，我会将“最便宜”识别为可能想要成为单独功能的东西，因为我可能想稍后更改条件，或者将其应用于 SUV好吧，“汽车”和“汽车集”听起来像是我在问题领域需要的课程的好候选人。
要建立这些：
- 在问题描述中搜索动词：那些 make 方法
- 在问题描述中搜索名词：那些构成类
- 找到约束，以及它们与什么相关：最便宜的是某物的属性，还是操作的结果？
最终，我从进一步绘制这些关系转向伪代码和小型原型，以尝试并了解问题描述中出现的其他未知约束。
于 2009-10-27T23:23:37.967 回答
3
对于这类事情，我通常会勾勒出基本的 UI，绘制（纸上的方框）域模型和数据库模式。我总是从纸上开始，然后如果我觉得有必要，我会导出到 visio/basalmiq。
于 2009-10-27T23:18:55.343 回答
2
对于简单的程序，我会用纸和铅笔画出它的 UI 草图，并在上面做一些注释。它可以帮助我澄清我的想法并确认我的设计。
如果程序更大（我的意思更像是一个完整的产品），您可能需要从其他人那里收集一些反馈，因为一个人的想法无法涵盖所有内容。手绘草图依然有效，邀请更多人审阅并给你一些建议，这样你的设计就会有很多的润色。但是，如果您的朋友不在身边，您可能需要将纸质草图传真给他们（或者扫描纸质草图并通过电子邮件发送）。
有一些工具可以帮助您创建 UI 原型，其中一些甚至允许您运行 UI 模拟（如 Axare 和 ForeUI），这对于收集其他人的反馈非常有用。
于 2009-10-28T03:31:06.980 回答
1
这在很大程度上取决于事情的数量，最重要的是你在做什么。
1）我的第一步是声明你在做什么。好听，简单吗？有时不是。列出您希望程序执行的操作。列出什么是必须拥有的，什么是可以拥有的，什么是可以拥有的（包括在内并不麻烦）。
2) 第二步是（尽你所能）确定项目成功的最薄弱环节。如果您正在编写 WebDB，您应该担心的是 Web UI（从一个页面转换到另一个页面）和数据模型。如果您正在编写游戏，那么游戏规则将很重要。或者如果游戏是高度交互的，那么你应该将交互考虑为游戏的流程。
你在这里确定的是你应该花时间在纸上设计它。
由于识别这可能需要经验而您可能没有（如果您这样做，您已经知道该做什么，对 :-D），您可能会随着项目的进展不时回来查看它。
3）为了避免过度设计，专注于为理解建模，而不是为文档建模。
4）一旦你了解更多，尝试创建一个小程序来检查是否可以。如果是您，请确定其他关键但有风险的部分。
5）从小处着手，但始终考虑扩展。对我来说，想大一点是可以的，但做大是有风险的。
这些就是我所做的。希望它能给你一些想法。:-D
于 2009-10-27T23:54:06.190 回答
1
夹克口袋里没有什么像迷你记事本那样的东西，为了尽快转储，我个人在迷你UML和点点之间切换。快速、简单、始终可访问。
编辑：而且我总是有一个专门用于特定用例和操作的页面/区域。这使我可以回来检查系统是否可以处理其中的每一个。
于 2009-10-27T23:17:22.817 回答
1
我会使用 UML 不是因为它是事实上的行业标准，而是因为它可以帮助您在探索领域（无论是个人还是企业）时组织和记录您的想法。一个免费工具是 ArgoUML。
我将模拟 UI 作为另一种帮助来确定和交流你认为你想在你的系统中做的事情。Balsamiq Mockups 是一款很棒的免费工具。
我会首先关注行为，最后关注数据。参见 Rebecca Wirfs-Brock 的著作。
祝你好运！标记
于 2009-11-04T16:05:33.250 回答
0
This is the order of how I do things:
1) Write a pseudocode in pencil. This where you can brainstorm ideas with yourself and others if necessary.
2)Write the algorithm outlining the objectives and how you will go about accomplishing those objectives.
3)If the project is small, simple and clear to you, you can ommit this step. Else, draw up a flow chart of th application.
4)Lastly, Start coding using your algorithm and flow chart as your guide.
于 2009-10-27T23:43:32.013 回答
0
在我看来，你应该坚持你的最终目标，在大多数情况下，最终目标是将你的结果交付给你的客户、你的老板、你的同事。
所以你要做的一切都应该与目标一致。释放它并交付它。
我不认为在纸上设计是个好主意，它让你懒得做一些实际的工作。实际上大多数项目都来不及进入编码阶段，许多愚蠢的设计师或架构师都在争论几个星期在作战室中从未存在过的细节。他们推迟了项目。
实际上你应该学习更多关于测试驱动开发的思想，这并不意味着你应该完全遵循这种模式，而是一种思想，教你如何有效地致力于交付结果。
最后，我认为测试驱动是保持您向客户交付合格结果的承诺的最有效方式。
于 2009-10-28T00:31:54.190 回答
0
对于小型代码项目，我喜欢直接编写版本 0 的代码，创建我认为需要的所有类，并尝试让它们在某种程度上协同工作。然后我停下来，完全重新开始。这通常会创建一个更好的项目。
于 2009-10-29T13:30:00.397 回答
0
我的一些“技巧”：
我首先使用思维导图（例如 MindMeister）。
然后，我找到了可能的“难点”并进行了一些轻量级原型设计
于 2009-10-27T23:17:26.123 回答
0
我发现首先勾勒出 UI 非常有助于找出所需的功能。然后我喜欢为每个 UI 元素和它应该做什么做一个列表。一旦完成，我通常会写出一个数据库模式......
于 2009-10-27T23:29:27.970 回答
0
我非常喜欢使用 SketchFlow 来创建线框和模型，这确实有助于 Web/桌面应用程序的整个设计过程。您可以看到并触摸它，并证明您的想法确实有效。我也喜欢其他地方提到的思维导图（MindMeister）。最近我尽量避免使用 BDUF（预先设计的大设计）规范！
于 2009-10-28T20:12:55.777 回答
0
软件就像艺术，因为它具有创造性，并且解决问题的方式有无限的可能性。作为程序员，我们经常在设计之前跳入代码。设计甚至在查看技术解决方案之前就开始了。这些是应首先采取的一些步骤，以帮助限制设计范围。
- 定义你的目标。这些可能是您自己的，也可能由业务经理/产品经理提供给您。
- 识别资源限制。这可能是您可以使用的时间、金钱、硬件甚至是编程语言。
- 研究来自您的软件将参与的行业或环境的环境限制。例如法规或用户愿意接受的内容。
- 担心未来（但不要让自己发疯）。尽你最大的能力使设计从软件级别和功能级别可扩展。
- 然后开始迭代。尝试并开始迭代设计是很重要的。您将永远无法预料到一切，因此您会尽力而为，然后继续前进。
我写了一篇博客文章，使用非常规领域的示例更详细地描述了这些，但也适用于软件：
于 2015-06-05T13:25:11.330 回答