Coding style 设计及；编码-从上到下还是从下到上？

在编码时，根据您的经验，什么是更好的方法

将问题分解为足够小的部分，然后实施每个部分

分解问题，然后使用自上而下的方法实现

还有别的吗

---

对。做所有这些事情

---

这可能看起来很讽刺（对不起，我回到形式上），但这确实是一个没有正确答案的情况。

你的第二个选择是一个合理的选择。如果您将问题分解为可理解的部分，自上而下的方法将在您实现所有小细节之前揭示任何主要的设计缺陷。您可以为较低级别的功能编写存根，使所有内容保持在一起。

您可能需要查看。自上而下和自下而上是基于一次建成的设计和施工

“在综合文档之上运行软件”意味着您构建的第一件事情是您可以运行的最小有用的东西。顶部底部？都不是

---

当我年轻的时候，我从事的项目——根据合同——严格来说是自上而下的。这不管用。事实上，这是行不通的。因此，您会得到堆积如山的冗余设计和代码。如果不加考虑的话，这不是一个合理的方法

我注意到的是敏捷方法——工作的小部分——倾向于将问题分解成可以一次抓住的部分。自上而下/自下而上不再那么重要。事实上，这可能根本不重要

哪些线索是：“如何为敏捷开发进行分解？”诀窍是避免创建一个必须分解的大东西。如果你分析一个问题，你会发现参与者试图完成用例却失败了，因为他们没有所有的信息，或者他们没有及时得到信息，或者他们不能执行他们的决策，或者诸如此类的事情

通常，这些都不是需要分解的大东西。如果是，您需要在目标后向方向解决问题。从目标到使您能够实现该目标的事情，再到使能器的事情，等等。由于目标通常是大的事情，这往往是自上而下的——从一般业务目标到详细的业务流程和步骤

在某种程度上，我们将概述这些实现目标的不同步骤。我们已经完成了分析部分（分解）。现在是合成部分：我们将我们拥有的重新组合成我们可以实际构建的东西。合成是自下而上的。然而，让我们不要忘乎所以。我们有几个观点，每个观点都不同

我们有一个模型。这通常是从细节构建到更大的概念模型中。然后，有时会再次分解为针对OLTP规范化的模型。或者分解成一个为OLAP规范化的星型模式。然后，我们从规范化模型中创建ORM映射。上-下-上

我们正在处理。这通常是从业务流程的摘要构建到处理步骤的细节。然后围绕这些步骤进行软件设计。然后将软件分为类和方法。向下-向上-向下

[题外话。对于开明的用户，这种分解定义了新的工作标题和工作方式。对于未开明的用户，旧工作会保留下来，我们会编写大量文档，将旧工作映射到新软件上。]

我们有组件。我们经常查看这些部件，查看我们对可用组件的了解，并进行某种匹配。这是最随机的过程；这类似于晶体形成的方式——有成核中心，而设计是围绕着这些中心固化的。网络服务。数据库事务管理。演出音量。以某种方式帮助我们选择实现部分或全部解决方案的组件的不同功能。通常感觉是自下而上的（从功能到产品），但有时是自上而下的（“我拿着锤子，把一切都称为钉子”==对一切都使用RDBMS。）

最终我们必须编码。这是自下而上的。有点您必须定义一个包结构。您必须将类定义为一个整体。那部分是自上而下的。您必须在类中编写方法。我经常做这种自下而上的工作——粗略地描述方法，编写单元测试，完成方法。大致列出下一个方法，编写单元测试，完成该方法

驱动原则是敏捷——构建一些有效的东西。详细信息遍布整个地图——上、下、前、后、数据、流程、参与者、主题领域、业务价值。

以下是我的工作：

首先了解领域。理解要解决的问题。确保您和客户（即使该客户是您！）在解决什么问题上处于同一页

然后，针对这个问题提出了一个高层次的解决方案，从中，设计将变成页面上的气泡或子弹，但关键是它将摇出，变成可以设计的组件

在这一点上，我为尚未编写的类编写测试，然后充实这些类以通过这些测试

我使用测试优先的方法，构建工作的、经过测试的组件。这对我来说很有用。当组件接口已知，并且“规则”知道它们如何相互通信并向彼此提供服务时，通常就变成了一个简单的“将所有东西连接在一起”练习

---

我就是这样做的，它对我起了很好的作用。

< P>我认为还有比顶部向下设计更需要考虑的事情。显然，你需要把设计分解成可管理的工作单元，但是你也需要考虑优先级等。在一个迭代开发项目中，一旦你为上一个解决方案提供了解决方案，你就经常重新定义问题。 你从你想做的开始