评价系统开发目前遇到的问题

工作

评价系统当前逻辑结构图

后端存在问题

1.导入逻辑
目前评价可以分别从管理端，小程序，Excel批量导入三个功能点导入答卷数据，每一个端的导入逻辑都有不同分别做了不同的兼容。

• 管理端加入了草稿逻辑，用户自己填评语，用户不填没有，可以覆盖小程序

• 小程序端用户没有填写的需要程序自动将默认评语导入答卷

• Excel用户维度全部选填，用户没填写的采用默认评语，要求可以覆盖小程序与管理端的填写内容。

• 营火虫与广州的采用同种方法处理，造成在导入时，针对在广州营火虫问卷需要强行将维度评语写入答卷。

2.导出逻辑

目前导出主要为导出Excel，导出主要内容为答卷数据。但是营火虫与广州的维度并不存在答卷数据。

• 兼容广州的维度不展示
• 兼容营火虫的导出维度评语与建议，用户没写使用默认的

3.预览报告逻辑

要求预览报告与真实报告一致，且复用报告逻辑，造成在原有稳定逻辑上，进行兼容。获取题目等。

4.管理端设置字段兼容

管理端的设置字段意义不明，且设置时报告处又要区分广州营火虫与普通问卷，加入兼容逻辑。

5.小程序端

• 小程序复杂量表，广州的要求一直不能展示维度，营火虫的要求要展示维度且用户要自己填。复杂量表的维度全局只有一份，目前实现方式，只要模版维度发生改变，会影响到整个用复杂量表模版生成的问卷。
• 小程序要求实时保存，不合理的交互造成速度过慢，最后一步提交时，后端需要将用户没填写的内容全部写入默认评语，造成最后一步提交除进行必须校验外还要进行分数计算等操作。
• 名字要求实时与教务保持一致，造成多次请求教务接口，速度慢。

6.报告端

• 营火虫的要求展示自己填写的评语
• 广州的什么时候都使用默认评语（生成报告逻辑还好）
• 获取报告接口数据混乱
• 前端此处也针对广州营火虫的进行了特殊处理判断

7.答卷编辑页
+ 前端对于复杂量表，营火虫的可编辑维度评语做了兼容处理

前端存在问题

1、管理端目前需要兼容业务的情况不多，主要是后端
a) 在题目设置页面，各种题型单位的大小限制
b) 在问卷设置页面，预览报告的时候会先调用一次提交的接口
c) 在问卷设置页面，仅展示总评会隐藏维度的可再次编辑选项

d) 在编辑答卷页面需要对萤火虫页面做特殊处理，使其可以更改维度评语

ps：需要注意的是修改一个地方可能涉及多个页面的修改，容易遗漏的是预览题目弹窗、手动和批量添加答卷页和编辑答卷页。

2、报告H5，针对性较强，目前有两份模板，一份已废弃
a) 广州量表：
广州量表需要把第一个维度的二级维度隐藏，这是定制需求
广州的无效问卷只保留第一个维度
不展示总评的得分
文案修改：把所有建议改成描述，雷达图的平均分改成标准分（最大分值5.3，标签整行显示）
二级维度不展示雷达图和条形图
b) 虎门小学：
首段空格
文案修改：总评的评语改成教师寄语
条形图：右上角显示成几枚
得分显示成徽章图标??
c) 广州AS
条形图：右上角显示成单词描述
/听力|口语|阅读/维度的得分显示成L1的形式
/Comment|Language/的维度不展示得分
/Language/维度才展示展开详情这个按钮
d) 应支持主题颜色可配置
ps：目前都是写死ID和文本来确定

3、小程序
a) 填写说明的展示与否是缓存在前端的
b) 广州量表不用处理维度，填完题目直接提交

前端存在问题

1、管理端目前需要兼容业务的情况不多，主要是后端
a) 在题目设置页面，各种题型单位的大小限制
b) 在问卷设置页面，预览报告的时候会先调用一次提交的接口
c) 在问卷设置页面，仅展示总评会隐藏维度的可再次编辑选项

d) 在编辑答卷页面需要对萤火虫页面做特殊处理，使其可以更改维度评语

ps：需要注意的是修改一个地方可能涉及多个页面的修改，容易遗漏的是预览题目弹窗、手动和批量添加答卷页和编辑答卷页。

2、报告H5，针对性较强，目前有两份模板，一份已废弃
a) 广州量表：
广州量表需要把第一个维度的二级维度隐藏，这是定制需求
广州的无效问卷只保留第一个维度
不展示总评的得分
文案修改：把所有建议改成描述，雷达图的平均分改成标准分（最大分值5.3，标签整行显示）
二级维度不展示雷达图和条形图
b) 虎门小学：
首段空格
文案修改：总评的评语改成教师寄语
条形图：右上角显示成几枚
得分显示成徽章图标??
c) 广州AS
条形图：右上角显示成单词描述
/听力|口语|阅读/维度的得分显示成L1的形式
/Comment|Language/的维度不展示得分
/Language/维度才展示展开详情这个按钮
d) 应支持主题颜色可配置
ps：目前都是写死ID和文本来确定

3、小程序
a) 填写说明的展示与否是缓存在前端的
b) 广州量表不用处理维度，填完题目直接提交

一点看法

个人认为，对于一个系统规划，在迭代过程中修改是在所难免的，可以理解。但是每一次修改都要推倒之前的规划，以及功能实现上从来不考虑对系统整体影响。评价是一个三端联动交互相对频繁的系统，任何一点小改动都会影响到三个地方，所以一开始规划就应该有一个清晰明白稳定的体系。接入一个线下团队，为了满足需求就修改之前的系统，又反过来影响规划。一千个人心中就有一千个哈姆雷特，同理一千个人看待同一个东西也会有不同的理解，那么不同的团队由于业务场景不同，其看问题的角度当然只会局限与自己的角度，我认为我们要做的是提取出共通的需求，以及按照我们的愿景引导让他们去规划系统，而不是一味的做妥协，这样不断修改还不如针对每个线下团队开发出一套系统，定制化，说怎么改就怎么改，现在这样造成线下团队吐槽我们系统不好用，我们自己也觉得系统越做越恶心，还不如外包团队，至少能让客户满意。长期这样搞，项目组成员也会越来越没自信，大家就这样一直改着，bug数量也陷入一个不可控的境地，因为系统太魔改了，后期就不知道做这个兼容又会对之前的逻辑造成什么问题。我一直相信，什么都想做就什么都做不好，每一种软件在诞生之日起就应该是在适用某个场景，而不是不断的兼容场景。
以上