1.项目类型

教育考试类型，功能点偏向于教师

2.项目功能

在线考试/组装试卷/查看成绩等

3. 问题与反思

3.1 分析与解决

• 1.试卷模板与试卷不同，当使用试卷模板生成考试试卷时，最好把试卷模板的信息放进去考试表
• 2.分组作业时，分给某些组可以存起来组的id,也可以存起来这些组里的user_id,查询的时候用like（%@.user_id.@%）进行查询
• 3.题库可以不存分数，因为每个试卷的题目数量是不一样的，所以在组卷时加入分数较好
• 4.获取器里面只写一层就可以，如果是某个表的多个字段需要使用1v1关联或者1vn关联
• 5.需要什么属性追加什么属性，只能处理一个字段，尽量不要在模型里面强制append，tp5里面append放在查询之后，单条查询需要先判断再追加
• 6.判断状态的字段要统一，设置的值也要统一。例如：1表示肯定的状态，2=表示否定状态
• 7.只要不是http访问的代码部分都要进行异常接管，不要只在第三方的地方做，例如workerman出问题也要接管
• 8.不管什么时候列表都要做分页，就算前端不用，默认limit写大一点。
• 9.pc部分与小程序部分两个前端的思路不同，导致后期改动较大，在遇到此类问题在前期就确定好思路，写入文档
• 10.接口文档保证成功返回实例有注释，apipost保存的东西必须检查！！！从分享出去的接口文档检查！！！一定要保证文档与接口是一致的
• 11.前端写完某些功能之后，后端要过来代码自己点击一下确保业务流程没有问题，然后检查页面数据字段等，防止前端随便用其他接口来补
• 12.相似的接口尽可能提取出公共部分，例如：判断题目对错的部分提取出来，而不是使用同一个接口。分成两个接口调用公共部分
• 13.全局！！！全局！！！一定要统揽全局！！！哪怕前期设计数据库多花费一点时间！！！也不要一边做项目一边设计数据库！！！这样很蠢！！！
• 14.文件都让前端生成！！！不是特殊情况后端不要生成文件，过于消耗服务器资源。
• 15.在做试卷与试卷库部分时，最好生成试卷时，将试卷库的数据同时保存一份，而不是单一只和试卷库id绑定

4.亮点

4.1 数据库

• 1.存储逗号分割的ids，在数据库存成@1@，@2@这种类型
• 2.当涉及到小组类型的问题时，把小组id与这个小组对应的user_ids存到两个字段，查询的时候可以使用user_id进行like查询，’%@’.user_id.’@%’
• 3.相近类型的数据（返回的数据结构相似的数据）都放在一张表，可以加字段进行区分，确定了返回数据都是相似的之后一定要放在一张表里

4.2 代码

1.全局查询（tp5）/搜索器（tp8-tp6）–新增数据字段时查询较为方便

protected function base($query)
{
    $query->where('status',1);
}

5.项目–可提升

• 1.项目实际评估周期过短–对项目不够了解–报出工期=工期天数的1/3+工期天数
• 2.客户提出的需求与仿制项目的功能发生冲突，完成部分功能只做演示，不让客户提出建议。完成所有功能之后让客户把所有的建议一并提出，防止改来改去。