是PHP情懷讓我9年了沒有放棄推出DRYCMS

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