伪代码编程过程与测试驱动开发

Question

对于那些没有读过Code Complete 2的人来说，伪代码编程过程基本上是一种设计例程的方法，首先用简单的英文描述它，然后逐步修改它到更详细的伪代码，最后编写代码。这样做的主要好处是通过自上而下而不是自下而上构建系统来帮助您保持适当的抽象级别，从而在不同的层中构建一个干净的API。我发现TDD在这方面效果较差，因为它过于注重做最低限度的测试以通过并鼓励一点点前期设计。我还发现，必须为不稳定的代码（不断重构的代码）维护一套单元测试是非常困难的，因为通常情况下你需要对例程进行十几次单元测试，只需要一次或两次。当您进行重构时 - 例如更改方法签名 - 您所做的大部分工作是更新测试而不是更新prod代码。在组件的代码稳定了一点之后，我更喜欢添加单元测试。

我的问题是 - 那些尝试过两种方法的人，你更喜欢哪种方式？

Answer 1

我的团队混合了两种方法，这是一种很棒的开发方式（至少对我们而言）。我们需要单元测试，因为我们有一个庞大而复杂的软件系统。但伪代码编程过程是我遇到的软件设计的最佳方法。让它们一起工作：

• 我们从编写课程开始， 并填写完整的评论 方法存根，带输入和 输出。
• 我们使用配对编码和同行评审作为对话来改进和验证设计，仍然只使用方法存根。
• 此时我们现在都设计了我们的系统并且有一些可测试的代码。所以我们继续编写单元测试。
• 我们返回并开始填写方法，并为需要编写的逻辑添加注释。
• 我们写代码;测试通过。

它的美妙之处在于，当我们实际编写代码时，大多数实现工作已经完成，因为我们认为实现的大部分实际上是代码设计。早期的过程也取代了对UML的需求 - 类和方法存根也是描述性的，而且它实际上也会被使用。而且我们始终处于适当的抽象层次。

显然，这个过程从来没有像我所描述的那样线性 - 一些实施的怪癖可能意味着我们需要重新审视高级设计。但总的来说，当我们编写单元测试时，设计非常稳定（在方法级别），因此不需要进行大量的测试重写。

Answer 2

通过测试驱动开发，您应该在开始时进行一些规划。首先应该高度看看你想要做什么。不要拿出所有的细节，而是用简单的英语想一想如何解决这个问题。

然后开始测试问题。一旦你完成了测试，就开始让它通过。如果不容易，您可能需要修改初始计划。如果有问题只需修改。测试不是为了定义解决方案，而是允许您进行更改，以便在确保稳定性的同时获得更好的解决方案。

我想说最好的选择是使用TDD。关键是要意识到TDD并不意味着“跳过规划”。 TDD意味着做一些计划好好开始，并根据需要进行调整。你可能甚至不需要调整。

Answer 3

一般来说，我发现只有当解决问题所需的代码比测试解决方案所需的代码复杂得多时，伪代码才真正变得相关。如果不是这种情况，我不会遇到你所描述的困难，因为可能有效的最简单的事情通常是一个可接受的解决方案，可以花费大量时间来解决这个问题。

另一方面，如果问题 很复杂，我需要先考虑如何处理它，然后才能编写一个初始天真的解决方案 - 我仍然需要在编码之前进行规划;因此，我使用两种方法的组合：我最初将要编写的内容的英文描述，然后是测试工具，然后是天真的解决方案代码，然后是细化。

Answer 4

我已经同时使用Big Upfront Development，这三个都取决于语言，团队动态和程序规模/复杂性等问题。

在动态语言（特别是ruby）中，我强烈推荐TDD，它将帮助您捕获其他语言在编译时捕获的错误。

在一个庞大而复杂的系统中，您提前设计的设计越多，您的设计就越好。看起来当我为一个大型项目设计时，我手工挥动的每个区域都说“这应该是非常直接的”，这是项目后期的绊脚石。

如果你是在一个静态类型的语言中单独工作，列表方法是合理的，将为你节省大量的TDD时间（测试维护不是免费的，虽然首先编写测试是不是太糟糕了 - 当你正在进行的系统中没有任何测试时，添加测试并不总是令人敬佩，你甚至可能会引起一些不必要的注意。

Answer 5

仅仅因为测试通过，并不意味着你已经完成了。

TDD的最佳特征是Red - Green - Refactor。

进行测试可提供一个（两个）目标线。这只是第一个最小的要求。真正的目标是与“伪代码编程过程”或任何设计学科相同的目标。

此外，TDD通过测试驱动，但这并不意味着通过测试盲目驱动。您可以像迭代代码一样迭代测试。在这里没有教条坚持愚蠢计划的地方。这是一种敏捷技术 - 这意味着可以根据您的团队和您的情况进行调整。

设计足够的代码以获得可测试的界面。设计足够的测试以确保界面正常工作。设计一些更多测试和更多实现，直到您看到需要重构。

真正的目标是Good Software。 TDD不能排除“善”。

技术不是限制性任务。应该将技术看作是帮助您生成良好代码的拐杖。如果我更聪明，更富有，更好看，我就不需要TDD。但由于我和我一样愚蠢，我需要一个拐杖来帮助我重构。

Answer 6

对我来说，TDD有一个无法与之竞争的ace伪编码 - 它们都可以帮助你抽象和规划开发，但是一旦你在TDD土地中完成开发，你仍然有单元测试。

AS有用的方法，因为CC2描述了伪编码，它只是无法匹配。 TDD只是设计的一半，它还提供了一个严格的脚手架，您可以从中推进项目。但是我看不出为什么你不能用伪代码来解决TDD设置的问题。

  

我不能有机地发展   伪代码是心灵杀手   正是小小的死亡使项目记忆被遗忘   我将面对90年代的方法论   我会允许它通过我和我   当它过去时，我会转动内心的眼睛来看它的路径   在伪代码消失的地方会有TDD   只剩下单元测试。

（请不要因此而激怒我，我只有一半认真：P）