一旦你完成了你的第一组需求和设计，你从哪里开始编程？（假设测试将以相同的顺序编写，但在代码之前）。
- 入口点
- 框架/支持类
- 实体类
- 先说最简单的
- 先说最难的
你有什么建议？
问问题
774 次
16 回答
7
我从依赖链中的最低层工作到最高层。这样我就可以尽早编译和测试一些东西，然后我就可以在它的基础上进行构建。
于 2009-05-18T19:48:39.240 回答
7
我几乎总是从用户界面开始。一旦我确切地知道什么进出什么，我会发现组织其他一切变得更容易。
于 2009-05-18T19:54:21.943 回答
5
我从我的数据结构（数据库表、XTD、数据字典等）开始，然后是数据如何进出所述结构（数据访问层），然后是业务对象及其相关逻辑，最后是用户界面并附加这些我的业务逻辑的编程挂钩
于 2009-05-18T19:49:42.187 回答
5
似乎每个发布此问题答案的人都指定了不同的起点。起点的巨大差异完美地说明了您应该真正从哪里开始：您理想的起点在哪里。
不同的人有不同的处理问题的方法。通常，一个项目的成功与一个人采用的初始方法无关。花时间思考并尝试不同的领域，首先关注并找出适合您的领域。
编辑：在更抽象的层面上，Paul Graham 的这篇文章对 Lisp 风格的自下而上的编程方法提供了很好的见解。
于 2009-05-18T19:58:28.643 回答
3
就个人而言，我认为您应该从域模型开始。这将在很大程度上直接从您的需求中提取，并将帮助您确定需要创建哪些部分。您的领域模型将驱动您的数据模型，需求将告诉您必须对领域对象做什么。
于 2009-05-18T20:07:33.210 回答
2
回复：简单 vs 困难项目优先级：
我尝试先做我认为更难的事情。这样，如果出现问题，您更有可能获得并能够提前通知。此外，如果事实证明某些事情是无法实现的，您不会将时间浪费在一堆依赖且不再需要的小事情上。
于 2009-05-18T20:35:42.980 回答
2
它必须取决于你正在创造什么。我正在开发一个 Windows 移动应用程序，从自下而上开始，处理类和各种数据抽象，然后用 gui 将它们全部插入，这是一场噩梦。你只是不能向人们（非开发人员）展示代码并让他们相信你已经完成了 40%，他们需要看到某种 GUI。如果我可以回去，我会先模拟 GUI。
但是当涉及到数据驱动的网站时，我纯粹从数据开始，因为允许您操作它们的网页取决于了解数据的外观以及您可能如何与之交互。
顺便说一句，我对“最简单”和“最难”的事情感兴趣，因为我认为人类的自然倾向是认为简单的事情会比实际情况更容易，而困难的事情会比实际情况更难！
于 2009-05-18T19:53:57.620 回答
2
我喜欢从粗略的 UI 开始。
这样可以更快地讨论设计和需求是如何错误的（即使每个人都签署了它们），并节省了大量浪费的精力。
然而，这有点危险，因为大多数人认为 UI 是大部分工作，并且不会理解为什么当屏幕看起来几乎是最终完成时要花这么长时间才能完成。
于 2009-05-18T19:54:10.727 回答
1
恕我直言，最好的起点是数据模式，然后是域模型，然后是模型和接口之间的任何业务逻辑，然后是接口。
根据您使用的技术和开发范例，它将作为您的业务需求到编码世界的自然扩展，因为它应该在理想情况下代表您的大部分需求。
实际上，您需要考虑的是您正在构建的内容、用于构建解决方案的设计模式、正在使用的相关技术以及它们如何相互关联（或不相互关联）及其依赖关系。
从限制因素开始——如果没有数据模式就无法构建足够的领域模型，那么就从模式开始。
如果你有一个相当智能的数据库（所有的表、完整性和规则都内置在存储过程中，它们会进行所有的错误检查和验证）和一个相当无知的中间层（它所做的只是传递数据）设计，那么大部分工作和功能在后面....
如果你有一个相当简单的数据库（只有表和字段）和一个非常智能的中间层（所有的逻辑、验证和完整性检查都在这里完成）......大部分功能都在中间......
现在这是一个偏好问题。我喜欢进步，所以我从构建“最简单”的东西开始——应用程序的“最简单”部分。对我来说，这有助于我在代码级别将整个过程具体化 - 以相对频繁的速度查看各个部分。
但我总是把令人眼花缭乱的前端留到最后（或者我让其他人来做——我更喜欢）。！！
它既是一门艺术，也是一门科学……每个项目都是不同的，除非你只是用相同的技术和流程重复一个模式——在这种情况下，把它分解成一门科学，并确保你从中吸取教训每个项目，以便您可以编写一个更有效的流程。
干杯
于 2009-05-18T20:44:53.867 回答
1
我更喜欢从更高级别（架构）部分开始，因为它们将更好地定义您在较低级别特别需要的内容。如果您从较低级别开始，那么您通常最终会混淆较高级别以适应您认为较低级别应该工作的方式。因此，从本质上讲，您从较低级别开始会使您的工作变得更加困难，并且您的设计变得更难理解。更高级别的应用程序代码是您希望易于理解的部分，因此从那里开始并确保它完全按照您的意愿工作对我来说更有意义。
这通常意味着从 UI 开始，并在构建 UI 时添加功能。
编辑：如果您不知道在您工作的更高级别上将如何工作；然后为更高级别的部分创建一个方法来调用并将工作推送到较低级别的模块。这在简化我的代码方面对我来说确实很神奇。
于 2009-05-18T21:04:49.303 回答
1
我倾向于首先编写和测试支持的框架类。我发现如果我不这样做，我最终会在编译和测试之前编写太多代码。此外，首先编写它们意味着您将更倾向于使它们完全抽象，而不是与使用它们的代码过于乱伦耦合的半生不熟的抽象。如果您在编写支持类时没有编写更高级别的代码，您将避免意外引入循环依赖。
也就是说，当我编写支持类时，我至少已经编写了代码片段，展示了如何在更高级别代码中使用它们的示例。
于 2009-05-18T19:53:36.717 回答
1
使用桌面/命令行程序时，我通常按照 Ted 的建议从依赖链（树）的顶部（根）开始，以便尽早测试和编译。然后我逐步向下（向上）添加类和复杂性链（树）。
使用 Web 应用程序时，我通常会采取一些不同的方法：
- 我倾向于从构建一个粗略的 html shell 开始，以了解网站应该是什么样子。
- 然后我从最简单的功能开始（在许多情况下，它是一个留言簿或类似博客的输入/显示数据类型的东西），我首先在数据库中设置一个表，将它映射到我的数据提供者（如果是实体框架）我在 .Net 中）并让网站访问数据（还没有输入功能！）。
- 当页面正确获取数据时（我通过手动将随机内容放入数据库进行测试）我开始处理网站这一部分的输入部分。
- 一旦网站的一个部分（例如留言簿）完成并完全按照我的意愿工作，我会继续下一部分并从 1 重新开始。
于 2009-05-18T19:58:57.940 回答
0
我喜欢从编写框架开始，然后让其他部分拼凑起来。
例如，我通常会编写一个我知道需要的类，然后在我有一些所需的功能时对其进行接口......然后将继续使用周围的功能。
我喜欢用这种方式做事，因为如果感觉像是意识流，当事情发生时，它是非常令人满意的。
于 2009-05-18T20:53:40.433 回答
0
我作为熟练程序员的看法：
- 规划数据结构
- 制作一个粗略的 UI
- 编写应用程序逻辑代码
- 对 UI 进行最后的润色
在开发 Django 应用程序时，我会首先定义模型，将一些刚刚合适的模板组合在一起，编写视图函数并完成 UI 上的剩余工作。所有这些步骤不可避免地会有一些重叠（比如在编写视图时对模型类进行更改），但这对我来说是一般的路线图。
于 2009-05-18T21:03:24.487 回答
0
只要有可能，我都会从整个应用程序的路径开始。慷慨地处理存根。这有助于阐明程序的整体架构。
完成后，我强烈建议接下来进行最难的部分。（最难的部分，也就是最危险的部分，也就是你掌握的信息最少的部分。）
为什么？因为你需要时间来找到所有缺失的信息，如果你不能让这部分工作，其他部分就被浪费了。
于 2009-05-18T20:31:12.227 回答
0
我同意到目前为止的普遍共识，即您从应用程序的最低级别（数据层）开始并从那里构建。对我来说这很有意义，因为业务逻辑建立在数据层之上，而前端则建立在业务逻辑等之上。
然而，只考虑一件事——你的客户。不幸的是，客户需要看到可见的变化才能知道您正在做某事。你会惊讶地发现，即使是技术经理也倾向于落入这种心态。
因此，我尝试确保在每次迭代中对 UI 也进行一些处理，因此从某种意义上说，应用程序是在垂直线中构建的。即一些数据，一些业务逻辑，一些UI，展示给客户。重复。
于 2009-05-18T20:03:24.747 回答