我是周春,DRYCMS的开发者,2010年7月我毕业于华东交通大学,本科学的是工业工程专业。
大学毕业后我去上海看完世博会就留在上海工作了,第一年做ASP,然后就转了PHP。
我接触的第一个PHP框架是openCart,当时为一汽大众做商城就选的这个框架,我从这个框架学会了MVC的架构模式,基于自己的兴趣爱好,就试着自己去实现一个MVC框架,经过一番努力,最后做出来了,但是只适合小项目使用。
后面我依次接触到了ThinkPHP、CodeIgniter、Laravel、Symfony、Yaf、swoole等PHP框架,而且都用相应框架做过完整的项目。
ThinkPHP、CodeIgniter都是中规中矩的MVC框架,Laravel、Symfony是高度封装的MVC框架。
我从Laravel框架开始才接触到PHP的包管理工具composer,Yaf、swoole都是基于C语言写的拓展库框架,而swoole彻底改变了我的编程思维,因为它是常驻内存的,所以像$_GET这样的全局变量就不能直接使用了。
我在2011年就想过做一个自己的CMS,想名字也花了一番功夫,有一种编程原则叫DRY(Don't Repeat Yourself),我觉得这个名字很好,自己想做的就是让别人不要重复的写一样的代码,于是注册了域名drycms.com。
2012年4月30这天,我计划在2012年国庆发布DRYCMS,结果2014年1月1日才发布,为什么时间记得这么清楚,因为可以在微博搜索DRYCMS这个词查看我当时发的微博。
2014年我才接触到像Bootstrap这样的前端界面框架,所以之前的那一版DRYCMS用的都是HTML原生的组件,但是它自动化的思想在当时还是蛮前卫的,我用它大概接了20个单子,开发挺快的,后面由于工作的原因停止了开发。
我接触swoole框架是在2016年,同时还接触到了go语言,从此打开了通往架构师的大门。
2017年我用swoole给哈工大航天研究的一个项目做了WebSocket长连接通信服务,他们有上万个设备需要实时连接到主控等待命令,这算是把swoole好好的熟悉了一番。
2018年在趣头条工作时用的是鸟哥的Yaf框架,后面就转go语言开发了。
2019年2月我离开上海到贵阳工作,这边都不加班,早上09:00上班,下午17:30下班,我有了足够多的业余时间,于是重新开始开发DRYCMS。
我直接推翻了之前的代码,完全重写,历时一年多,终于在2020年5月1日重新发布了DRYCMS 1.0.0,然后经过一个月的迭代在2020年6月14日发了DRYCMS 1.0.1版本。
一路走来,DRYCMS能到今天这个地步,确实不容易,下面是DRYCMS在重写时面临的一些选择问题:
1.没有前后端分离
因为DRYCMS是我一个人开发的,如果做到前后端分离,需要的时间会更多。
2.没有选基于vue或者react的前端框架,而是选择了layui
我个人比较喜欢layui的小清新风格,引入一个css和一个js就可以了,很方便,我自己比较偏重后端,前端的vue、react虽然会,但是还达不到熟练的程度。
3.为什么选swoole?
在2019年2月这个时间点,自己已经工作8年多了,如果要推出一个开源作品,肯定要拿出一个像样的,所以针对技术好一点的PHP开发者,我选了swoole。
4.为什么用PHP开发而不是用go语言来开发?
虽然自己用go语言很熟悉了,但是远没有php工作的年限长,所以积累的优质代码很少,考虑到php可以快速的开发出DRYCMS,等稳定了后面再推出go语言版本也是可以的,所以先用PHP实现。
5.为什么要做后台自动化?
后台的东西无外乎增删改查,平时会接一些项目,我不想天天写同样的代码,而且后台处理文件的相关操作会很麻烦,索性封装起来,就文件这一个功能,我做了1个多月。
后面说一下DRYCMS的计划吧:
DRYCMS目前只是推出了PHP版本而已,后面会推出go语言版本的,而且是前后端分离的,前端框架会使用element admin或者antd其中的一种。
DRYCMS不会停止更新,好的想法会先用PHP实现。
DRYCMS计划推出生成其他编程语言代码的功能,因为框架拥有元数据,可玩性非常高。
DRYCMS的go语言版本会是一个多租户的系统,可以直接上云,用户无需自己部署,直接用云就好了,会针对企业用户开发。
最后,如果你不喜欢PHP了,可以尝试下我用go语言搭建的单体框架吧,我后面还会开源基于go语言的微服务框架。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。