在编码时，我们认为哪种方法更好？

• 将问题分解成足够小的部分，然后实施每个部分。
• 分解问题，然后使用自上而下的方法实施。
• 任何其他？

解决方案

是的。做所有这些事情。

似乎很讽刺(对不起，我回复为原形)，但这确实是没有正确答案的情况。

第二个选择是一个合理的选择。如果将问题分解为可以理解的部分，那么自顶向下的方法将在实施所有小细节之前揭示出任何主要的设计缺陷。我们可以编写用于较低级别功能的存根，以使所有内容保持一致。

我们可能需要查看《敏捷宣言》。自上而下和自下而上取决于"一次构建全部"的设计和构造。

"通过全面的文档编写工作软件"意味着我们构建的第一件事就是可以运行的最小有用的东西。最佳？底部？两者都不。

在我年轻的时候，我从事的项目是(按合同)严格按照自上而下进行的。这是行不通的。确实，这是行不通的。结果，我们将获得大量的冗余设计和代码。盲目应用时，这不是一个合理的方法。

我注意到的是，敏捷方法-起作用的小片段-倾向于将问题分解为可以立即掌握的部分。自上而下/自下而上不再那么重要。确实，这可能根本不重要。

哪个线索导致："我们如何分解进行敏捷开发？"诀窍是避免创建大的东西，然后必须分解。如果分析问题，我们会发现参与者试图完成用例而失败，因为他们没有所有信息，或者他们没有及时获得信息，或者他们无法执行决策，或者类似的事情。

通常，这些不是需要分解的大事情。当它们出现时，我们需要朝着"目标向后"方向解决问题。从目标到使我们能够实现目标的事物，再到使​​推动者实现目标的事物，等等。由于目标通常是大事，因此往往是自顶向下的-从一般业务目标到详细的业务流程和步骤。

在某些时候，我们概述了实现目标的各个步骤。我们已经完成了分析部分(分解内容)。现在是综合部分：我们将所拥有的东西重新组装成我们可以实际构建的东西。合成是自下而上的。但是，我们不要被迷住。我们有几种观点，每种观点都是不同的。

我们有一个模型。这通常是从细节构建为更大的概念模型。然后，有时会再次分解为针对OLTP标准化的模型。或者分解为针对OLAP标准化的星型模式。然后，我们进行备份以根据规范化的模型创建ORM映射。上下上。

我们有处理。这通常是从业务流程摘要到处理步骤的详细信息来构建的。然后围绕这些步骤设计软件。然后将软件分为类和方法。向下向下。

[题外话。对于开明的用户，此分解定义了新的职位和工作方式。对于开明的用户，旧的工作仍然存在，我们编写了大量的文档，将旧的工作映射到新的软件上。

我们有组件。我们经常查看各个部分，了解我们对可用组件的了解，然后进行某种匹配。这是最随机的过程；这类似于晶体的形成方式-存在成核中心，并且设计种类在这些中心周围固化。网页服务。数据库。交易管理。表现。体积。可以帮助我们选择实现部分或者全部解决方案的组件的不同功能。通常感觉自下而上(从功能到产品)，但有时自上而下("我拿着锤子，把所有东西都钉上钉子" ==对所有事物都使用RDBMS。

最终，我们必须进行编码。这是自下而上的。有点儿。我们必须定义一个包结构。我们必须整体定义类。那部分是自上而下的。我们必须在类中编写方法。我经常自下而上-粗略地编写方法，编写单元测试，完成方法。粗略了解下一个方法，编写一个单元测试，完成该方法。

驱动原理是敏捷-建立一些可行的方法。详细信息遍布整个地图-上，下，前，后，数据，过程，参与者，主题区域，业务价值。

这是我的工作：

首先了解域。了解要解决的问题。确保我们和客户(即使该客户就是我们！)在同一页上，指出要解决什么问题。

然后，提出了针对该问题的高级解决方案，从该解决方案，设计将变成页面上的气泡或者项目符号等，但要点是它会抖落成可以设计的组件。

那时，我为尚待编写的类编写测试，然后充实这些类以通过这些测试。

我使用测试优先的方法，并构建可以运行的，经过测试的组件。那对我有用。当组件接口已知并且"规则"因它们如何相互交谈和彼此提供服务而闻名时，那么通常就变成了一种直接的"将所有内容联系在一起"的练习。

这就是我的方法，对我来说效果很好。

我认为除了topverses自下而上的设计之外，还有更多需要考虑的问题。显然，我们需要将设计分解为可管理的工作单元，但同时也需要考虑优先级等。在迭代开发项目中，一旦为上一个解决方案交付了解决方案，我们通常会为下一个迭代重新定义问题。 。

从里到外的设计。

我们从尝试在高端实现的目标开始，然后知道在底层实现的目标。继续努力，直到两端在中间相遇。

在设计时，我喜欢做中间制作。我喜欢对域建模，然后设计类，然后从那里移到数据库和UI。如果有基于UI或者基于数据库的特定功能，我也可以预先设计这些功能。

在进行编码时，我通常喜欢尽可能自下而上(首先是数据库，然后是业务实体，然后是UI)。我发现用这种方法使事情变得简单起来要容易得多。

同样以敏捷的方式，首先编写测试！

那么所有软件都是一个连续的循环

• 红色-代码未通过测试
• 绿色-代码通过测试
• 重构-保留意图的代码改进。

缺陷，新功能，变化。它们都遵循相同的模式。

我有点同意所有的人都说"都不是"的意思，但是每个人都属于这个范围。

我更像是一个自上而下的家伙。我选择一个高级功能/要点/任何内容，并将其实现为一个完整的程序。这使我能够在问题域的范围内勾勒出基本的计划和结构。

然后，我从另一个功能入手，将第二个可以使用的原始内容重构为新的共享实体。泡沫，冲洗，重复直到涂装完成。

但是，我认识许多人，他们是自下而上的家伙，他们听到一个问题并开始考虑他们可能需要在其上构建应用程序的所有支持子系统。

我不相信任何一种方法都是错误的或者正确的。他们俩都能取得成果。我什至尝试找一个自下而上的人一起工作，因为我们可以从两个不同的角度来解决这个问题。

我倾向于设计自上而下并实现自下而上。

对于实现而言，构建最小的功能部件并将它们组装到更高级别的结构中似乎是最适合我的。但是，对于设计，我需要从整体上入手，然后将其分解以确定这些部分将是什么。

两者都是有效的方法。有时，一个人比另一个人更"自然"。但是，存在一个大问题：一些主流语言，尤其是其框架和库确实非常依赖IDE支持，例如语法突出显示，后台类型检查，后台编译，智能代码完成，IntelliSense等。

但是，这不适用于自上而下的编码！在自顶向下的编码中，我们将不断使用尚未实现的变量，字段，常量，函数，过程，方法，类，模块，特征，mixin，方面，包和类型！因此，由于编译错误，IDE会不断对我们大喊大叫，到处都是红色的波浪线，我们将无法完成代码，依此类推。因此，IDE几乎禁止我们进行自上而下的编码。

我做了一个自上而下的变体。我倾向于尝试先做界面，然后再将其用作功能列表。此版本的优点是，它仍可与IDE一起使用，否则可能会抱怨。只需将一个函数调用注释为尚未实现的函数即可。

我相信，有了优秀的软件设计师(我认为所有软件开发人员在某种程度上也应该是软件设计师)，其神奇之处在于能够同时进行自顶向下和自底向上的工作。

导师让我"受过教育"要做的事情是，首先是非常简短的自上而下地了解所涉及的实体，然后再自下而上地找出我要创建的基本元素，然后再备份并了解我知道我对自下而上的结果有什么了解，就可以往下走一层，依此类推，直到"他们在中间相遇"。

希望能有所帮助。