PHP开发演化史 01存单页应用 02函数"中央集权"开始有分工 03各种MVC框架 04Compos ...

2018-3-30 13:00 |来自: 互联网 271 0

摘要: 来源 /腾讯课堂Coding学院（ID：ke_coding）导语也写了几年PHP了, 一直都在追求高效的开发, 随着行业技术的发展, PHP也一直都在进化, 开发的方式也不断的在更新今天就从我的经历来简单跟大家分享一下, 新人可以看 ...

来源 /腾讯课堂Coding学院（ID：ke_coding）

导语
也写了几年PHP了, 一直都在追求高效的开发, 随着行业技术的发展, PHP也一直都在进化, 开发的方式也不断的在更新今天就从我的经历来简单跟大家分享一下, 新人可以看看一个老鸟的一些思考, 老鸟的希望抛砖引玉的交流。

01存单页应用

最早接触PHP的时候是在13年, 那个时候的PHP还是作为快速功能开发而存在的, 最主要的作用可能就是 1. 处理提交的表单 2. 根据参数从数据库拉取相应的数据展示那个时候的代码基本上都是随性而为, 而且基本上PHP代码都是作为补丁一样存在于一个HTML页面中的, 所以也是某种形式上的”单页应用”这个时候的PHP开发基本上可以说就是:

02函数"中央集权"开始有分工

但是随着公司业务步入正规, 在某一块业务上可能有了进一步发展的需求, 所需要的程序猿也从原来的一只变为了一群, 那么总不可能一群程序猿都按照自己”天马行空”的套路来开发吧? 那万一某个人离职了或者要维护另外一个人的代码还不欲哭无泪? 所以大家自发的(其实更多都是被业务、被青涩的新人、被坑逼的老人逼出来的)开始维护一个公共的代码层面上的规范, 某种意义上也算一个框架的雏形吧！

所以这个跟团队的风格以及水平都是有关系的, 这里就拿我当时接触到的一个套路简单的举例, 直接上代码的结构图:其中的核心就是global.php 这个文件的代码大概是如下结构(年代久远可能记不太清楚了 = =)很明显这个global.php就相当于一个公共的初始化的文件, 那么在我们需要开发一个页面hello.php的时候结构大概就如下:所以这样做的趋势很明显: 初始化的工作开始收敛, 我们的项目收敛在global.php里面开始出现一些分工的收敛, functions.php专门存放公共的函数, Mysql.class.php数据库操作有关等

好处也很明显:

出错的机会变少了(谁没几个写中文分号\空格语法错一点点死活看不出来的时候?!)

由规范反哺你需求处理的思路, (公共逻辑找functions, 数据库操作封装在Mysql.class)

03各种MVC框架

开发的形式会随着业务、行业的进化而进化聪明的程序员开始制定自己觉得好用的规则, 并通过当时比较火的MVC架构得到完善, 发布了各种各样的框架我差不多也写了1年的PHP, 接触了ThinkPHP\CodeIgniter\ZendFramework等框架各种框架对于我来说其实就是上面的思想的高级版, 同时把对于Http请求的处理加入到公共的逻辑里面, 而且出现了我认为比较重要, 放到现在也算是比较重要的东西各种风格的load机制在CI框架里面的话用过的肯定不陌生就是load方法实现的原理就在CI_Loader.php里面:回过头来看CI框架依然简单好用, 加载可控, 核心逻辑清晰简单, 但是2.x的版本:

核心类的命名风格太奇怪 CI_Model (蛇形加驼峰厉害了我的哥= =)

没有命名空间的概念全局会有污染\冲突

在后面公司的电商业务开发中由于团队水平、上手难易等原因我最终选择了CI框架

刚开始的时候很美好, 但是到了后期渐渐的出现了问题大家都知道电商业务:

操作的对象繁多(用户用户地址商品 SKU 商品分类属性供货商订单等)

每个对象的属性\状态又繁多(商品名字市场价售价详情图头图… 订单代付款待发货待收货已取消已确认申请退款申请退货退款中…)

所以用CI框架渐渐力不从心:

底层逻辑(页面展示数据数据库操作)跟业务逻辑(只显示某人的某种订单读取这个人的所有订单加上订单的收货地址)傻傻分不开

频繁的”雪崩”我就改了发货的model逻辑怎么前台用户都不能生成订单了?

最终我的老大采用模块化、微服务化的结构解耦了, 这样设计也不用考虑太多复杂的规则, 就算招实习生来维护也方便

但是除了接受老大的方案之外, 我也开始了解研究老一辈比较不喜欢的技术命名空间以及Composer(后面发现其实也是PHP现在发展的趋势)