在线问题反馈模块实战(一):梳理业务需求并创建数据库表

👨‍🎓作者：bug菌 ✏️博客：CSDN​、掘金等 💌公众号：​​猿圈奇妙屋​​ 🚫特别声明：原创不易，转载请附上原文出处链接和本文声明，谢谢配合。 🙏版权声明：文章里可能部分文字或者图片来源于互联网或者百度百科，如有侵权请联系bug菌处理。 

一、前言🔥

       接下来的这几期，bug菌想跟大家分享一下自己昨天刚接到一个临时的需求，热乎着呢，想分享一下自己是如何面对临时需求并制定整个开发周期，其中包括从梳理业务到创建业务表再到实现业务逻辑形成闭环再到与前端对接，其中会穿插一些业务拓展及功能性拓展，这一条龙流程在线与大家一起见证，分享给刚入门的小伙伴，希望对你们有所帮助。

环境说明：idea2019.3 + springboot2.3.1.REALSE + mybati-plus3.2.0 + mysql5.6 + jdk1.8

二、正文🔥

1️⃣背景

        由于疫情被困在家，临时接到了公司一个新项目，项目周期两个月吧，然后需求也是相对比较简短，实现一个员工在线晋升评定平台。

        然后我这边身为技术开发负责人，必当义不容辞接了啊，在家想怎么开发就怎么开发，相对还是比较自由，然后我就先是对整个业务系统做了全面梳理，之后开始制定后端系统架构，及业务表结构梳理并制定。

2️⃣调研业务需求

        眼瞅着两个月就快要到了，这时候，又临时来了个新需求，还是客户那边提出来的，说系统需要在线支持用户能反馈系统或使用建议等问题收集，也就是说需要收集用户需求反馈且给予反馈。

        想想这也说得过去，一般的业务系统都需要提供在线反馈功能，针对用户提出来的问题进行集中攻克或者对于热门的新需求给予满足。

        根据以往业务开发经验，这个模块功能相对比较单一，因为不牵涉主流业务，所以可以直接当成一个模块单一开发就行了，然后就是确定表字段及创建相关业务表即可。但是具体需求这个没有需求指定，所以这里就需要我来想办法定一下了，发挥我的多年业务开发的经验了，如果换做是你，你们有何想法？

3️⃣创建相关业务表

        仔细分析一下，也大致浏览了些传统网站的设计思路，总结下来就大致定了如下字段；

你们也可以看下，仅供参考，若是你们需求跟我不一致，也可以改动部分字段即可。

4️⃣创建表sql语句

如下是具体的创建业务表sql语句，仅供参考。

CREATE TABLE `user_questions` (
  `id` varchar(64) NOT NULL COMMENT 'uuid主键',
  `creator_name` varchar(255) DEFAULT NULL COMMENT '反馈人姓名',
  `creator_account_id` varchar(255) DEFAULT NULL COMMENT '反馈人域账号',
  `creator_dept_name` varchar(255) DEFAULT NULL COMMENT '反馈人部门名称',
  `question_type` varchar(64) DEFAULT NULL COMMENT '反馈问题类型(功能异常、体验问题、功能建议、其它)',
  `question_content` varchar(512) DEFAULT NULL COMMENT '反馈问题/建议详情',
  `in_page` varchar(255) DEFAULT NULL COMMENT '反馈问题/建议所在页面',
  `file_paths` varchar(255) DEFAULT NULL COMMENT '附件截图保存地址',
  `status` int(1) DEFAULT NULL COMMENT '状态(0:正常，1：删除；2：已解决；3：不予解决；4：解决中)',
  `solver` varchar(255) DEFAULT NULL COMMENT '解决人域账号',
  `create_time` datetime DEFAULT NULL COMMENT '创建时间',
  `create_by` varchar(255) DEFAULT NULL COMMENT '创建人',
  `update_time` datetime DEFAULT NULL COMMENT '修改时间',
  `update_by` varchar(255) DEFAULT NULL COMMENT '修改人',
  PRIMARY KEY (`id`)

如果对于有需要的小伙伴，也替你们省去了手写创表sql的体力活了，直接粘贴复制不比你手动写sql轻松么？对吧，看看我想得多周道。

5️⃣总结

        如果你对于该需求有何独特的见解，我希望你能在评论区留言告知我，我说不定就会采纳你的建议并实践到项目中去哦。

       然后，我对于如上业务表结构字段，对其中某些字段我在此给大家统一解释一下，省的我带偏部分不走脑的小伙伴啦，当然，不是针对屏幕前你的啦。

6️⃣答疑

        为何要保存域账号id(creator_account_id)字段？因为这是从OA系统的人员账户主键id，可通过这个字段关联拿到用户的所有基本信息，且该域账号id也是本系统的登录账户id。

        然后对于用户的部门字段、用户姓名字段，其实完全可根据域账号id关联人员基本信息表获取，但是由于人员基本信息表是定时同步(每天凌晨1点触发同步)，而同步逻辑却又是全量，就是先清表再全插，同步数据量过于庞大且没有保障，即使失败了也没有ack机制会再次触发同步，必须得等第二天运维人发现同步失败了手动执行，这多耽误事儿啊，既我就不想在同步过程中出现纰漏从而影响反馈问题模块展示用户信息，因此我干脆就冗余这些字段，在新增反馈问题的时候一并查出用户这些相关信息并进行存储。这样后续也就不会由于用户基本信息抽取故障等问题而造成数据用户信息无法展示的问题了。

        可能很多用户会关心若是用户基本信息发生了修改，那怎么办？会用户基本信息同步吗？其实这个我问了需求，变动很小千年不动，虽然发生几率很小，但也不代表不发生，所以与需求讨论了下，结论就是开放口子后续可手动编辑这部分内容，毕竟改动非常的小，人为处理也再简单不过了，你们觉得呢？

        好啦，以上就是这期的所有内容啦，你们学废了么？