weixin069计算机实验室排课与查询系统开发手记在高校里待过的人都知道计算机实验室的排课一直是个挺让人头疼的活。每个学期初实验中心主任要拿着几十份纸质申请表对着Excel表格来回比对生怕某间实验室在同一时间被两个老师同时约走。而学生那边也好不到哪去要么贴在走廊里的纸质课表被风吹掉了要么登录教务系统查了半天还是找不到实验课的具体地点。我自己就接过不少次这种“帮忙看看这学期实验室怎么安排的”的求助后来干脆花时间做了一套基于微信生态的计算机实验室排课与查询系统把排课、查询、管理这三件事收到一个平台里。这套系统我用了一个学期的数据做验证排课效率提升非常明显也帮我踩出了一堆教科书上不会写的坑。这篇文章就把整个设计思路、表结构、关键算法和实际开发中遇到的问题完整记录下来希望能给正在做课设、或者真有实验室管理需求的同学一点参考。1. 项目定位与需求拆解实验室排课到底难在哪1.1 排课场景的三个核心角色做系统之前最重要的不是写代码而是把使用场景里的角色和关系摸清楚。计算机实验室排课系统看上去就是个“课程表管理”但一旦深入进去你会发现自己面对的是三个角色、三种完全不同的需求。第一类是实验中心主任或者教务管理人员他们的核心诉求是“不能冲突”。同一间实验室同一时间只能有一个班在上课同一个老师同一时间也不能分身去两间实验室这是一个硬性的约束条件。除此之外他们还关心实验室的使用率、哪个时间段空置率最高、哪些设备比较老旧需要避开排课这些属于管理层面的需求。第二类是专任教师他们需要的是“能快速申请、能看结果”。老师申请实验室的时候最希望看到的就是哪些时间段是空闲的能不能直接选一个空档提交而不是自己先在Excel里查一遍再填表最后被管理员通知“这个时间被占了你再换一个”。从实际体验来看能可视化地看到空闲时间并一键提交是教师用户愿意持续使用这个系统的核心动力。第三类是学生他们的需求就两个字——查询。学生想知道自己这门实验课在哪个实验室上、第几周到第几周上、要不要换教室这些信息的准确性比任何花哨的功能都重要。因为实验课经常因为设备维护、期中考试等原因调整时间如果学生拿到的是过时的课表后果就是全班同学在错误的教室门口等上半小时。所以查询模块对数据实时性的要求反而比排课模块更高。1.2 系统功能边界与核心需求清单项目标题里虽然只写了“排课与查询系统”但实际开发时不能只做这两个功能。排课之前得有实验室信息的管理排课之后得有数据的维护和调整查询也不能只让一个人查不同角色看到的内容应该完全不同。我梳理之后把系统切成下面这几个功能模块实验室管理、教师管理、班级管理、排课管理、课表查询、系统管理。实验室管理维护的是机房编号、位置、容纳人数、设备配置、是否可用这些基础信息教师管理和班级管理解决的是“谁申请、给谁排”的问题排课管理是整个系统的核心承担时间片分配和冲突检测课表查询则面向教师和学生提供按周次、按实验室、按教师三种维度的检索方式系统管理负责管理员登录、账号分配、数据备份这些后台操作。这套功能边界的划分有一个原则排课是管理行为查询是服务行为基础信息是数据底座。没有基础信息排课无源可依没有排课数据查询就是空转。把这三个层次分清之后后面做数据库设计和接口设计就顺了。2. 总体架构与数据库设计2.1 微信小程序 后端服务 管理后台的整体方案这套系统名字里带weixin前端选择微信小程序是一个很实际的决定。高校师生几乎人人都有微信小程序不需要单独安装App扫一扫就能用尤其是学生端“查课表”这种高频但轻量的操作小程序比网页端方便太多。教师和管理员的排课操作相对复杂我建议走网页管理后台毕竟在小程序里做复杂的表格拖拽、批量导入并不顺手。后端我采用的是Spring Boot MyBatis MySQL的组合。Spring Boot负责提供RESTful接口小程序端通过wx.request调用MyBatis处理数据库的读写MySQL存储所有业务数据。之所以选这套组合是因为它成熟度高、网上资料多遇到问题不愁找不到解决方案。当然如果你自己更熟悉PHP或者Node.js完全可以替换核心的表结构设计是不变的。整体架构其实只有三层小程序/网页前端通过HTTP接口请求后端服务后端服务处理业务逻辑并访问MySQL数据库。没有引入Redis或者消息队列这些中间件不是因为它们不好而是对于单校区的实验室排课场景并发量很低一台普通服务器扛几百个老师同时查课表绰绰有余。过度设计是这类项目最常见的坑能简单解决的问题不要上来就搞微服务。2.2 核心数据表设计与关系规划数据库设计是整个系统最关键的部分因为排课系统的核心本质上是“数据关系是否正确”。我设计了6张核心表每张表都有自己的职责。实验表lab字段包括lab_id、lab_name、lab_location、capacity、equipment、status。status标识这个实验室是否可用比如设备维修期间可以临时设置为0排课时就会自动排除。教师表teacher字段包括teacher_id、teacher_name、department、phone。学生表student字段包括student_id、student_name、class_name、major。这里需要提一下学生并不仅仅是为了登录而存在班级信息是排课的重要参照因为排课的最小单位是班级而不是单个学生。排课表schedule这是整个系统的核心字段比较丰富schedule_id、lab_id、teacher_id、class_id、course_name、week_start、week_end、weekday、section_start、section_end、semester。week_start和week_end表示从第几周到第几周weekday表示星期几section_start和section_end表示第几节到第几节。这样设计的灵活性在于可以非常方便地表示“第3周到第12周每周二的第3-4节”这种常见的重复性排课而不需要把每周都单独存一条数据。这里有一个设计上的取舍值得说一下为什么不用“每一天存一条排课记录”的方案因为那样数据量会膨胀好几倍而且查询时会非常啰嗦。用周次的区间存储虽然查询时要多做一次区间判断但数据表保持精简维护起来也容易。后面讲的冲突检测就是在这个区间模型上实现的。2.3 排课冲突检测的核心算法思想排课系统的灵魂在于冲突检测。所谓冲突可以归纳成三种情况同一实验室在重叠的时间片内被安排了两门课、同一个老师在重叠的时间片内被安排了两次课、同一个班级在重叠的时间片内被安排了不同的课程。要检测这三种冲突本质上是判断两个时间区间是否有交集。假设已有排课记录时间范围是week_start到week_end、每周weekday、节次section_start到section_end新申请的时间范围是new_week_start到new_week_end、new_weekday、new_section_start到new_section_end那么“重叠”的条件就是周次上有交集new_week_start week_end 并且 new_week_end week_start 星期几相同weekday new_weekday 节次上有交集new_section_start section_end 并且 new_section_end section_start三个条件同时满足就意味着冲突了。这个判断用SQL写的话大概是这样的SELECT COUNT(*) FROM schedule WHERE lab_id #{labId} AND #{newWeekStart} week_end AND #{newWeekEnd} week_start AND weekday #{newWeekday} AND #{newSectionStart} section_end AND #{newSectionEnd} section_start AND semester #{semester}简单说就是“新时间段的开始早于已有时间段的结束并且新时间段的结束晚于已有时间段的开始”只要区间重叠就返回计数大于0就说明这个时间片已经被占用了。这里有一个特别容易出错的地方——边界的包含关系。比如已有排课是第3节到第4节新申请是第4节到第5节这种情况算不算冲突在实际排课里当然是算的因为第4节课你不可能同时上两门课。所以判断时必须用小于等于和大于等于不能把边界情况漏掉。这个小问题我第一次做的时候就没注意导致后来自测时发现同一节次被排了两门课好在当时还没有正式数据不然就闹笑话了。3. 核心模块实现排课、查询、管理三重功能3.1 排课模块周次-节次-实验室三维排课排课模块的后台页面我是按照“日历式”布局来设计的。管理员进入排课页面后左边是一个实验室列表中间是本周的课表网格网格的行为星期一到星期日列为节次。点击某个空闲的单元格系统会弹出一个排课表单让管理员选择班级、课程名称、开始周次、结束周次然后提交保存。这样设计的用户体验比较友好因为管理员不再需要面对一堆字段而是直接“看空填位”。但这对后台的逻辑处理提出了一个要求系统必须能够实时计算出某个实验室某个时间片是否空闲并展示出所有已被占用的位置。我在后端提供了一个查询接口传入labId和weekday返回当天所有已排的记录。前端拿到这些记录后把从section_start到section_end的所有单元格标记为“已占用”同时设置点击不可用状态。如果两个排课记录的节次区间重叠网格上就会有一块连续高亮区域直观地向管理员展示占用情况。排课提交时前端把整个表单数据封装成JSON提交给后端后端先执行一次前面提到的冲突检测SQL确认没有冲突后再执行插入操作。这里我建议用数据库事务把“查询冲突”和“插入记录”两步包起来因为在高并发场景下两个请求可能同时通过冲突检测然后同时插入导致冲突数据产生。虽然实验室排课的并发量并不高但养成这个习惯没有坏处。3.2 查询模块教师端与学生端的差异化展示查询模块是这个系统面向学生和教师最频繁使用的功能我把它设计成三个维度按教师查询、按实验室查询、按班级查询。学生端的小程序首页就是一个“本周课表”的默认视图。用户登录后系统根据学生所属班级自动拉取本学期的排课数据然后按星期一到星期日、第1节到第12节生成一张课程表。这里有一个小细节如果某个学生跨周次有不同课程比如单周上A课、双周上B课那么课程表的展示必须区分当前是哪一周。我的做法是后端根据当前日期计算出所在的教学周次然后只返回当前周有效的课程数据。这样学生打开小程序就能看到“本周”的真实课表不用自己数周次。教师端查询则不太一样教师更关注的是“我这门课被安排到了哪个实验室”以及“我一周的课是怎么分布的”。所以教师端默认视图是一个按星期排列的课程列表每门课程会显示课程名、班级、实验室编号、节次、起止周数。另外我还加了一个“按实验室查看”的功能方便教师查询某间实验室的空闲时间比如需要调课时可以直接看到哪些时间段是空的。学生端的查询还额外做了一个“按周次切换”的功能周次选择器可以从第1周拉到第20周选择后课程表会自动更新。这个功能看似简单但实现起来要注意后端接口要做周次参数的透传前端也要在切换时重新请求数据并做好加载状态的管理避免出现白屏或者旧数据闪烁的问题。3.3 管理后台实验室信息与排课记录管理管理后台除了排课之外还有不少琐碎但必须做好的功能。实验室信息管理支持新增、编辑、删除实验室设置实验室的最大容量和设备说明同时支持批量导入管理员可以从Excel中一次性导入几十间实验室的信息省去逐条录入的麻烦。排课记录管理页面则是一个综合表格列出所有排课记录支持按学期、按实验室、按教师过滤筛选。管理员可以对某条排课记录进行编辑或者删除。编辑时有一个需要特别注意的地方——如果管理员把某条记录的节次从“3-4节”改成“5-6节”系统必须重新做冲突检测不能因为记录本身已存在就跳过校验。这个逻辑我在开发时差点遗漏因为一开始想着已经排好的记录改一下应该没问题但实际测试时发现如果改成的时间片被其他课占用了系统不会拦截直到数据越来越乱才意识到问题的严重性。管理后台还包括账号管理、修改密码、数据导出等功能。数据导出的价值往往被低估。学期结束时管理员需要向教务处提交实验室使用情况报告如果系统能一键导出Excel格式的排课总表至少能省下半天的人工整理时间。我实现的时候用的是Apache POI后台生成Excel文件前端提供下载按钮效果还不错。4. 关键细节设计与避坑实录4.1 时间冲突检测的边界条件处理前文提到的冲突检测算法看起来只有简简单单几行SQL但真正处理起来你会发现很多边界条件需要注意。第一个就是跨周次的课程。比如某门课从第2周到第8周每周三第7-8节上课。另一个老师在申请第6周到第10周的周三第7-8节时系统必须判断出两者在第6周到第8周之间是重叠的。这里我用的是区间重叠判断也就是new_week_start existing_week_end new_week_end existing_week_start这样就能正确覆盖部分重叠的情况。第二个是跨节次的课程。有些实验课是两节连上有些是四节连上比如第3-4节和第3-6节它们在3-4节上必然重叠。如果只判断“节次的开始值是否相同”就会漏掉这种部分重叠的情况。我的做法是对节次区间做同样的重叠判断确保任何一段节次的重叠都会被捕获。第三个是星期几不同但日期相邻导致的问题。比如某门课星期五第1-2节另一门课星期六第1-2节这两者并不冲突。因为weekday字段的星期几是精确匹配的跨天不会互相干扰这个反而简单。但如果哪天有人提出“周六周日也算统一教学周”就得把weekday扩展成日期类型的字段而不是单纯枚举1到7了。4.2 实验室状态联动与空闲判断逻辑很多初学排课系统的同学会把“实验室状态”和“排课状态”搞混直到数据变得混乱。我在设计时把这两个概念做了严格区分实验室的基础状态status表示物理可用性比如维修中的机房设为0正常使用的设为1而排课状态则是动态的需要根据schedule表实时计算。举例来说某间实验室status1表示设备正常、可以排课。但是在某个具体的周三第5-6节如果schedule表里已经有一条占用该实验室的记录那么这个时间片的“空闲状态”就是false。反过来如果实验室status0那么无论schedule表里有没有记录这个实验室都不能再被排新课程。这给前端带来了一个联动的要求小程序端显示课表时如果某个实验室被标为维修中那么这张课表的“可选择”状态必须置灰不能让学生以为还能申请使用。后台排课时也一样下拉框里应该自动过滤掉status0的实验室。这个逻辑听起来理所当然但开发时如果前端和后端各写各的判断很容易出现一边显示可用、一边提交报错的情况。建议把空闲判断统一收敛到后端接口中前端只负责展示接口返回的状态。4.3 微信小程序端的数据缓存与刷新策略小程序端的性能优化是很多从Web开发转过来的同学比较容易忽略的地方。排课查询这种场景操作频繁但不涉及复杂的交互如果每次切换页面都重新请求服务器会带来两个问题流量浪费和体验卡顿。我采用的策略是本地缓存加后台刷新。小程序进入时先从本地缓存读取课表数据并渲染同时在后台发起请求获取最新数据等新数据返回后再用wx.setStorageSync更新缓存并重新渲染页面。这样用户打开课表几乎是无感的即使在网络状况不太好的情况下也能先看到上一次加载的数据不至于白屏干等。当然缓存策略必须配合“手动刷新”和“自动失效”一起使用。我在课表页放了一个下拉刷新的手势用户下拉就能强制重新请求数据。同时缓存数据里会保存更新时间戳如果超过12小时没有更新前端会自动忽略缓存、直接走网络请求。这里有一个小经验缓存更新时一定要用setData重新渲染后端返回的最新列表不能只更新storage不重绘页面否则用户看到的还是旧课表。5. 从开发到落地几个值得注意的经验教训5.1 需求确认阶段最容易被忽略的细节这项目给我最大的教训不是技术上的而是需求确认上的。在动手写代码之前我只和实验中心主任聊了不到半小时就自以为完全理解了需求结果第一版做出来之后对方看了一眼说“挺好但我们需要按教学周显示你现在显示的是按日期排的”而我当时把weekday设计成了具体日期而不是星期几。这个改动说起来不复杂但它牵连了数据库字段、后端查询逻辑、前端课表渲染三个层次相当于把整个系统的地基重新打了一遍。从那以后我每次做这类管理系统都会先花时间把业务流程彻底搞清楚排课是按周次为单位还是按天为单位调课有没有审批流程同一个班级能不能一周排两次实验课选修课和必修课要不要区分。这些问题的答案直接影响表结构越早确认越好。建议拿到项目后先写一份一页纸的需求确认清单找用户逐条确认哪怕觉得有些问题问得很傻也没关系。磨刀不误砍柴工这句话放在软件项目里再正确不过。5.2 数据权限设计的一点点心得权限设计也是这类系统里绕不开的话题。我的做法是分三种角色管理员、教师、学生每种角色的接口权限不同。管理员的token由后端颁发有效期为2小时教师和学生登录后也会拿到对应的token但接口级别更受限。这里我踩过一个不算小的坑最开始我让前端把用户角色放在请求参数里传给后端后端依靠参数判断角色。结果测试阶段发现只要懂一点抓包知识的人就能伪造管理员参数直接调用排课接口。后来改成了在拦截器里统一解析token、从token中获取用户角色后端完全信任token信息不信任任何客户端传过来的角色参数。这是一个安全方面的基础意识但很多课程设计级别的项目恰恰容易忽略。哪怕只是一个课设也建议从一开始就按这种方式做。5.3 后续可扩展的方向虽然系统已经上线跑了一个学期但站在现在的角度看有几个方向是可以继续深入的。第一是智能排课。目前的排课是半手工模式管理员需要在可视化网格上逐项选择。如果有几百个班级要排课这依然是一个不小的工程量。可以考虑写一个自动排课算法把班级、课程、实验室容量、教师时间偏好作为约束条件用回溯或者贪心策略自动生成排课方案再让管理员微调。这个方向做起来比较有挑战性也很有意思。第二是实验室利用率统计。目前系统里虽然存了所有排课数据但没有做数据分析和可视化。如果把每个实验室的周使用时长统计出来再算一算总可用时长和使用率对于学校申请设备更新经费、优化实验室资源配置都会有非常直接的帮助。第三是与教务系统对接。现在教师和学生的账号是单独维护的如果能接入学校的统一身份认证两个系统之间的数据同步就会简单很多也能减少管理员手动维护账号的工作量。最后再分享一个我在实际操作中的体会这类管理系统的成败很多时候不是看功能有多炫而是看数据录入和展示环节的细节做得够不够贴心。数据录入时要尽量减少管理员的手工输入次数能用下拉选择的绝不用文本框能批量导入的绝不让管理员逐条操作数据展示时则要保证查询速度、信息层级、以及最重要的——准确性。准确度是第一位的一个误导人的错排课会让老师和学生对整个系统失去信任。做排课与查询系统给我的收获不只是写了几千行代码而是明白了一个朴素道理工具越强大越要敬畏数据的准确性。计划赶不上变化但这套系统让我真正体会到了“让数据多跑路、让人少跑腿”的成就感。