在编码时，根据您的经验，更好的方法是什么？
- 将问题分解成足够小的部分，然后实施每一部分。
- 分解问题，然后使用自上而下的方法实施。
- 任何其他？
carleeto
问问题
3963 次
13 回答
15
我倾向于设计自上而下并实施自下而上。
对于实现，构建最小的功能部件并将它们组装到更高级别的结构中似乎是最适合我的方法。但是，对于设计，我需要从整体情况开始，然后分解以确定这些部分将是什么。
于 2008-09-25T02:40:43.590 回答
12
这就是我所做的：
先了解领域。了解要解决的问题。确保您和客户（即使那个客户就是您！）对于要解决的问题在同一页面上。
然后针对这个问题提出一个高层次的解决方案，然后设计将变成页面上的气泡或项目符号或其他任何东西，但关键是它会变成可以设计的组件。
那时，我为尚未编写的类编写测试，然后充实这些类以通过这些测试。
我使用测试优先的方法并构建工作的、经过测试的组件。这对我有用。当组件接口已知并且“规则”知道它们如何相互通信并相互提供服务时，那么它通常会变成一个简单的“将所有东西连接在一起”的练习。
我就是这样做的，而且对我来说效果很好。
于 2008-09-25T01:28:44.543 回答
3
您可能想查看敏捷宣言。自上而下和自下而上的前提是“一次性构建”的设计和构造。
“工作软件优于综合文档”意味着您构建的第一件事是您可以运行的最小有用的东西。最佳？底部？两者都不。
当我年轻的时候，我从事的项目——根据合同——严格自上而下。这行不通。确实，它行不通。结果，您会得到大量的冗余设计和代码。盲目应用时，这不是一个合理的方法。
我注意到敏捷方法——有效的小部分——倾向于将问题分解为可以一次全部掌握的部分。自上而下/自下而上不再那么重要。事实上，这可能根本不重要。
哪些线索会：“你如何分解敏捷开发？” 诀窍是避免创建必须分解的大事物。如果你分析一个问题，你会发现参与者试图完成用例并且失败了，因为他们没有所有的信息，或者他们没有及时获得信息，或者他们无法执行他们的决定，或者类似的事情。
通常，这些不是需要分解的大事。当它们出现时，您需要在目标向后的方向上解决问题。从目标到使您能够实现该目标的事物，再到使促成因素成为可能的事物等。由于目标通常是大事物，因此这往往是自上而下的——从一般业务目标到详细的业务流程和步骤。
在某些时候，我们会概述导致目标的这些不同步骤。我们已经完成了分析部分（分解）。现在是综合部分：我们将我们拥有的东西重新组合成我们可以实际构建的东西。合成是自下而上的。但是，我们不要得意忘形。我们有几个观点，每个观点都不一样。
我们有一个模型。这通常从细节构建到更大的概念模型中。然后，有时会再次分解为针对 OLTP 规范化的模型。或者分解为针对 OLAP 规范化的星型模式。然后我们从标准化模型创建一个 ORM 映射。上 - 下 - 上。
我们有处理。这通常是从业务流程的总结到处理步骤的详细信息。然后围绕这些步骤设计软件。然后将软件分解为类和方法。向下-向上-向下。
[题外话。对于开明的用户，这种分解定义了新的职位和工作方式。对于未开化的用户，旧工作仍然存在，我们编写大量文档以将旧工作映射到新软件。]
我们有组件。我们经常看碎片，看看我们对可用组件的了解，并进行一种匹配。这是最随机的过程；它类似于晶体的形成方式——有成核中心，设计在这些中心周围凝固。网页服务。数据库。交易管理。表现。体积。不同的功能以某种方式帮助我们选择实现部分或全部解决方案的组件。经常感觉自下而上（从功能到产品），但有时是自上而下（“我拿着一把锤子，把所有东西都称为钉子”== 对所有事情都使用 RDBMS。）
最终我们必须编码。这是自下而上的。有点儿。您必须定义一个包结构。您必须将类定义为一个整体。那部分是自上而下的。您必须在类中编写方法。我经常做这种自下而上的——粗略的方法，写一个单元测试，完成方法。粗略下一个方法，写一个单元测试，完成方法。
驱动原则是敏捷——构建行之有效的东西。细节无处不在——上、下、前、后、数据、流程、参与者、主题区域、业务价值。
于 2008-09-25T01:22:45.900 回答
2
是的。做所有这些事情。
这可能看起来很讽刺（对不起，我恢复形式），但这确实是一个没有正确答案的情况。
于 2008-09-25T01:18:53.147 回答
2
同样以敏捷的方式，首先编写您的测试！
那么所有的软件都是一个不断循环的
- 红色 - 代码未通过测试
- 绿色 - 代码通过测试
- 重构——保留意图的代码改进。
缺陷，新功能，变化。这一切都遵循相同的模式。
于 2008-09-25T01:40:49.023 回答
1
你的第二个选择是一个合理的方法。如果您将问题分解为可理解的部分，则自上而下的方法将在您实施所有小细节之前揭示任何主要的设计缺陷。您可以为较低级别的功能编写存根，以将所有内容挂在一起。
于 2008-09-25T01:19:34.473 回答
1
我认为除了自上而下的设计之外，还有更多需要考虑的因素。您显然需要将设计分解为可管理的工作单元，但您还需要考虑优先级等。在迭代开发项目中，一旦您为前一个迭代交付了解决方案，您通常会为下一次迭代重新定义问题.
于 2008-09-25T01:29:07.443 回答
1
在设计时，我喜欢做中间。我喜欢对领域进行建模，然后设计类，然后从那里转移到数据库和 UI。如果有基于 UI 或基于数据库的特定功能，我也可以预先设计这些功能。
编码时，如果可能的话，我通常喜欢自下而上（首先是数据库，然后是业务实体，然后是 UI）。我发现使用这种方法更容易保持直截了当。
于 2008-09-25T01:40:17.027 回答
1
我相信，对于优秀的软件设计师（在我看来，所有软件开发人员在某种程度上也应该是软件设计师），其神奇之处在于能够同时进行自上而下和自下而上的工作。
我的导师“教育”我做的是从非常简短的自上而下开始了解所涉及的实体，然后转向自下而上找出我想要创建的基本元素，然后备份并看看我是如何可以向下一层，知道我对自下而上的结果的了解，依此类推，直到“他们在中间相遇”。
希望有帮助。
于 2009-05-13T15:25:12.600 回答
0
外向内设计。
你从你想要达到的最高端开始，你知道你必须在最低端做什么。继续工作，直到他们在中间相遇。
于 2008-09-25T01:31:50.357 回答
0
我有点同意所有人说“都不是”的观点，但每个人都属于范围内的某个地方。
我更像是一个自上而下的人。我选择了一个高级功能/点/任何东西，并将其作为一个完整的程序来实现。这让我在问题域的范围内勾勒出一个基本的计划和结构。
然后，我从另一个特性开始，将所有可以被第二个使用的原始特性重构为新的共享实体。起泡，冲洗，重复直到应用完成。
但是，我认识很多自下而上的人，他们听到问题并开始考虑在其之上构建应用程序可能需要的所有支持子系统。
我不相信任何一种方法是错误的或正确的。他们都可以取得成果。我什至试着找自下而上的人一起工作，因为我们可以从两个不同的角度来解决这个问题。
于 2008-09-25T01:56:15.087 回答
0
两者都是有效的方法。有时一个人只是“感觉”比另一个人更自然。但是，有一个大问题：一些主流语言，尤其是它们的框架和库，确实非常依赖IDE 支持，例如语法高亮、背景类型检查、后台编译、智能代码完成、IntelliSense 等。
但是，这不适用于自上而下的编码！在自上而下的编码中，您经常使用尚未实现的变量、字段、常量、函数、过程、方法、类、模块、特征、mixin、方面、包和类型！因此，IDE 会因为编译错误不断地对你大喊大叫，到处都是红色的波浪线，你将无法完成代码等等。因此，IDE 几乎禁止您进行自上而下的编码。
于 2008-09-28T04:27:40.383 回答
0
我做了一个自上而下的变体。我倾向于先尝试做界面 - 然后我将其用作我的功能列表。这个版本的好处是，它仍然适用于否则会抱怨的 IDE。只需注释掉对尚未实现的功能的一个函数调用。
于 2009-01-13T19:56:07.003 回答