我在工作中讨论这个问题，并且想知道人们在哪里开始他们的设计？我们倾向于从设计代码开始解决提交给我们的问题，但这可能是我们所有人（或者是）程序员。
我想知道其他人和组织在哪里开始他们的设计。他们是否首先将问题解决为编码问题，坐下来设计要使用的UI，或绘制出数据或工作流程？
由于
答案 0 :(得分：3)
我总是从工作流程/流程开始。我发现，当您开始建模业务流程/工作流时，您通常会获得更多信息，使UI更易于使用，并且代码/要求往往更适合用户需求。
人们通常会在真正理解工作流程之前就开始设计代码/ UI。话虽如此，如果您了解大局，那么您可以开始设计3个工作流程中的任何一个，代码，ui（以我的首选顺序）。
答案 1 :(得分：3)
我认为你对这个问题的答案（就目前而言）将主要反映由编写答案的人设计/创建的应用程序的类型。例如，如果您正在设计一个程序，它将从一个数据库（或某个来源）获取数据，根据需要按摩它，然后将结果放入另一个数据库中，很可能您将开始考虑数据库模式，数据流和数据编码/格式化（可能大约是那个顺序）。
另一方面，如果您正在编写打开文件类型的典型桌面程序，则允许用户编辑其内容，然后保存（无论是照片，文字处理文档，演示文稿还是其他内容） ）很可能数据库模式不会跳到你的思考前面。有人看过（例如）Microsoft Office文件格式的规格可能有空间来争辩说，在某些情况下，如果更多的前期思考被放入，那么设计会更好 格式，但通常不会。但
为了得到一个更有意义的答案，我认为你需要退一步，简单地说“你解决问题的方法是什么？”更像是：“问题类型与解决问题的方法之间有什么关系？”否则，你得到的大部分内容通常只不过是对这个人所处理的问题的间接陈述。
答案 2 :(得分：2)
为什么不从验收测试开始？
我在最近的项目中一直在推动的一件事是确保测试团队能够参与项目中的大量预算。如果您无法与客户达成验收标准，则必须提出问题，是否真的需要一些项目要求？
为此，我现在对测试试图以可测试方式捕获需求的框架非常感兴趣，例如：
也许一个前期的自动验收测试/需求管理框架将允许尝试多个解决方案。
答案 3 :(得分：1)
就个人而言，如果应用程序有UI，那就是我开始的地方，因为这通常会驱逐流程和工作流程。
Paper prototyping在我工作的地方有意义并重申设计。
如果这是一个命令行应用程序，我会在开始工作之前仔细考虑命令行选项，默认值和正常使用模式。
答案 4 :(得分：1)
我的一般工作流程倾向于遵循这些方针：
我通常构建嵌入式软件解决方案和/或GUI来连接这些系统并操纵它们/显示输出数据。
答案 5 :(得分：1)
我从工作流程和功能要求开始。我的工作独立于UI（通常使用命令行工具和脚本），几乎总是有三个测试框架（全功能/单元测试，快速“启动和运行”状态检查，以及性能压力测试）。最后一步是用户界面。
答案 6 :(得分：0)
我从需求的设计开始。如果需求要求用户界面，那么我倾向于将其设计为子任务，并将计算引擎（或任何你称之为的）设计为另一个子任务;这是一种MVC，M和V之间有明显的分离，C提供了它们之间的联系。因此，设计C成为另一个子任务。
但是我现在很少从头开始设计任何东西，我更有可能在现有系统中添加新模块和新功能。在这种情况下，大多数UI设计已经完成，因此有很多M设计。
我听说测试驱动设计现在是一项受欢迎的运动，因此测试可能是您考虑的另一个起点。
答案 7 :(得分：0)
我总是从需求开始，然后设计数据库，然后设计应用程序。在数据库之前设计的应用程序是问题的处方。我认为有趣的是，没有其他人甚至认为设计数据库非常重要。难怪有那么多不良的商业应用程序。
答案 8 :(得分：0)
我从原始数据开始。甚至没有数据结构，但有整数，浮点数，字符串数组，整数数组等。没有uml图表或用户要求，没有类层次结构或继承，没有类或函数接口，没有工作流程或进程。只有一个算法产生一组数据。
答案 9 :(得分：0)
我在编程和设计方面经验不多，但我所拥有的主要是与数据库连接，所以这就是我开始的地方。当我遇到问题时，我会坐下一小时画出数据库架构，创建它，然后添加我的SP和视图。
接下来，编写查询和表单，实际的HTML以及使它看起来非常漂亮的JS和CSS（或者不是，我的“设计”通常就是这种情况）。
所以，在MVC模型中，我想首先是M，然后是V？我对MVC的经验不多。
这是一种相对自然的方式吗？