从哪里开始编程？

Question

一旦完成了第一组要求和设计，您在哪里开始编程？ （假设测试将以相同的顺序编写，但在代码之前）。

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

你有什么建议？

Answer 1

我从依赖链中的最低级别到最高级别工作。这样我就可以早点编译和测试，然后我可以随时随地进行编译。

Answer 2

我几乎总是从用户界面开始。一旦我确切知道将要发生什么以及发生了什么，我发现组织其他所有内容都更容易。

Answer 3

我从我的数据结构（数据库表，XTD，数据字典等）开始 那么数据将如何进出所述结构（数据访问层） 然后是Business Objects及其相关逻辑 最后，用户界面将这些程序化挂钩附加到我的业务逻辑

Answer 4

似乎所有发布此问题答案的人都会提出一个不同的起点。起点的广泛变化是真正开始的地方的完美例证： 的理想起点。

不同的人有不同的方法来处理问题。通常，项目的成功与最初的方法无关。花点时间思考并尝试不同的领域，首先关注并找出适合自己的方法。

编辑：在更抽象的层面上，this article by Paul Graham提供了对Lisp风格，自下而上的编程方法的深刻见解。

Answer 5

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

Answer 6

它必须取决于你正在创造什么。我正在开发一个Windows移动应用程序，从底层开始，处理类和各种数据抽象，然后用gui将它们全部插入，这是一场噩梦。你不能向人们展示（非开发人员）代码并说服他们你完成了40％，他们需要看到某种GUI。如果我可以回去，我会先模拟GUI。

但是当谈到数据驱动的网站时，我首先从数据开始，因为允许您操作它们的网页取决于知道数据的外观以及如何与之交互。

顺便说一句，我对“最简单”和“最难”的事情感兴趣，因为我认为人类的自然倾向是认为简单的事情会比现在容易得多，而事情会变得比现实更难。 ！

Answer 7

我喜欢从粗略的UI开始。

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

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

Answer 8

Re：Easy vs Hard项目优先：

我尝试做我认为首先更难的项目。这样一来，如果出现问题，你就更有可能获得并提前通知。此外，如果事实证明某些事情是无法实现的，那么你就不会浪费时间在一堆依赖且不再需要的小东西上。

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

Answer 9

我倾向于首先编写和测试支持框架类。我发现如果不这样做，我最终会在编译和测试之前编写太多代码。另外，首先编写它们意味着你将更倾向于使它们完全抽象，而不是使用它们过于依赖于代码的半生不熟的抽象。如果在编写支持类时没有编写更高级别的代码，则可以避免意外引入循环依赖。

也就是说，当我编写支持类时，我至少已经编写了代码片段，展示了如何在更高级别的代码中使用它们的示例。

Answer 10

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

使用Web应用程序我通常采用一种不同的方法：

1. 我倾向于首先构建一个粗略的html shell来了解该网站应该是什么样子。
2. 然后我从最简单的功能开始（在很多情况下，它是一个留言簿或类似博客的输入/显示数据类型），我首先在数据库中设置一个表，将其映射到我的数据提供者（实体框架，如果我在.Net）并让网站访问数据（还没有输入功能！）。
3. 当页面正确获取数据时（我通过手动将随机内容放入数据库进行测试），我开始处理网站此部分的输入部分。
4. 一旦网站的一个部分（例如留言簿）完成并按照我的要求完成工作，我将继续下一部分并再次从1开始。

Answer 11

最好的起点是imho，它是数据模式，然后是域模型，然后是模型和模型之间的任何业务逻辑。接口然后是接口。

根据您使用的技术和开发范例，它将作为业务需求自然扩展到编码领域，理想情况下，它应代表您的大部分需求。

真的，您需要考虑的是您正在构建的内容，您用于构建解决方案的设计模式，正在使用的相关技术以及它们如何相互关联（或不相关）及其依赖关系。

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

如果您有一个相当智能的数据库（所有表，完整性和内置于存储过程中的规则，用于执行所有错误检查和验证），并且具有相当无知的中间层（它所做的就是传递数据）设计，那么大部分工作和功能都在后面......

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

现在这是一个偏好问题。我喜欢进步，所以我开始构建“最简单”的东西 - 应用程序的“最简单”部分。对我来说，这有助于在代码级别为我整合整个过程 - 看到以相对频繁的速率落入到位的碎片。

但我总是将令人眼花缭乱的前端留在最后（或者我让其他人去做 - 我更喜欢这样做。）

这是一门艺术，因为它是一门科学......每一个项目都是不同的，除非你只是重复一个采用相同技术和流程的模式 - 在这种情况下，将其归结为科学并确保你采取远离每个项目的课程，以便您可以构建一个更有效的过程。

干杯

Answer 12

我更喜欢从更高级别（架构）部分开始，因为它们将更好地定义您在较低级别上特别需要的内容。如果你从较低的水平开始，那么你通常最终会将更高的水平放在一边，以适应你决定较低水平应该工作的方式。所以从本质上讲，你从较低的层次开始让你的工作变得更难，你的设计变得更难理解。更高级别的应用程序代码是您想要易于理解的部分，因此从我开始并确保它按照您希望的方式工作更有意义。

这通常意味着从UI开始并在构建UI时添加功能。

编辑：如果你不知道你正在从事更高层次的工作是什么？然后为更高级别的部分创建一个方法来调用并将工作推送到较低级别的模块。这对我来说简化了我的代码。

Answer 13

我同意到目前为止的普遍共识，即从应用程序的最低级别，数据层开始，然后从那里开始构建。对我而言，它非常有意义，因为业务逻辑构建在数据层之上，而前端建立在业务逻辑之上。

然而，只考虑一件事 - 您的客户。不幸的是，客户需要看到明显的变化才能知道您正在做某事。甚至技术经理也倾向于陷入这种心态，你会感到惊讶。

所以我尝试确保在每次迭代时也会对UI做一些事情，所以从某种意义上说，应用程序是用垂直线构建的。也就是说，一些数据，一些业务逻辑，一些UI，向客户展示。重复。

Answer 14

只要有可能，我就会从整个应用程序的路径开始。顽固地工作。这有助于阐明程序的整体架构。

完成后，我强烈建议您继续努力完成最难的部分。 （最难的部分也是风险最大的部分，也就是你信息最少的部分。）

为什么呢？因为你需要时间来找到所有缺失的信息，如果你不能使这部分工作，其他部分都被浪费了。

Answer 15

我喜欢从编写框架开始，然后将其他部分放在一起。

例如，我通常会编写一个我知道需要的类，然后在我有一些所需的功能后连接它......然后将继续执行周围的功能。

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

Answer 16

我作为一名熟练的程序员：

1. 规划数据结构
2. 制作粗略的UI版本
3. 编写应用程序逻辑
4. 对UI进行最后润色

在开发Django应用程序时，我首先定义模型，将一些恰当的模板放在一起，编写视图函数代码并完成UI上的剩余工作。所有这些步骤不可避免地重叠（比如在编码视图时更改Model类），但这对我来说是一般的路线图。