技術(shù)選型和前期設(shè)計真的很重要

之前一段時間幫朋友看了個項目，他們其實是要開發(fā)一個類似內(nèi)容展示、編輯的功能，同時加上一些自定義功能，所以想全部自己搞一套接口和網(wǎng)站。

在他們項目里，不同內(nèi)容對于不同類型的用戶群體來說功能是不一樣的。比如說，對于某些內(nèi)容，適合于我方管理員來進(jìn)行修改和編輯，對于另外一些內(nèi)容適合一些編輯人員來編輯，還有一些內(nèi)容則只適合普通用戶來看。另外最初的時候他們還想著以后可能要出付費(fèi)會員制，會員又可以有不同級別，然后具有不同的權(quán)限。

這其實很明顯就關(guān)乎一些權(quán)限控制問題了，要實現(xiàn)的話就需要用到用戶和用戶組以及權(quán)限的關(guān)聯(lián)了。最理想的方案其實是用戶、用戶組、權(quán)限單獨(dú)都有一個表，然后用戶和用戶組，用戶組和權(quán)限都是多對多的關(guān)系，就是一個用戶可以屬于多個組，每個組就有不同的權(quán)限，這樣一個用戶的權(quán)限其實就是這多個用戶組對應(yīng)所有權(quán)限的并集，到時候請求接口的時候判斷該用戶是否擁有當(dāng)前接口所需要的權(quán)限就好了。這樣一來，用戶可以有多個身份，也就可以根據(jù)不同身份獲取不同權(quán)限了。現(xiàn)在大多數(shù)內(nèi)容管理系統(tǒng)幾乎都是這種思路實現(xiàn)的。

然而呢，他們現(xiàn)在怎么做的？他們完全沒有用戶組的概念，而且直接用戶表加了一個字段，叫是否為管理員，然后權(quán)限怎么存的呢？它把所有權(quán)限直接存成了一個列表，然后將其序列化，存到了另外一個字段里面。自己想象一下吧，這簡直是災(zāi)難級的設(shè)計，現(xiàn)在他們由于要區(qū)分多個不同內(nèi)容的權(quán)限，再加上又有新的模塊加進(jìn)來，權(quán)限越來越多，導(dǎo)致這個權(quán)限字段存的越來越多，單個字段越來越龐大，幾乎無法管理了。現(xiàn)在他們又要加會員訂閱制功能，覺得搞不下去了，所以現(xiàn)在也不得不重構(gòu)權(quán)限管理這一套邏輯，這一改又牽扯到線上很多業(yè)務(wù)邏輯，現(xiàn)在頭大得很。

我就問他當(dāng)時為啥不這么設(shè)計，他說一開始就不想搞那么復(fù)雜，從簡直接來了。結(jié)果到頭來，因為前期的簡化和不全面的考慮，導(dǎo)致后期開發(fā)和維護(hù)成本越來越高，以至于不得不半路停下來重新設(shè)計底層的權(quán)限系統(tǒng)。

因此，一些基礎(chǔ)的方案，前期的設(shè)計真的很重要，不要圖快不要只逞一時之快，凡事長遠(yuǎn)考慮下，磨刀不誤砍柴工，最終我們會發(fā)現(xiàn)，前期鋪下的路能為后期省下太多太多時間。

有感而發(fā)，隨手一記，完畢。

崔慶才丨靜覓

隱形字

同名公眾號「崔慶才丨靜覓」

在這里分享自己的一些經(jīng)驗、想法和見解。

長按識別二維碼關(guān)注