谈引擎与配置

一些背景

我的第一个真真正正的比较像样子的PHP项目是用Pi引擎做的，虽说是引擎，但是在整个项目的开发过程中，我是一直把他当作MVC框架来用。直到眼界宽了，见的技术、项目多了，才意识到，这不是框架，或者确切的说Pi不仅仅是框架，它是引擎。

在接触Pi之前，我使用过PHP的三个MVC框架：

• ThinkPHP
• CodeIgniter
• Yii2.0

ThinkPHP在大二升大三的暑假中做了简单的接触，但是并没有用过。

CodeIgniter是在大三的软件工程课上，做了一个小项目时用的，当时的感觉就是简单好用。

Yii2是我刚到公司，最先接触的一个项目就是用Yii2做的，感觉比CI要复杂一点，并且整个项目的感觉对于一个已经两年没有写过程序而找到SDE工作岗位的应届生来说，有些企业级应用开发的感觉。

直到接手一个用Pi开发的项目，当时的我才知道曾经的自己是多么Naive，以前使用的开发框架和Pi比，框架功能的复杂度及学习曲线简直不是一个数量级的。但是我需要做下去，就这样搞来搞去的搞了半年。最开始的时候，我经常抱怨，这个框架难学又难用。慢慢的，我发现我的认识不正确，如果我把他当作框架，那确实不太正确，是会影响生产力的，因为他是一个引擎，是一个把所有功能都做成可配置化和模块化的引擎。场景不一样，使用起来怎么能舒服呢？

最近的一些事

有一天晚上，Y总跟我说，RC系统现在是一整套规则引擎，但是并不是完完全全可配置的规则引擎。他想把RC系统做成完全的可配置。因为，用这个系统的人完全是内部的运营人员，运营人在后台登录，在后台页面做一些操作，就能够修改MySQL的一些存储配置，这些配置就是逻辑代码中的具体规则，这样做就相当于在后台页面修改了规则，让业务系统的下一步逻辑处理流程变得不同。

又有一天晚上，CL跟我说现在做的V系统很无聊，（这个V系统我以前也接手做了一部分，因为无聊，我跳坑了，但是后来想想，是有机会可以做的更好的），

我跟他说：V系统可以做的不无聊。

他说：那怎么做？

我说：我们可以做成引擎，配置引擎，这样就省略了大量的重复的代码。

CL此时两眼冒光：我现在就是这么想的，我现在正在推倒以前的代码重做。要将整个V系统做成完全的可配置。

我点了点头，会心一笑。

一点思考

Pi很强大。

当我有一天意识到这个东西是一个及其强大的工具的时候，我才知道曾今的抱怨Pi很鸡肋的自己是多么的无知。

是啊，场景。使用任何工具一定要注意场景。单单只说Pi的话，他十分的适合

为运营人使用，一次开发，部署到云上作为SaaS平台，而再也不需要操作代码，任何修改都只需到后台进行配置修改即可

这样的一个场景。

Pi引擎的配置代码十分的多。在统一的配置目录下有大约30个左右的配置文件，分别管理不同的资源。并且，在每一个Module模块下，都有专属于这个模块的配置，每个模块都可以当作一个Project。Pi的后台更是强大到过于复杂。所有的细节都是可配置的，角色管理也是十分的详尽明细的。

看上去可配置的东西真的很好，可以大大的提高生产力。对于RD来说，RD可以告诉运营人这个后台怎么操作，让他们直接修改存储到DB的数据，让整个系统的新规则直接生效，让整个系统可配置，RD则不需要登录到机器、更新代码。

但是，我又有两个保守的观点：

1. 要适度的构建和使用引擎，能不用引擎就尽量不用引擎，能不做可配置就不做可配置，让代码尽可能的如流水般简单。
2. 提防大一统思想：要把整个项目完全做成引擎化，所有的东西都做成可配置。

为什么我这么说？

因为引擎看上去是技术需求，是产自技术方，但是他是和业务需求紧紧耦合在一起的。没有业务需求，就不会有可配置的需求和功能出现，也就很少会在系统中有引擎要产生。业务需求的改动是频繁的，但是引擎的基本逻辑和框架是要稳定的。如果要频繁的改动引擎，这样是不是不太好。并且，一般要用到引擎功能的系统，都有可能会做的比较大，随着项目的变大，很有可能形成网状的调用关系和结构，那个时候再有新需求，牵一发则动全身。

另外一点，如果基于最小成本的角度去工作和思考，如果开发一套引擎出来，还不如写流水的代码快速和高效，那是不是直接写相对冗余和不那么方便的代码更好呢？

凡事无绝对。当然，如果现有系统的场景就是需要一个引擎，那么就用吧。我后面这些话的目的是要提防引擎化的思想，并不是引擎就是好的，并不是所有过程都很自动化，都是可配置就是好的。并不是追求高大上的技术方法和将事物复杂化、技术化就是好的。引擎和可配置只是技术的一种方法论，技术只是一种实现目标的手段，只要手头的工具在综合考量局部最优和全局最优后是能够提供最大的生产力就是好的。