16 tdd ppp pseudocode
对于那些没有阅读过代码完成2的人来说,伪代码编程过程基本上是一种设计例程的方法,首先用简单的英语描述它,然后逐步修改为更详细的伪代码,最后编写代码.这样做的主要好处是通过自上而下而不是自下而上构建系统来帮助您保持正确的抽象级别,从而在不同的层中构建一个干净的API.我发现TDD在这方面效果较差,因为它过于注重做最低限度的测试以通过并鼓励一点点前期设计.我还发现,必须为不稳定的代码(不断重构的代码)维护一套单元测试是非常困难的,因为通常情况下你需要对例程进行十几次单元测试,只需要一次或两次.当您进行重构时 - 例如更改方法签名 - 您所做的大部分工作是更新测试而不是更新prod代码.在组件的代码稳定了一点之后,我更喜欢添加单元测试.
我的问题是 - 那些尝试过两种方法的人,你更喜欢哪种方法？
我的团队混合了两种方法,这是一种很棒的开发方式(至少对我们而言).我们需要单元测试,因为我们有一个庞大而复杂的软件系统.但伪代码编程过程是我遇到的软件设计的最佳方法.让它们一起工作:
它的美妙之处在于,当我们实际编写代码时,大部分的实现工作已经完成,因为我们认为实现的大部分实际上是代码设计.早期的过程也取代了对UML的需求 - 类和方法存根也是描述性的,而且它实际上也会被使用.我们始终保持适当的抽象层次.
显然,这个过程从来没有像我所描述的那样线性 - 一些实现的怪癖可能意味着我们需要重新审视高级设计.但总的来说,当我们编写单元测试时,设计确实非常稳定(在方法级别),因此不需要大量的测试重写.
使用测试驱动开发，您仍然应该在一开始就做一些计划。首先应该从高层次审视您想要做什么。不要提出所有细节，而是用简单的英语了解如何解决问题。
然后开始测试问题。一旦你完成了测试，就开始让它通过。如果这不容易做到，您可能需要修改最初的计划。如果有问题就修改一下。测试并不是为了定义解决方案，而是为了让您能够进行更改，以便在确保稳定性的同时获得更好的解决方案。
我想说最好的选择是使用 TDD。关键是要认识到 TDD 并不意味着“跳过计划”。TDD 意味着做一些计划才能很好地开始，并根据需要进行调整。你甚至可能不需要调整。