从哪里开始编程？

Question

一旦你有了第一套要求和设计，你就可以开始编程了吗？ （假设测试将以相同的顺序写入，但在代码之前）。

• 入口点
• 框架/技术支持类
• 实体类
• 最简单的事情第一
• 最难的事情第一

你有什么建议？

Answer 1

似乎每个人都发布了对这个问题的答案，并命名了一个不同的地方开始。出发点差异很大是你应该在哪里的完美例证真的是开始：无论你在哪里你的理想的出发点是。

不同的人有不同的接近问题的方式。项目的成功通常独立于所采取的初始方法。花时间思考并尝试不同的领域，首先关注并找出适合自己的方式。

编辑：在更抽象的层面上，this article by Paul Graham提供了一个Lisp风格，自下而上的编程方法的良好洞察力。

Answer 2

我从依赖链中的最低级别工作到最高级别。这样我就可以尽早编译和测试，然后我就可以继续编译和测试。

Answer 3

与我的数据结构（数据库表，XTD，数据字典等） 我开始那么数据将如何进入和离开所述结构（数据访问层） 那么企业与其关联的逻辑 最后对象，用户界面，并将这些编程钩子附加到我的业务逻辑

Answer 4

我倾向于首先编写和测试支持框架类。我发现，如果我不这样做，我最终会在编译和测试之前编写太多的代码。另外，首先写它们意味着你会更倾向于使它们完全抽象化，而不是用过于乱糟糟的代码来使用它们。如果您在编写支持类时没有编写更高级别的代码，则可以避免意外引入循环依赖。这就是说，当我编写支持类时，我至少已经编写了代码片断，显示了如何在更高级代码中使用它们的示例。

Answer 5

它必须取决于您正在创建的内容。我正在开发一个Windows移动应用程序，并开始自下而上，处理类和各种数据抽象，然后将它们与gui一起插入，这是一场噩梦。你不能向人们展示代码并且说服他们你已经完成了40％，他们需要看到某种GUI。如果我可以回去，我会首先模拟GUI。

但是当涉及到数据驱动的网站时，我只是从数据开始，纯粹是因为允许您操纵网页的网页取决于了解数据的外观以及与您的交互方式。另外，我对“最简单”和“最难”的事情感兴趣，因为我认为自然的人类倾向是认为简单的事情会比他们更容易，而艰难的事情会比事情更难是！

Answer 6

我喜欢从粗糙的UI开始。

这样可以更快速地讨论设计和要求如何都是错误的（即使每个人都签了字），并节省大量的浪费。

然而，这样做有点危险，因为大多数人都认为UI是大部分工作，并且不理解为什么当屏幕看起来几乎是最终的时候花费很长时间才能完成。

Answer 7

我几乎总是从用户界面开始。一旦我确切地知道将要发生的事情和发生的事情，我发现组织其他事情更容易。

Answer 8

使用桌面/命令行程序时，我通常按照Ted的建议并从依赖链（树）的顶部（根）开始，以便尽早测试和编译。然后我逐步向上（向上）链（树）添加类和复杂性。

与Web应用程序我通常采取有所不同的方法工作：

1. 我倾向于建立一个粗略的HTML外壳给的网站应该是什么样子的想法开始。
2. 然后我从最简单的功能开始（在许多情况下，它是一个留言本或类似博客的输入/显示数据类的东西），我首先在数据库中建立一个表，将它映射到我的数据提供者（如果我在.Net中的实体框架），并让网站访问数据（没有输入功能呢！）。
3. 当页面正确地获取数据时（我通过手动将随机数据放入数据库进行测试），我开始处理该部分的输入部分。
4. 一旦网站的一部分（例如留言）完成并按照我的意愿工作，我就继续下一部分，然后重新从1开始。

Answer 9

我同意迄今为止的一般共识，即您从应用程序的最低级别数据层开始，并从此处开始构建。对我来说，这是非常有意义的，因为业务逻辑建立在数据层之上，而前端建立在业务逻辑之上。

但是，只需考虑一件事 - 您的客户。不幸的是，客户需要看到明显的变化才能知道自己在做什么。即使是技术经理也倾向于这种思维方式，你会感到惊讶。

因此，我试图确保在每次迭代时都会对UI执行一些操作，因此从某种意义上说，应用程序是以垂直线构建的。也就是说，一些数据，一些业务逻辑，一些用户界面显示客户。重复。

Answer 10

就我个人而言，我认为你应该从领域模型开始。这在很大程度上可以直接从您的需求中提取，并且可以帮助您确定需要创建哪些部分。您的域模型将驱动您的数据模型，并且这些要求将告诉您必须对域对象执行哪些操作。

Answer 11

只要有可能，我会从整个应用程序的路径开始。与存根慷慨地工作。这有助于澄清程序的整体架构。

完成后，我强烈建议接下来最难的部分。 （最难的部分也就是最危险的部分，也就是你最不了解的部分）

为什么？因为您需要时间来查找所有缺少的信息，并且如果您无法使这部分工作，其他部分已被浪费。

Answer 12

回复：易VS硬项目的优先级：

我尝试做什么，我认为将是更难的项目第一。这样如果事情出错了，你很可能会得到并能够提前通知。另外，如果事实证明某些事情是无法实现的，那么你就不会浪费时间在一堆依赖和不再需要的小事上。

http://www.businessballs.com/rocks.htm

Answer 13

到最好的地方开始，恕我直言，是与模型之间的数据模式，然后域模型，然后任何业务逻辑&的界面，然后在界面。

根据您使用的技术和开发范例，它将作为业务需求的自然延伸到编码世界中，理想情况下它代表您的大部分需求。

真的，你需要考虑什么是你正在构建什么，您使用的建筑师解决方案的设计模式，所使用的相关技术，以及它们如何相互关联（或没有）和它们的依赖。

从限制因素开始 - 如果无法在没有数据模式的情况下构建适当的域模型，则从模式开始。

如果你有一个相当聪明的数据库（存储过程中内置的所有表，完整性和规则完成所有的错误检查和验证）与一个相当无知的中间层（它只是传递数据），然后设计工作和功能的大部分在于背部....

如果你有一个相当简单的数据库（只是表和字段）和一个非常聪明的中间层（所有的逻辑，验证和完整性检查完成这里）...大部分功能在中间...

现在，这是一个偏好问题。我喜欢进步，所以我开始构建“最简单”的东西 - 应用程序的“最简单”部分。对我而言，这有助于在代码级为我整理整个过程 - 以相对频繁的速度查看碎片。

但是我总是把眩目的前端留到最后（或者让别人去做 - 我更喜欢）。

它既是一门艺术，也是一门科学......每一个项目都是不同的，除非你只是用相同的技术和过程重复一个模式 - 在这种情况下，把它归结为一门科学，并确保你从每个项目中吸取教训，以便今后能够构建更高效的流程。

干杯

Answer 14

我喜欢写作的框架，然后让其他碎片掉下来，开始。例如，我通常会编写一个我知道会需要的类，然后一旦我具有一些所需的功能，就将其接口，然后继续执行周围的功能。

我喜欢这样做，因为如果感觉像意识流，当事情点击时它是非常令人满意的。

Answer 15

我拿个临时程序员：

1. 计划的数据结构
2. 做一个粗略的版本UI的
3. 编写应用程序逻辑上的UI

认沽收尾

在开发Django应用程序时，我会首先定义模型，将一些恰到好处的模板拼凑在一起，编码查看功能并完成UI上的剩余工作。所有这些步骤不可避免地重叠了一点（比如在编码视图时对模型类进行更改），但这将是我的一般路线图。

Answer 16

我更喜欢从更高层次（体系结构）部分开始，因为它们会更好地定义您在较低级别特别需要的内容。如果你从较低的层次开始，那么你通常最终会混淆更高的层次以适应你决定低层应该工作的方式。所以，从本质上说，你从较低的层次开始让你的工作变得更难，你的设计变得更难理解。更高层次的应用程序代码是您想要易于理解的部分，因此从头开始并确保其按照您的要求运行更加合理。

这通常意味着从用户界面开始并在构建用户界面时添加功能。

编辑：如果你不知道如何在你正在工作的更高层次上工作，然后创建一个方法让更高层次的作品调用并将作品推送到较低层次的模块。这对我来说简化我的代码并不奇怪。