所有系統(tǒng)的開發(fā)都受限于當(dāng)時(shí)的技術(shù)積累、人力資源、設(shè)計(jì)方案，沒有完美的系統(tǒng)， 我們只是在自己的技術(shù)能力內(nèi)做到100分。 -- fuyuan

沒有完美的系統(tǒng)，只有適合的系統(tǒng)。我不是大神，本文結(jié)合我以前在一個(gè)企業(yè)的CRM管理系統(tǒng)和后來開發(fā)維護(hù)的一個(gè)系統(tǒng)來說介紹下我踩過的坑。
??

業(yè)務(wù)背景

先說下業(yè)務(wù)背景吧，我當(dāng)時(shí)接手重構(gòu)改造任務(wù)的時(shí)候，面臨如下情況：

老系統(tǒng)部署環(huán)境比較陳舊，還是apache+php, 比較老的環(huán)境了，經(jīng)過若干年人員更替，部門分拆，已經(jīng)不能說清楚上面運(yùn)行的各種服務(wù)了，運(yùn)維部署起來也比較困難，哪天死了，基本上無法復(fù)制，單點(diǎn)情況比較嚴(yán)重。

所用框架也比較老舊，自有框架，不僅包含后臺(tái)服務(wù)代碼，還包含管理系統(tǒng)代碼，開發(fā)維護(hù)也比較困難。

界面風(fēng)格也比較舊，還是十幾年前的風(fēng)格，操作起來比較怪異。

領(lǐng)導(dǎo)授權(quán)說重構(gòu)吧。這個(gè)是最關(guān)鍵的，領(lǐng)導(dǎo)授權(quán)，是一個(gè)項(xiàng)目啟動(dòng)的旗幟。
?
系統(tǒng)從開發(fā)到后來的優(yōu)化都是遵循的原則PDCA。?
??
?

好，匯總各方面需求總結(jié)的情況如下：

新作一個(gè)管理后臺(tái)系統(tǒng)，最好與主業(yè)務(wù)一樣的結(jié)構(gòu)，這樣便于開發(fā)。即linux + nginx + php + yaf + memcache + yaconf + mysql等等。

遷移舊系統(tǒng)功能，按時(shí)完成，實(shí)現(xiàn)新的需要的功能。

找個(gè)流行的響應(yīng)式模版。

技術(shù)棧升級(jí)，這個(gè)是最近才加入的內(nèi)容。

系統(tǒng)整體架構(gòu)設(shè)計(jì)

開始的時(shí)候因?yàn)閷?duì)yaf不太熟，所以沒有注意到application.dispatcher.defaultRoute.controllerPrefer=true 這個(gè)配置。以至于 每次一個(gè)接口，都得重建一個(gè)文件，寫一個(gè)controller。
后來我想了一方法：對(duì)于a/b/c_d 這種路由，自己寫了個(gè)規(guī)則，映射到A_B_C controller的d action方法中。
這樣 對(duì)于簡(jiǎn)單的增刪改查方法，就可以放在一個(gè)文件里了。

model設(shè)計(jì)

訪問數(shù)據(jù)庫(kù)的model，因?yàn)閥af框架比較簡(jiǎn)單，所以我參照了thinkphp的訪問數(shù)據(jù)庫(kù)部分自己寫了一個(gè)簡(jiǎn)單的模塊。
后來一個(gè)兄弟引入了laravel的ORM模塊Eloquent，不過沒有遷移所有的業(yè)務(wù)，所以存在了兩套內(nèi)容。

賬號(hào)

這個(gè)比較簡(jiǎn)單，跟常用的系統(tǒng)相同。

角色

角色管理是確定角色具備哪些權(quán)限的一個(gè)過程，他是一個(gè)集合的概念，是眾多最小權(quán)限顆粒的組成。我們通過把權(quán)限給這個(gè)角色，再把角色給賬號(hào)，從而實(shí)現(xiàn)賬號(hào)的權(quán)限，這是網(wǎng)上摘抄的，我在系統(tǒng)中并沒有實(shí)現(xiàn)這么復(fù)雜。沒用用到 超級(jí)管理員，管理員，普通用戶角色區(qū)分，這個(gè)要看系統(tǒng)應(yīng)用場(chǎng)景吧。

權(quán)限的定義

網(wǎng)上有各種個(gè)樣的帖子介紹管理系統(tǒng)的，我也介紹下我的這個(gè)系統(tǒng)里面權(quán)限的部分。

權(quán)限可以分為三種：頁面權(quán)限，操作權(quán)限，數(shù)據(jù)權(quán)限??
頁面權(quán)限：即入口，用戶可以看到哪個(gè)頁面，看不到哪個(gè)頁面。
操作權(quán)限：進(jìn)入同樣的頁面，有些人看到這個(gè)按鈕可點(diǎn)擊，有些人只能瀏覽這個(gè)頁面的數(shù)據(jù)。
數(shù)據(jù)權(quán)限：則是控制你可以看到哪些數(shù)據(jù)，比如會(huì)員的人A只能看到或者修改A部創(chuàng)建的數(shù)據(jù)，他看不到或者不能修改B部的數(shù)據(jù)。

我這邊實(shí)現(xiàn)是限定一個(gè)一個(gè)常量列表和一個(gè)權(quán)限菜單。可以是增刪改查的，我這邊考慮到這個(gè)變化有限，所以只在代碼中寫成了固定的內(nèi)容，增加一項(xiàng)菜單就改回代碼就行了。

// 常量定義 define('P_USER_MANAGE', 1); // 后臺(tái)用戶管理 define('P_USER', 2); // 用戶管理列表 define('P_GROUP', 3); // 組管理列表 ... ...// 權(quán)限樹 P_USER_MANAGE => ['title' => '后臺(tái)管理','link' => '','class' => 'fa fa-user','child' => [P_USER => ['title' => '用戶列表','link' => '/user/list','class' => '','child' => array()],P_GROUP => ['title' => '組列表','link' => '/group/list','class' => '','child' => array()]] ]

這樣 每次用戶進(jìn)入頁面 再根據(jù)一定的算法獲得用戶 應(yīng)該有的權(quán)限，相關(guān)代碼可以參考：
https://github.com/netbird/permission

這個(gè)是以前實(shí)現(xiàn)的一個(gè)類，是將權(quán)限由低到高排列，保存的時(shí)候每4位轉(zhuǎn)變成1個(gè)十六進(jìn)制的字符，然后合并。
例如： 用戶權(quán)限是 '', 把權(quán)限 12加上，就是1000 0000 0000, 保存就是，800。
主要實(shí)現(xiàn)了以下方法：

Permission::setuserPermission($permission_index, $user_perm)// 這個(gè)是設(shè)置權(quán)限，比如用戶的現(xiàn)在權(quán)限是'', 如果把12這個(gè)權(quán)限號(hào)碼加上則執(zhí)行：// $user_permission = Permission::setuserPermission(12, $user_permission)Permission::deleteUserPermission($permission_index, $user_perm)// 刪除權(quán)限 Permission::isAllowUserPermission($permission_index, $user_perm)// 判斷用戶是否有權(quán)限

至于按鈕權(quán)限，這個(gè)也可以參照這個(gè)進(jìn)行，定義一個(gè)按鈕的設(shè)置常量，判斷有那個(gè)權(quán)限，則展示按鈕。
數(shù)據(jù)訪問，這個(gè)具體場(chǎng)景 具體分析了，不過每個(gè)接口入口的地方 至少需要判定訪問權(quán)限。
?

響應(yīng)式模版

技術(shù)講究厚積薄發(fā)，只有平時(shí)多積累多實(shí)踐，關(guān)鍵的時(shí)候才能發(fā)揮用途。因?yàn)橐郧白隽祟愃频南到y(tǒng)，所以利用了以下一個(gè)模版框架。然后進(jìn)行改造。
?
我不愿意每次都寫表格頁面，所以使用jquery table這個(gè)第三方的插件，采用異步加載數(shù)據(jù)的方式。在這個(gè)插件上面進(jìn)行了簡(jiǎn)單的二次開發(fā)。后來的大多數(shù)功能都是采用的這個(gè)插件。
?
bootstrap是個(gè)好東西，以前用的少，這次大規(guī)模使用，每天就是調(diào)頁面，調(diào)前端。在筆記本上看著不錯(cuò)，到了顯示器上就走樣，很苦惱。不過我經(jīng)手的頁面普遍沒啥問題。
?

功能改進(jìn)

之前每次新建功能都得新建個(gè)表，然后寫編輯頁面，好煩啊。能不能搞個(gè)公用的機(jī)制，簡(jiǎn)單的引用就生成個(gè)簡(jiǎn)單的編輯頁面。于是，我對(duì)編輯部分進(jìn)行了封裝改進(jìn)。
先說下數(shù)據(jù)庫(kù)：建造個(gè)公共表：主要包含 main_key, second_key, config_value,等內(nèi)容，config_value是參照key-value格式數(shù)據(jù)庫(kù)的value字段使用，當(dāng)然 text類型最高65535個(gè)字節(jié)把，如果太大，會(huì)造成bug。

?
就是將關(guān)系型數(shù)據(jù)庫(kù)作為key-value用了，一些加單的配置信息，經(jīng)過json轉(zhuǎn)成字符串然后保存下來。
?

自定義通用配置

有沒有一種方案，能夠不編寫代碼，僅靠后臺(tái)點(diǎn)點(diǎn)就能滿足配置？ 于是先出設(shè)計(jì)方案，后加工。
一般的項(xiàng)目配置分成單頁和列表的配置。可參照如下需求：

進(jìn)入設(shè)置頁面，創(chuàng)建1個(gè)item，類型分成單頁和列表。

選擇 編輯頁面是否包含日期，發(fā)布權(quán)限的人員，可修改字段的人員，發(fā)布的文件名稱等等吧。

單頁面或者列表的單頁面編輯頁支持自定義字段編輯(可添加或減少字段)。

于是這個(gè)項(xiàng)目就產(chǎn)生了。雖然體驗(yàn)差了一點(diǎn)，但是基本滿足需求，節(jié)約開發(fā)時(shí)間還是沒有問題的。

模版

關(guān)于模版是在列表頁面提出的，在自定義列表頁，每次創(chuàng)建單頁面的時(shí)候都需要重建數(shù)據(jù)很麻煩。于是改進(jìn)了下，在配置頁面有個(gè)模版設(shè)置頁面，模版頁面可以添加刪除定義字段。這樣在創(chuàng)建新頁面的時(shí)候就可以繼承模版了。
?

ini配置文件

關(guān)于生成的配置信息，我們還是采用了yaconf的php擴(kuò)展插件，所以大部分配置以ini文件的形式推到線上。yaconf的用戶可以參考線上說明。下面博客也總結(jié)了一些yaconf使用的坑。
一些使用Yaconf的經(jīng)驗(yàn)分享

日志及備份

一開始記錄mysql，每條都記錄，后來發(fā)現(xiàn)不太好，需要的時(shí)候什么也查不出來。還是應(yīng)該從產(chǎn)品的角度看這個(gè)日志吧。
這個(gè)模塊一直在開發(fā)改進(jìn)中。大致的方向是給使用者一個(gè)友好的查詢界面，去查詢相關(guān)的內(nèi)容。
因?yàn)橐恍╇[患，后來我加入了配置信息備份功能，每次配置更新的時(shí)候保存已有的線上這個(gè)文件配置，并且記錄到數(shù)據(jù)庫(kù)。然后做個(gè)后臺(tái)，可以查看，比對(duì)配置并且上線。
這個(gè)地方引用了一個(gè)公共類庫(kù)：https://github.com/chrisboulton/php-diff
?

vue

一次偶然的機(jī)會(huì)接觸到vue基礎(chǔ)知識(shí)，在系統(tǒng)的某些頁面決定嘗試以下，沒有深入使用，只是引入了 vue.js。進(jìn)行了一些頁面處理，感覺確實(shí)方便了很多。當(dāng)時(shí)只是看了vue的一些基礎(chǔ)知識(shí)，有很多問題還停留在表面層，所以沒有深入應(yīng)用。

類似下面的代碼，很舒服的感覺。

new Vue({el: '#app',data: {source_url:"",count_result_text: "",uid: ""},methods: {count_result: function () {var that = this;if (this.source_url == '') {bootbox.alert('url不能為空');return;}var param = {"source_url": this.source_url,"uid": this.uid};$.post('/api/counts', param, function(return_data){that.count_result_text = return_data.s;}, 'json');}}});

Vue.js 組件與路由

ant design

年初，想對(duì)系統(tǒng)升級(jí)改造。增加幾個(gè)模塊，朋友推薦ant design。感覺挺好，使用各種入坑。


下面是一些問題的總結(jié), 我在另外的兩篇文章中提到的：
ant design form表單的時(shí)間處理
碰到一個(gè)ant design跨域問題

全新的開發(fā)模式，我很喜歡。

?
技術(shù)棧：react，ant-design，dva，Mock
關(guān)于dva，有個(gè)圖，我想大家應(yīng)該學(xué)習(xí)下：

本次學(xué)會(huì)使用了npm，webpack, mock.js, node.js等相關(guān)內(nèi)容。
最后學(xué)以致用，技術(shù)永遠(yuǎn)為業(yè)務(wù)服務(wù)。這個(gè)是歷史以來的道理。多運(yùn)用，多思考。

轉(zhuǎn)載于:https://blog.51cto.com/9681602/2300861

總結(jié)

以上是生活随笔為你收集整理的一个管理系统的成长历程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。