编码时，您的体验是更好的方法吗？
答案 0 :(得分：15)
我倾向于自上而下设计并实现自下而上。
为了实现，构建最小的功能部件并将它们组装到更高级别的结构中似乎最适合我。但是，对于设计，我需要从整体画面开始并将其分解以确定这些作品的内容。
答案 1 :(得分：12)
这就是我的所作所为：
首先了解域名。了解要解决的问题。确保您和客户（即使该客户就是您！）与要解决的问题在同一页面上。
然后针对这个问题提出了一个高级别的解决方案，并且由此，设计将变成页面上的气泡或子弹或其他任何东西，但重点是它会摇摆成可以设计的组件。
此时，我为尚未编写的类编写测试，然后充实类以通过这些测试。
我使用测试优先方法并构建可运行的，经过测试的组件。这对我有用。当组件接口是已知的并且“规则”已经知道它们如何相互通信并相互提供服务时，它通常变得简单“将所有事物连接在一起”练习。
我就是这样做的，而且对我来说效果很好。
答案 2 :(得分：3)
您可能希望查看Agile Manifesto。自上而下和自下而上取决于Built It All At Once设计和构造。
“综合文档上的工作软件”意味着您构建的第一件事是您可以运行的最小有用的东西。最佳？底部？都不是。
当我年轻的时候，我参与的项目 - 通过合同 - 严格自上而下。这不起作用。确实，它无法奏效。结果，你会得到多余的设计和代码。当盲目地应用时，这不是一个合理的方法。
我注意到的是敏捷方法 - 有效的小块 - 往往会将问题分解为可以同时掌握的部分。自上而下/自下而上不再重要。实际上，它可能无关紧要。
哪条线索：“你如何分解敏捷开发？”诀窍是避免创建必须分解的 A Big Thing 。如果你分析一个问题，你会发现演员试图完成用例并失败，因为他们没有所有的信息，或者他们没有及时，或者他们无法执行他们的决定，或类似的事情。
通常，这些都不是需要分解的大事。如果是，您需要在目标向后方向解决问题。从目标到能够使目标成为能够实现推动者的事物的事物等等。由于目标往往是大事，这往往是自上而下 - 从一般业务目标到详细的业务流程和步骤。
在某些时候，我们会概述导致这些目标的各种步骤。我们已经完成了分析部分（打破了局面）。现在是合成部分：我们将我们所拥有的东西重新组合成我们可以实际构建的东西。合成是自下而上的。但是，让我们不要忘掉。我们有几个观点，每个观点都不同。
我们有一个模特。这通常是根据细节构建成更大的概念模型。然后，有时会再次分解为针对OLTP规范化的模型。或者分解为针对OLAP规范化的星型模式。然后我们重新开始从标准化模型创建ORM映射。 Up - Down - Up。
我们有加工。这通常是根据业务流程摘要构建到处理步骤的详细信息中。然后围绕这些步骤设计软件。然后将软件分解为类和方法。 Down - Up - Down。
[题外话。对于开明的用户，这种分解定义了新的职位和工作方式。随着未开明的用户，旧的工作留下来，我们编写大量文档来将旧工作映射到新软件。]
我们有组件。我们经常查看这些部分，查看我们对可用组件的了解，并进行一种匹配。这是最愚蠢的过程;它类似于晶体形成的方式 - 存在成核中心和围绕这些中心固化的设计类型。网页服务。数据库。交易管理。性能。体积。不同的功能以某种方式帮助我们选择实现部分或全部解决方案的组件。通常感觉自下而上（从功能到产品），但有时自上而下（“我拿着锤子，称之为钉子”==使用RDBMS来处理所有事情。）
最终我们必须编码。这是自下而上的。的种类。您必须定义包结构。您必须将类定义为一个整体。那部分是自上而下的。你必须在类中编写方法。我经常自下而上 - 粗略地说出方法，编写单元测试，完成方法。粗略地说出下一个方法，编写单元测试，完成方法。
敏捷的驱动原则 - 构建有效的东西。详细信息遍布地图 - 上，下，前，后，数据，流程，演员，主题领域，商业价值。
答案 3 :(得分：2)
是。做所有这些事情。
看起来似乎很讽刺（对不起，我还要表格），但这确实是一个没有正确答案的情况。
答案 4 :(得分：2)
同样以敏捷方式，首先编写测试！
然后所有软件都是
的连续循环缺陷，新功能，变化。这一切都遵循相同的模式。
答案 5 :(得分：1)
你的第二个选择是合理的方式。如果您将问题分解为可理解的块，那么在您实现所有细节之前，自上而下的方法将揭示任何主要的设计缺陷。您可以为较低级别的功能编写存根，以便将所有内容保持在一起。
答案 6 :(得分：1)
我认为除了自上而下的设计之外，还有更多考虑因素。您显然需要将设计分解为可管理的工作单元，但您还需要考虑优先级等。在迭代开发项目中，一旦您为前一个解决方案提供了解决方案，您通常会重新定义下一次迭代的问题。
答案 7 :(得分：1)
在设计时，我喜欢中断。我喜欢为域建模，然后设计类，从那里移动到数据库和UI。如果有基于UI或基于数据库的特定功能，我也可以预先设计这些功能。
在编码时，我通常喜欢自下而上（数据库优先，然后是业务实体，然后是UI），如果可能的话。我发现用这种方法保持正确的方式要容易得多。
答案 8 :(得分：1)
我相信，对于优秀的软件设计师（在我看来，所有软件开发人员也应该是某种程度上的软件设计师），神奇的是能够同时进行自上而下和自下而上。
我的导师所做的“教育”是从上到下非常简短地了解所涉及的实体，然后自下而上找出我想要创建的基本元素，然后备份和看看我怎样才能达到一个级别，知道我对自下而上的结果的了解，等等，直到“他们在中间相遇”。
希望有所帮助。
答案 9 :(得分：0)
外部设计。
你从最高端想要达到的目标开始，你知道你必须在底端做些什么。继续工作，直到他们在中间相遇。
答案 10 :(得分：0)
我同意所有人都说“不”，但每个人都在某种程度上。
我更像是一个自上而下的人。我选择一个高级功能/点/任何东西，并将其作为一个完整的程序实现。这让我可以在问题域的范围内勾勒出一个基本的计划和结构。
然后我从另一个功能开始，重构从原来可以被第二个使用到新的共享实体的所有内容。泡沫，冲洗，重复直至涂抹完成。
然而，我知道很多人是自下而上的人，他们听到了问题，并开始考虑他们可能需要在其上构建应用程序所需的所有支持子系统。
我不相信任何一种方法都是错误的或正确的。他们都可以取得成果。我甚至尝试找到自下而上的人一起工作，因为我们可以从两个不同的角度来解决这个问题。
答案 11 :(得分：0)
两者都是有效的方法。有时一个人“感觉”比另一个人更自然。然而，有一个大问题：一些主流语言，特别是他们的框架和库在IDE支持上真的严重，例如语法突出显示，后台类型检查，后台编译，智能代码完成，IntelliSense等等
然而，这不适用于自上而下的编码！在自上而下的编码中，您经常使用变量，字段，常量，函数，过程，方法，类，模块，特征，你还没有实现的mixins，方面，包和类型！因此，IDE会因为编译错误而不断对你大喊大叫，到处都会出现红色波浪线，你将无法完成代码等等。因此，IDE几乎禁止您进行自上而下的编码。
答案 12 :(得分：0)
我做了自上而下的变种。我倾向于首先尝试使用界面 - 然后我将其用作我的功能列表。这个版本有什么好处，它仍然适用于IDE，否则会抱怨。只需注释掉一个尚未实现的函数调用。