技术选型和前期设计真的很重要

之前一段时间帮朋友看了个项目，他们其实是要开发一个类似内容展示、编辑的功能，同时加上一些自定义功能，所以想全部自己搞一套接口和网站。

在他们项目里，不同内容对于不同类型的用户群体来说功能是不一样的。比如说，对于某些内容，适合于我方管理员来进行修改和编辑，对于另外一些内容适合一些编辑人员来编辑，还有一些内容则只适合普通用户来看。另外最初的时候他们还想着以后可能要出付费会员制，会员又可以有不同级别，然后具有不同的权限。

这其实很明显就关乎一些权限控制问题了，要实现的话就需要用到用户和用户组以及权限的关联了。最理想的方案其实是用户、用户组、权限单独都有一个表，然后用户和用户组，用户组和权限都是多对多的关系，就是一个用户可以属于多个组，每个组就有不同的权限，这样一个用户的权限其实就是这多个用户组对应所有权限的并集，到时候请求接口的时候判断该用户是否拥有当前接口所需要的权限就好了。这样一来，用户可以有多个身份，也就可以根据不同身份获取不同权限了。现在大多数内容管理系统几乎都是这种思路实现的。

然而呢，他们现在怎么做的？他们完全没有用户组的概念，而且直接用户表加了一个字段，叫是否为管理员，然后权限怎么存的呢？它把所有权限直接存成了一个列表，然后将其序列化，存到了另外一个字段里面。自己想象一下吧，这简直是灾难级的设计，现在他们由于要区分多个不同内容的权限，再加上又有新的模块加进来，权限越来越多，导致这个权限字段存的越来越多，单个字段越来越庞大，几乎无法管理了。现在他们又要加会员订阅制功能，觉得搞不下去了，所以现在也不得不重构权限管理这一套逻辑，这一改又牵扯到线上很多业务逻辑，现在头大得很。

我就问他当时为啥不这么设计，他说一开始就不想搞那么复杂，从简直接来了。结果到头来，因为前期的简化和不全面的考虑，导致后期开发和维护成本越来越高，以至于不得不半路停下来重新设计底层的权限系统。

因此，一些基础的方案，前期的设计真的很重要，不要图快不要只逞一时之快，凡事长远考虑下，磨刀不误砍柴工，最终我们会发现，前期铺下的路能为后期省下太多太多时间。

有感而发，随手一记，完毕。

崔庆才丨静觅

隐形字

同名公众号「崔庆才丨静觅」

在这里分享自己的一些经验、想法和见解。

长按识别二维码关注