对于没有阅读“代码完成2”的人,伪代码编程过程基本上是一种通过以简单的英文描述来设计例程的方法,然后逐渐将其修改为更详细的伪代码,最后是编码.这样做的主要好处是通过自上而下而不是自下而上建立系统来帮助您保持正确的抽象水平,从而在不同的层面上开发一个干净的API.我发现TDD在这方面效果较差,因为它太重视做最低限度的测试以通过并鼓励很少的前期设计.我还发现,必须为不稳定代码(代码不断被重构)维护一套单元测试是相当困难的,因为通常情况下,您只需要一到两次的例程来进行十几个单元测试.当您做重构时 – 更改方法签名,例如,您所做的大部分工作是更新测试而不是prod代码.我更喜欢在组件的代码稳定后添加单元测试.
我的团队混合了两种方法,这是一个非常棒的开发方式(至少对我们来说).我们需要单元测试,因为我们有一个庞大而复杂的软件系统.但是,伪代码编程过程是我遇到的最好的软件设计方法.让他们一起工作：
原文链接：https://www.f2er.com/javaschema/281899.html>我们开始写我们的课,
并填写完整的评论
方法存根,输入和
输出.
>我们使用对编码和同行评审作为对话来完善和验证设计,但仍然使用方法存根.
>在这一点上,我们现在已经设计了我们的系统并且有一些可测试的代码.所以我们继续写下我们的单元测试.
>我们回去,开始填写方法,注释需要写入的逻辑.
>我们编写代码;测试通过.
它的优点是,当我们实际编写代码时,大部分的实现工作已经完成,因为我们认为实现的大部分实际上是代码设计.早期的过程代替了对UML的需求 – 类和方法存根只是一样描述,加上它将被实际使用.我们始终保持适当的抽象层次.
显然,这个过程从来没有像我所描述的那样非常直观 – 一些实现可能意味着我们需要重新考察高级设计.但是一般来说,当我们编写单元测试时,设计真的很稳定(在方法层面),所以不需要大量的测试重写.
