转载

编程范式

简介

架构整洁之道, 看这一篇就够了！

架构是软件系统的一部分，所以要明白架构的价值，首先要明确软件系统的价值。软件系统的价值有两方面，行为价值和架构价值。

行为价值是软件的核心价值，包括需求的实现，以及可用性保障（功能性 bug 、性能、稳定性）。这几乎占据了我们90%的工作内容，支撑业务先赢是我们工程师的首要责任。如果业务是明确的、稳定的，架构的价值就可以忽略不计，但业务通常是不明确的、飞速发展的，这时架构就无比重要，因为架构的价值就是让我们的软件（Software）更软（Soft）。
架构价值
1. 当需求变更时，所需的软件变更必须简单方便。
2. 变更实施的难度应该和变更的范畴（scope）成等比，而与变更的具体形状（shape）无关。

实现行为价值的需求通常是 PD 提出的，都比较紧急，但并不总是特别重要；架构价值的工作内容，通常是开发同学提出的，都很重要但基本不是很紧急，短期内不做也死不了。我们开发同学，在低头敲代码之前，一定要把杂糅在一起的“重要且紧急”和“不重要但紧急”分开，把我们架构工作（“重要但不紧急”）插进去。

其实所谓架构就是限制，限制源码放在哪里、限制依赖、限制通信的方式，但这些限制比较上层。编程范式是最基础的限制，它限制我们的控制流和数据流：结构化编程限制了控制权的直接转移（限制了goto语句），面向对象编程限制了控制权的间接转移（限制了函数指针的使用），函数式编程限制了赋值

编程范式		描述
结构化编程	限制控制权的直接转移	就是函数调用或者 goto 语句，代码在原来的流程里不继续执行了，转而去执行别的代码，并且你指明了执行什么代码。	限制goto语句
面向对象编程	限制控制权的间接转移	就是代码在原来的流程里不继续执行了，转而去执行别的代码，但具体执行了啥代码你也不知道，你只调了个函数指针或者接口。	限制函数指针
函数式编程	限制赋值	函数要保持独立，所有功能就是返回一个新的值，没有其他行为，尤其是不得修改外部变量的值