对于那些没有阅读过代码完成2的人来说,伪代码编程过程基本上是一种设计例程的方法,首先用简单的英语描述它,然后逐步修改为更详细的伪代码,最后编写代码.这样做的主要好处是通过自上而下而不是自下而上构建系统来帮助您保持正确的抽象级别,从而在不同的层中构建一个干净的API.我发现TDD在这方面效果较差,因为它过于注重做最低限度的测试以通过并鼓励一点点前期设计.我还发现,必须为不稳定的代码(不断重构的代码)维护一套单元测试是非常困难的,因为通常情况下你需要对例程进行十几次单元测试,只需要一次或两次.当您进行重构时 - 例如更改方法签名 - 您所做的大部分工作是更新测试而不是更新prod代码.在组件的代码稳定了一点之后,我更喜欢添加单元测试.
我的问题是 - 那些尝试过两种方法的人,你更喜欢哪种方法？
我的团队混合了两种方法,这是一种很棒的开发方式(至少对我们而言).我们需要单元测试,因为我们有一个庞大而复杂的软件系统.但伪代码编程过程是我遇到的软件设计的最佳方法.让它们一起工作:
我们首先编写我们的类,并使用输入和输出填充完全注释的方法存根.
我们使用配对编码和同行评审作为对话来改进和验证设计,仍然只使用方法存根.
在这一点上,我们现在都设计了我们的系统,并有一些可测试的代码.所以我们继续编写单元测试.
我们回过头来开始填写方法,并对需要编写的逻辑进行注释.
我们写代码; 测试通过.
它的美妙之处在于,当我们实际编写代码时,大部分的实现工作已经完成,因为我们认为实现的大部分实际上是代码设计.早期的过程也取代了对UML的需求 - 类和方法存根也是描述性的,而且它实际上也会被使用.我们始终保持适当的抽象层次.
显然,这个过程从来没有像我所描述的那样线性 - 一些实现的怪癖可能意味着我们需要重新审视高级设计.但总的来说,当我们编写单元测试时,设计确实非常稳定(在方法级别),因此不需要大量的测试重写.
京公网安备 11010802040832号 | 京ICP备19059560号-6 