均为个人读书笔记，精读并整理出来各个章节的知识点。
该范式，主要提到一个人，Dijkstra，该范式主要由他提出，为行文方便，下文简称大壮。
回顾一下该范式：goto有害于整体结构，应采用其他控制语句来代替goto。
可推导性
大壮很早得出结论：编程难度大，细节多到超过程序员人脑处理的范围，所以需要工具，否则会出错。
他的想法是：如果能将程序进行拆分成小部件，只要验证每个小部件是否有bug，保证小部件都没有bug后，再将小部件串联成一整套程序，那么就可以确定整个程序没有bug了。
这在我们现在看来，是很正常的事。但是在当时，代码充斥着goto语句，到处乱跳，导致无法拆分。
于是他就向大家证明了这三种控制结构，顺序结构，分支结构，循环结构，也能够完成任何程序。这样就可以做到去goto化了。
goto 是有害的
大壮给CACM写信，标题为《错误地使用 goto 语句是有害的》，并描述了三种控制结构。当时引起了长达10年的热议，那时还没有互联网，于是有很多人给CACM写信抨击，当然也有很多坚定的支持者。
当然这场辩论最终还是结束了，因为人们发现大壮是对的。
功能性降解拆分
既然小部件可以拆分成可验证的单元，那就意味着小部件（模块），也可以按照功能进行拆分。这样一来，我们将可以将一个大工程，拆分成一个一个的小功能，最终拆分为一个一个的最小的函数，进而组合在一起。
以此为理论基础，才出现了结构化分析和结构化设计的工作。
形式化证明没有发生
但是，并没有人去做形式化证明，即，没有人去一个个验证那个被拆分的最小单元代码，是否能正常运行。
科学来救场
我们只能去证伪，即证实这段代码是否会发生错误。如我们可以传递一个越界的参数给一个函数，它会报错，则说明这个函数有问题，没通过验证。但我们永远也无法证实这个这个函数会是正确的。
测试
大壮说过：测试只能展示bug的存在，并不能证明不存在bug。
如果采用了不加限制的goto，那么无论我们写多少测试，也不能证明其正确性。
小结
这个范式最有价值的地方，就是它赋予了我们创造可证伪程序单元的能力。更重要的是，在架构设计领域，功能性降解拆分任然是最佳实践之一。
