“自上而下”是已经被用于计算机领域来描述分析技术。我建议使用“自外而内”的术语。
“自外而内”是BDD中的一个术语,其中我们认识到系统通常有多个用户界面,用户可以是其他系统以及人。BDD方法类似于TDD方法,我会简要介绍一下,希望对您有所帮助。
在BDD中,我们从一个场景开始 - 通常是一个用户使用系统的简单示例。围绕这些场景的讨论可以帮助我们确定系统应该做什么。我们编写一个用户界面,如果需要,我们可以自动化地执行这些场景来测试该用户界面。
当我们编写用户界面时,尽可能保持简洁。用户界面将使用另一个类 - 控制器、视图模型等 - 我们可以为其定义一个API。
在这个阶段,API可能是一个空类或一个(程序)接口。现在我们可以编写用户界面如何使用控制器的示例,并展示控制器如何提供价值。
这些示例还展示了控制器的职责范围,以及它如何将其职责委派给其他类,比如存储库、服务等。我们可以使用模拟来表达这种委派。然后,我们编写该类以使示例(单元测试)工作。我们只编写足够的示例以使系统级场景通过。
我发现重构模拟示例很常见,因为模拟的接口一开始只是猜测的,然后随着类的编写而更加完整。这将帮助我们定义下一层接口或API,为其描述更多示例,直到不再需要模拟,并且第一个场景通过。
随着我们描述更多场景,我们在类中创建不同的行为,我们可以进行重构以消除不同场景和用户界面需要相似行为的重复。
通过以外部为基础的方式,我们可以尽可能地获取有关API应该是什么的信息,并尽快重新设计这些API。这符合
实际选择(除非你知道为什么,否则不要过早承诺)的原则。我们不创建我们不使用的任何东西,而API本身是为可用性而设计的,而不是为了编写的便利性。代码往往采用更自然的风格,使用领域语言而不是编程语言编写,使其更易读。由于代码的阅读量大约是编写量的10倍,因此这也有助于使其易于维护。
因此,我会使用外部为基础的方法,而不是自下而上的智能猜测。我的经验是,它会产生更简单、更强烈解耦、更易读和更易于维护的代码。