前言
从最开始的小公司做小网站，到现在进入现在的公司做项目，发现小公司里很多很多工作都是重复的劳动（增删改查），不过想想也是，业务软件最基础的东西不就是增删改查吗。
但是很多时候，这种业务逻辑其实没有必要挨个重写。总不能说你的增删改查比我的高级很多。很大程度上，复杂的问题只是数据太多了怎么优化。
简介
在真的开始做之前，先来简单介绍几个概念。简单介绍一下PaaS是什么，大概意思就是已经做好了一个大的平台，你可以在上边快速的配置、扩展你的服务。
详细的介绍推荐看一下阮一峰老师的博客 http://www.ruanyifeng.com/blog/2017/07/iaas-paas-saas.html
概念上
我想从零开始搭建一个能够配置定义业务，通过代码扩展业务的平台。在这个平台上，简单的需求，不写代码。复杂需求，只写与标准不同的代码。
有啥好处
提高生产力
其实，做软件的大部分时候，都是在写增删改查，实在是太简单了。搬砖谁不会对吧，要想搬得快，不需要你有多么好的脚力，更多的时候，你可能需要一个塔吊。
稳定的高负载
PaaS的设计之初，就是为了比较大的数据量来考虑的。项目小的时候，怎么着都行，但是，数据量一旦上来之后。小的项目可能根本没法用，如果是PaaS平台的话，你可能只需要多几台机器就完了，还是基础组搞的事情。
分工明确
提到了高负载，其实很大程度上都是底层的事情。普通的开发，更多的好处只是性能的提升。那么就需要两拨能力不同的人来共同完成这件事情。搞底层的更专注性能、扩展，搞业务的就更关注自己的核心业务就完了。
更少的服务代价
这个指的是客户花销，也是PaaS对于传统软件的优势。PaaS平台一旦做完，他肯定已经有平台了，如果要开发新的功能，可能并不需要占用更多的资源，只是在原有的资源上增加点业务而已。况且PaaS服务商与客户更多的是提供服务的续租模式，多一个客户少一个客户，其实对于服务器来说并没有啥压力，同一个团队能够服务与更多的人。
开发更快
就算是往小里做，如果你有这么一个PaaS的框架，你想要在上边直接搞一个业务的话。其实也就是搞点配置，然后作为一个单机软件部署，纯定制开发也会变得更快。
具体点 我们要做什么
假设我们现在要做一个人员管理系统，我们一般需要以下内容。
- 增加数据
可以配置一个或者多个新增数据的页面，点击保存就保存了数据
- 删除数据
可以配置个按钮，点击一下就把相关数据删除掉
- 修改数据
可以配置个按钮，点击一下出现一个编辑页面，里边会出现对应的数据，你可以修改，然后点击一下更新，数据就更新了
- 查
-- 列表页面
你可以在列表页面，配置几个筛选项，然后你修改完数据之后，点击搜索，就会根据你的数据来改变列表内容数据
-- 详情页面
你可以在列表页面点击名称（点击哪个可以配置）然后，就会自动跳转到详情页面
详情页面要展示哪些内容也可以通过配置来进行修改
NoCode能力
这个是整个业务的核心，也是PaaS之所以可以将几个月的工作量浓缩为数周的原因所在。
其实就是一个简单想法的转变，原本我们要实现我上边画的几张图，都是考改变代码来实现，比如说列表页面应该是战士什么Title、列表要不要出现选择框、列表究竟展示那几列、右上角究竟有什么按钮等等。
现在将这些原本需要写到代码里边的逻辑整理到配置里边，然后通过解释这些配置，渲染出页面，渲染出逻辑。
LowCode能力
当然了，上述的情况太过于简单了，基本上就是一个数据库的内容简单展示而已，如果我们需要更复杂一点的内容呢？
比如说我们需要输出这个人的年龄分层（幼儿、少年、青年、中年、老年），我们要怎么做呢？
很显然这个状态不应该被存放在数据库中的，因为这个实际上是通过年龄动态计算出来的，过一年之后这个展示状态可能就会过期了，这个时候我们就需要能够动态插入逻辑根据年龄计算这几个值，然后输出结果。
当然这并不是全部了，其他还有很多需要解决的事情。比如
- 使用配置来实现渲染，配置数据，读取起来是不是要比写代码慢很多？
- 搜索条件可能有很多，怎么实现这些条件可用呢？
- 如果默认的页面满足不了我的需求怎么办？
- 业务权限要怎么处理？总不能进入系统的人都有权限吧？
- 开发完了这个玩意怎么发布到线上去？
- ... ...
这个玩意有点庞大，一口气说不完。这次内容就这么多，我也只能一边整理一边写博客，这可能会是一个很长，也可能是做不下去很短的系列。
写的不好，能力有限多多见谅