折腾一个月,从重构到再次设计,管理系统总算接入了权限
大家好，我是 Chocolate。
大概有一个多月没有更新文章了，最近是有一点点懒散，另外一方面这段时间深圳疫情反复，居家办公了三周，刚开始得知居家的时候还是觉得挺不错的，但之后状态感觉不是很好了，也希望疫情早点过去，在工作日还是在公司上班要好一点，在家上班效率也不是很高，总是容易分心。
平时大家工作虽然线上交流居多，但有时候还是会走到工位上沟通一下，这居家了之后，线上交流也是一个问题，就拿这一个月做的权限管理系统来说吧。
在讲之前，推荐一下 hearling 的公众号，里面会分享前端设计模式以及 leetcode 算法相关，同时也是一位 up 主，关注一起变强不变秃！
分析一下需求
怎么说呢，这个管理系统差不多做了一年多了，老项目不断地迭代，但之前产品设计的时候就没有考虑今后引入权限，做的一些功能也相对比较分散，一般有什么需求了就会往上面叠加功能。所以导致这次强行接入权限前端的工作量巨大，路由、历史数据处理、按钮权限、页面 tab 权限、下拉数据处理、引进新版角色管理，人员与角色绑定，功能与权限绑定等等，这一个月下来，几乎是把整体代码逻辑都看了遍，然后这改改那改改。
前端 UI 框架
在这里还要提及的就是框架问题了，这个系统算是老一点的，之前的 UI 统一都使用 material-ui 来开发的，就谷歌提供的开源框架，后续在使用过程中发现有些交互还是不太舒服，风格和国内还是有一些差别，这个还是看主观上吧，因此我们更换了新的 UI，那就是 and pro，之前还写过一篇文章，阅读量还是不错的。
从引入 antd pro 开始，我就开始了各种重构的工作，在做的时候也梳理了一遍之前的交互逻辑，代码量也在那会逐渐增多，责任也就相应多了起来，毕竟线上出一些逻辑问题，还是会来找我。
按钮权限问题
其实 antd pro 已经给了权限实现的方案，还提供了相关 hook 使用，例子如下：
// src/access.ts
export default function (initialState) {
return {
canReadFoo: true,
canUpdateFoo: () => true,
canDeleteFoo: (data) => data?.status < 1, // 按业务需求自己任意定义鉴权函数
};
}
页面内的权限控制示例：
import React from 'react';
import { useAccess, Access } from 'umi';
const PageA = (props) => {
const { foo } = props;
const access = useAccess(); // access 实例的成员: canReadFoo, canUpdateFoo, canDeleteFoo
if (access.canReadFoo) {
// 任意操作
}
return (
Can not read foo content. }>
Foo content.
Can not update foo. Update foo.
Delete foo.
);
};
同时，还提供了 hook，使用示例如下：
const Button=()=>{
const access = useXX();
// 权限处理
return
}
看起来还是挺香的，直接使用就好了，不过...
我们的系统之前并不完全是按照 antd pro 来做的，总之就是比较乱，于是借鉴了其中的思想，自己实现了一层 access 和 useAccess。
实际效果还是不错，其中也可以满足产品的各种需求，比如有些按钮得加上 Tooltip 文字提示，有些按钮需要隐藏，又或是置灰状态，当然，还有 tab 页的显示与隐藏等等，所以能看出来产品的需求是真的多...
自己实现的方法当然不是一下就可以了，也会在做的过程中发现需要一些判断条件，但麻烦的是我们是两套 UI 框架共存，所以得适配两套框架的逻辑，因此会多一层判断。
怎么说，感觉是技术选型上留下来的债，还是要还的。
设计评审环节
可能需要吐槽一点的就是这个吧，前端和后端都会有一些不足的部分，后端数据表结构也存在问题，毕竟在之前其实都没有考虑会接入权限这一说法，所以一些接口的命名规范就不统一，在之后的实际开发过程中，全甩给前端做处理了，实际工作量大大提升，而在本地联调过程中，数据库里数据几乎都是空的，所以权限池里面的数据都是我手动一个一个加的，这个花费了大量的时间。
当时我就和导师商量了一番，这个接口绑定权限的后端就能做吧，当时得到的回复就是后端数据表结构比较乱，还要输入对应权限名称啥的，处理就会比较麻烦，害...
于是，大概在家弄了一周时间，两个人才把最后的绑定关系理清楚，将对应的权限树绘制了出来。
大概开发了两周之后，关于权限与功能管理的菜单页面做好了之后，后端的任务也就做完了，实际上就多一些新增页面的增删改查，后续权限的处理前端的工作量很大，于是在后两周的时间，后端基本上没啥事干了。
测试通过环节
在我开始写这篇文章的那一天，我把测试发现的所有前端缺陷都修复了，测试同学也是看了好几天，期间发现一个问题我就立即去修复，最后测试通过了所有的用例，这一瞬间就感觉之前的一些不快都没了，总算是要把这个系统搞上线了，感觉这过去几周默默改 bug 日子好像也还好。
测试通过之后，会有产品验收的环节，这时候又发现了问题，因为现在权限的控制是与接口相关的，比如我的提交按钮其实是与某个 action 相关的，也就是后端 api 嘛，所以在某个菜单功能下面，放的是一行一行接口权限，而不是产品所期望的增删改查权限。
简单来说在产品角度来看，有些权限看起来没必要分开，查询的就一个行了，这时候就出现分歧了，就在之前说的设计评审环节阶段，后端接口不统一，全由前端来处理，总不能把不需要的权限全部放开吧？放开了之后我的按钮权限到底是与那个接口绑定呢？
沟通处理
这个时候产品找了前端和后端，就觉得这个设计不太合理，接口不等于权限，认为我们是站在开发的角度去设计，而不是一个产品角度。
我导师感觉都不太愿意去探讨了，后续我被拉过去看了下，当时心里所想就是感觉讨论了也没啥结果，既然要接入权限，仅仅只是改动前端，后端一些接口规范性不改动，确实很难达成一致。
就比如一个编辑框，可能会因为第一个下拉框的结果会请求不同的接口，请求路径也不一致，这个其实可以做成一个接口就好了，也方便权限控制。
这时，后端同事也发现了其中的问题，看起来也是要改造一些接口，但实际上应该不会改动很多，毕竟整个开发周期都快一个月了，之前一直没改，现在突然改，又会拖很长进度，况且，后端逻辑改了，前端也得跟着改，前端页面改了，测试的一些用例可能也要再测一遍，这样就gg了。
最后处理方式
好在分析之后其实问题不是很大，就部分接口还是得合并一下，不是说权限和接口是一对一的，权限是一个大的整体，可能会有多个接口。
这里处理方式就是如果请求路径前缀相同，可以采用通配符方式。其它不好处理的情况，这块就不是我来做的了，由我的导师和后端同学沟通，后面看了下，采用绑定父权限来处理，这里后端同学和前端其实都做了一点妥协，相互再加一点工作量。
不管怎样，前端肯定是要改的，后端这回也跟着改动了，没办法，不改不行了。
总结与回顾
在我写完这篇文章的时候，基本上把问题解决差不多了，上线就等产品安排了，在这里总结一下这段开发历程：
首先感悟就是一个好的系统或者说是产品都是需要精心打磨的，也不是说东西一下就能做的很好，就比如上线的功能当时可能测的没问题了，说不定哪天又会出点小 bug，这也很正常，有问题就去解决问题。
第二点就是代码质量问题，想必多少都会有人吐槽前人所写的代码，包括我自己有时候也会发现一些问题，点击之后发现提交历史是自己就哈哈大笑，实在是太菜了。
对比我刚来公司写的代码和现在写的代码还是有一定差别的，所以说代码质量是在不断提升，但过去堆叠的问题还是会有，其实想想还好，至少没遇到过定义一个函数为 f，然后一堆很简略的变量名，就那种只有当事人自己看得懂的代码，这个是我同学遇到过的。总的来说，首先不管前人写的代码如何，至少在当时是把需求给交付了，现在遇到了就去改一改，对自己也要提高要求，不给别人留坑。
第三点，关于产品的原型设计，我们知道互联网员工其实流动性还挺大的，尤其是在年后，今三银四期间，跳槽的还挺多的，所以做这个系统原型设计的前产品可能早就离职了，当时就是这样设计的，而后来的设计又不太一样，所以就会存在一些差距，这谁来解决呢？
当然是我们开发了，所以这次的开发历程中我们就经历了，犹记得刚开始接到这个大需求，开设计评审然后评估工作量和时间的时候，当时还觉得这怎么要改这么多，都还不如重新开始做了。
现在回头来看，其实也还好，把工作进行细分，一块一块的解决好，最后发现做的还可以，在这个过程中我虽然不是核心人员，核心当然还是我导师，还是比较感谢导师的设计，许多一些难点都能想到一个好的解决方式，我也在这个过程中参与学习到了许多，或许也是以后跳槽找工作一个能说的点了。
非技术类文章，就当个人记录啦，内容仅做参考。
我也在 B 站拍了一个视频版，点击【阅读原文】，即可围观。
学如逆水行舟，不进则退
你若喜欢，为小狮子点个【在看】哦~