我是周春，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语言的微服务框架。