运营后台操作日志（web）思路+实现

标签：app   功能   聊天   列表   err   责任   多例   entry   type   

今天产品给我给我提了一个需求，要求我添加操作日志，记录登录人对运营后台的操作详细过程，本人菜鸟一枚，记录一下我的思路和过程，等我成为大佬的时候方便自我吐槽！。

产品要求：

　　要求：

　　　　１、要求记录操作人的名字，操作电脑的ip

　　　　2、记录操作内容

　　目的：

　　　　方便追溯责任，比如某管理员，审核了某个用户的申请，屏蔽了某个人的图片，冻结了某个用户等。当出问题的时候我们能拿出证据。

我的思路：

　　开始的时候我是完全按照产品需求做。步骤是这样的：

　　　　１、自定义注解，两个参数：操作描述（ｄｅｓｃｒｉｐｔｉｏｎ），操作类型：（ｔｙｐｅ）

　　　　２、用Ｊａｖａ的ａｏｐ对每个ｃｏｎｔｒｏｌｌｅｒ拦截

　　　　３、在每个ｃｏｎｔｒｏｌｌｅｒ添加注解

　　　　类似这样

@SaveOperateControllerLog(descrption = "聊天室管理 => 公会列表==>新增或者编辑工会营业执照", actionType = 1)
@RequestMapping("/updateClubBiz")
public Result updateClubBiz(@RequestBody PlatformEntryClub club) {
    try {
        return Result.ok(clubService.updateClubBiz(club));
    } catch (Exception e) {
        log.error("错误信息：{}",e);
        return Result.error(ResultCode.ERROR.getCode(),ResultCode.ERROR.getMessage());
    }
}

天真的我以为这样就可以了，但是产品说这个不行，让我好好思考下我们做操作日志的目的，想想日志该怎么记录。这里我反思了自己，我在一个小公司，我不知道大厂提需求是怎么样的，我们公司会产品口头表述，然后出一份简单的原型。而我就死板的照着原型做，其实这是不对的，我认为不管在大厂还是小公司，产品需求多么的详细，原型多么的完美，作为具体操作的者的我们都应该反复的思考一下，这样是否可行，这样做的目的是什么（或者说功能是啥）、是否有可以改进的地方等等，最后才考虑我该怎么去实现这个功能。不然等你代码写好了，自己在洋洋得意的时候，突然发现自己写的代码不对，或者说不能完全满足需求。就算你和需求一样，产品一句话你还不是要改。同事有句话说得好：是你的需求始终是你的，如果能一次写好是最好的，改来改去谁都烦，主要是再烦你还不是要改。偏了，下面继续。

在百度上看了很多例子后的思路：

　　在之前的基础上添加：添加请求参数、访问方法名、方法参数、返回结果、执行时间等，我以为这次完美了，但是并没有，参数是全面了，但是可读性不强，程序员能看懂，但是产品看着就很吃力了。所以下面就写我第三次更改后的代码，其实我写这篇博客的时候（2019年11月30日01:44:11）第三版本代码还没有写，准备今天晚上写个ｄｅｍｏ测试下，明天添加到我的分支上。有时间在同步博客。菜鸟程序员不配拥有周末！！！！！！！！

运营后台操作日志（web）思路+实现

标签：app   功能   聊天   列表   err   责任   多例   entry   type   

原文地址：https://www.cnblogs.com/libh9999/p/11961173.html