After a month of tossing, from reconstruction to redesign, the management system finally has access to the authority

Hello everyone, my name is Chocolate.

I haven’t updated the article for about a month. I have been a little lazy recently. On the other hand, during this period of time, the epidemic in Shenzhen has been repeated. I have been working from home for three weeks. It’s not very good. I also hope that the epidemic will pass soon. It’s better to work in the company on weekdays. The efficiency of working from home is not very high, and it is always easy to be distracted.

Although most of us communicate online at work, sometimes we still go to the workstation to communicate. After we are at home, online communication is also a problem. Take the permission management system we built this month as an example.

Analyze your needs

How should I put it, this management system has been in operation for more than a year, and the old projects are constantly iterated, but the introduction of permissions in the future was not considered when the product was designed, and some functions are relatively scattered. Generally, there is a need for it. Stack function on top. Therefore, the front-end workload for forcibly accessing permissions is huge this time, such as routing, historical data processing, button permissions, page tab permissions, drop-down data processing, introduction of a new version of role management, binding of personnel and roles, binding of functions and permissions, etc. In the past month, I have almost read the entire code logic, and then changed it.

Front-end UI framework

The problem of the framework is also mentioned here. This system is a bit older. The previous UI was developed using material-ui. As for the open source framework provided by Google, some interactions were found in the process of use. Comfortable, there are still some differences between the style and the domestic one. This is still subjective, so we replaced the new UI, which is and pro. We also wrote an article before, and the reading volume is still good.

Since the introduction of antd pro, I have started various refactoring work, and I have also sorted out the previous interaction logic while doing it. The amount of code will gradually increase there, and the responsibilities will increase accordingly. After all, online If there are some logical problems, they will still come to me.

button permission problem

In fact, antd pro has already provided a solution for permission implementation, and also provides related hook usage. Examples are as follows:

// src/access.ts
export default function (initialState) {
  return {
    canReadFoo: true,
    canUpdateFoo: () => true,
    canDeleteFoo: (data) => data?.status < 1, // 按业务需求自己任意定义鉴权函数
  };
}
复制代码

Example of permission control within the page:

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 (
    <div>
      <Access accessible={access.canReadFoo} fallback={<div>Can not read foo content.</div>}>
        Foo content.
      </Access>
      <Access accessible={access.canUpdateFoo()} fallback={<div>Can not update foo.</div>}>
        Update foo.
      </Access>
      <Access accessible={access.canDeleteFoo(foo)} fallback={<div>Can not delete foo.</div>}>
        Delete foo.
      </Access>
    </div>
  );
};
复制代码

At the same time, hooks are also provided. The usage examples are as follows:

const Button=()=>{
   const  access =  useXX();
   // 权限处理
   return <Button/>
}
复制代码

It still looks quite fragrant, just use it directly, but...

我们的系统之前并不完全是按照 antd pro 来做的，总之就是比较乱，于是借鉴了其中的思想，自己实现了一层 access 和 useAccess。

实际效果还是不错，其中也可以满足产品的各种需求，比如有些按钮得加上 Tooltip 文字提示，有些按钮需要隐藏，又或是置灰状态，当然，还有 tab 页的显示与隐藏等等，所以能看出来产品的需求是真的多...

自己实现的方法当然不是一下就可以了，也会在做的过程中发现需要一些判断条件，但麻烦的是我们是两套 UI 框架共存，所以得适配两套框架的逻辑，因此会多一层判断。

怎么说，感觉是技术选型上留下来的债，还是要还的。

设计评审环节

可能需要吐槽一点的就是这个吧，前端和后端都会有一些不足的部分，后端数据表结构也存在问题，毕竟在之前其实都没有考虑会接入权限这一说法，所以一些接口的命名规范就不统一，在之后的实际开发过程中，全甩给前端做处理了，实际工作量大大提升，而在本地联调过程中，数据库里数据几乎都是空的，所以权限池里面的数据都是我手动一个一个加的，这个花费了大量的时间。

当时我就和导师商量了一番，这个接口绑定权限的后端就能做吧，当时得到的回复就是后端数据表结构比较乱，还要输入对应权限名称啥的，处理就会比较麻烦，害...

于是，大概在家弄了一周时间，两个人才把最后的绑定关系理清楚，将对应的权限树绘制了出来。

大概开发了两周之后，关于权限与功能管理的菜单页面做好了之后，后端的任务也就做完了，实际上就多一些新增页面的增删改查，后续权限的处理前端的工作量很大，于是在后两周的时间，后端基本上没啥事干了。

测试通过环节

在我开始写这篇文章的那一天，我把测试发现的所有前端缺陷都修复了，测试同学也是看了好几天，期间发现一个问题我就立即去修复，最后测试通过了所有的用例，这一瞬间就感觉之前的一些不快都没了，总算是要把这个系统搞上线了，感觉这过去几周默默改 bug 日子好像也还好。

测试通过之后，会有产品验收的环节，这时候又发现了问题，因为现在权限的控制是与接口相关的，比如我的提交按钮其实是与某个 action 相关的，也就是后端 api 嘛，所以在某个菜单功能下面，放的是一行一行接口权限，而不是产品所期望的增删改查权限。

简单来说在产品角度来看，有些权限看起来没必要分开，查询的就一个行了，这时候就出现分歧了，就在之前说的设计评审环节阶段，后端接口不统一，全由前端来处理，总不能把不需要的权限全部放开吧？放开了之后我的按钮权限到底是与那个接口绑定呢？

沟通处理

这个时候产品找了前端和后端，就觉得这个设计不太合理，接口不等于权限，认为我们是站在开发的角度去设计，而不是一个产品角度。

我导师感觉都不太愿意去探讨了，后续我被拉过去看了下，当时心里所想就是感觉讨论了也没啥结果，既然要接入权限，仅仅只是改动前端，后端一些接口规范性不改动，确实很难达成一致。

就比如一个编辑框，可能会因为第一个下拉框的结果会请求不同的接口，请求路径也不一致，这个其实可以做成一个接口就好了，也方便权限控制。

这时，后端同事也发现了其中的问题，看起来也是要改造一些接口，但实际上应该不会改动很多，毕竟整个开发周期都快一个月了，之前一直没改，现在突然改，又会拖很长进度，况且，后端逻辑改了，前端也得跟着改，前端页面改了，测试的一些用例可能也要再测一遍，这样就gg了。

最后处理方式

好在分析之后其实问题不是很大，就部分接口还是得合并一下，不是说权限和接口是一对一的，权限是一个大的整体，可能会有多个接口。

这里处理方式就是如果请求路径前缀相同，可以采用通配符方式。其它不好处理的情况，这块就不是我来做的了，由我的导师和后端同学沟通，后面看了下，采用绑定父权限来处理，这里后端同学和前端其实都做了一点妥协，相互再加一点工作量。

不管怎样，前端肯定是要改的，后端这回也跟着改动了，没办法，不改不行了。

总结与回顾

在我写完这篇文章的时候，基本上把问题解决差不多了，上线就等产品安排了，在这里总结一下这段开发历程：

首先感悟就是一个好的系统或者说是产品都是需要精心打磨的，也不是说东西一下就能做的很好，就比如上线的功能当时可能测的没问题了，说不定哪天又会出点小 bug，这也很正常，有问题就去解决问题。

第二点就是代码质量问题，想必多少都会有人吐槽前人所写的代码，包括我自己有时候也会发现一些问题，点击之后发现提交历史是自己就哈哈大笑，实在是太菜了。

对比我刚来公司写的代码和现在写的代码还是有一定差别的，所以说代码质量是在不断提升，但过去堆叠的问题还是会有，其实想想还好，至少没遇到过定义一个函数为 f，然后一堆很简略的变量名，就那种只有当事人自己看得懂的代码，这个是我同学遇到过的。总的来说，首先不管前人写的代码如何，至少在当时是把需求给交付了，现在遇到了就去改一改，对自己也要提高要求，不给别人留坑。

第三点，关于产品的原型设计，我们知道互联网员工其实流动性还挺大的，尤其是在年后，今三银四期间，跳槽的还挺多的，所以做这个系统原型设计的前产品可能早就离职了，当时就是这样设计的，而后来的设计又不太一样，所以就会存在一些差距，这谁来解决呢？

当然是我们开发了，所以这次的开发历程中我们就经历了，犹记得刚开始接到这个大需求，开设计评审然后评估工作量和时间的时候，当时还觉得这怎么要改这么多，都还不如重新开始做了。

现在回头来看，其实也还好，把工作进行细分，一块一块的解决好，最后发现做的还可以，在这个过程中我虽然不是核心人员，核心当然还是我导师，还是比较感谢导师的设计，许多一些难点都能想到一个好的解决方式，我也在这个过程中参与学习到了许多，或许也是以后跳槽找工作一个能说的点了。

那么，就说这么多了，后续有想到啥就来补充吧。

非技术类文章，就当个人记录啦，不求赞啦，内容仅做参考。

我也在 B 站拍了一个视频版，与本账号同名，可以围观。

学如逆水行舟，不进则退