山东大学软件学院的创新实训几乎是每个软院本科生大学四年里最接近真实软件开发的一次体验。它不是一门普通的课程更像是一个缩水的“创业项目模拟器”给你十几周时间让你自己组队、自己选题、自己做需求分析、自己设计架构最后交付一个能跑、能讲、能演示的软件作品。这篇文章是“创新实训一”记录我们从课程启动到完成第一阶段里程碑的全过程包括团队搭建、选题决策、需求分析、技术选型和项目管理落地。如果你正准备开始类似的实训或课程项目这篇文章可以帮你少走很多弯路。先说结论创新实训最难的不是写代码而是“确认自己要做的东西到底值不值得做以及怎么做”。我们小组从组队到确定题目花了近一周期间否决了四个候选方向最后选了一个看上去不那么“高大上”但落地性极强的题目——基于微信小程序的校园二手交易平台。接下来我会按时间线详细拆解每个阶段做了什么为什么要这么做以及踩过的坑。1. 创新实训到底在训什么课程定位与真实目标1.1 课程定位和考核方式山东大学软件学院的创新实训通常在本科三年级下学期或四年级上学期开设不同年级安排略有差异但核心框架一致以团队为单位在限定时间内完成一个完整的软件项目。课时安排上分两个阶段第一阶段偏重需求分析与架构设计第二阶段偏重编码实现和系统测试。我们本次记录的是第一阶段周期大约六周。考核方式不是简单的“期末交个代码”而是多维度的过程文档占三成代码质量占三成中期演示占两成团队互评和个人贡献占两成。尤其注意过程文档不是事后补的指导老师会定期检查Git提交记录、需求变更记录、会议纪要。换句话说这一门课逼着你养成“像软件公司一样工作”的习惯而不是像课程设计那样最后一周突击。1.2 我们对创新实训的初始误判实训开始前我们一度以为这是一个“拼创意”的舞台谁的项目看起来酷、用了新框架、有AI加持谁就能拿高分。但我们和上一届学长交流后发现得高分的项目往往不是最炫的而是“需求清晰、完成度高、演示流畅、文档齐全”的项目。很多组选了“基于深度学习的XX识别”“某某推荐算法系统”结果数据找不到、模型精度达不到、前端粗糙最后演示翻车。所以我们从一开始就定了一个基调不盲目追求技术新颖性优先保证项目完整和闭环。这个决策在后续几周被证明极其正确。课程设计的本质是让你完整体验一次软件工程流程而不是真的做出能改变世界的产品。理解这一点选题方向就清晰多了。2. 团队搭建与选题决策比写代码更早的“代码”2.1 组队的三个关键条件软件学院创新实训是自由组队3到5人。我们组最终是4个人T负责后端L负责前端W负责产品文档和测试我负责架构决策和整体协调。这个分工不是一次到位的我们用了两天时间互相了解彼此的可用时间和技术栈。组队时我总结了三个关键条件缺一不可技术栈互补。如果四个人全写前端后端没人做如果全是后端前端UI可能惨不忍睹。我们组恰好T有Spring Boot开发经验L用过uni-app开发过小程序我做过MySQL和Redis调优W虽然代码弱一些但她资料整理能力极强正好补上文档和测试缺口。时间投入基本一致。这是实训里最容易引发矛盾的坑。有人准备考研只愿意每周投入5小时有人想拿国奖每周能投入30小时这两类人待在一起必然出问题。我们组提前约定每周至少保证20小时的有效开发时间并且接受周五晚上固定开进度会。能心平气和地吵架。创新实训过程中分歧必然发生比如技术选型、需求优先级、UI风格。组队时就该说清楚对事不对人谁负责的模块谁拍板但最终决定要写进文档。2.2 选题评估矩阵我们如何筛掉伪需求第一周我们列出了五个候选题目基于知识图谱的课程推荐系统校园互助跑腿小程序基于NFC的考勤打卡应用宿舍报修与后勤管理平台校园二手交易平台如果用直觉判断第一个听起来最有“技术含量”第五个听起来最普通。但我们没有马上决定而是做了一个简单的选题评估矩阵给每个题目打分因子包括需求真实性、数据获取难度、核心功能复杂度、团队技术匹配度、演示效果、开发时间预估。满分5分权重各不同。评估结果如下节选题目需求真实性数据获取功能复杂度技术匹配演示效果总分课程推荐系统4243417校园跑腿小程序4434419NFC考勤应用4242416宿舍报修平台3333315二手交易平台5434521最关键的变量是“数据获取”和“需求真实性”。课程推荐系统虽然听起来高级但需要大量的学生行为数据、课程评价数据我们在校园内拿不到规模化的真实数据只能造数据这就很虚。二手交易平台不一样每个学生的宿舍里都有闲置物品校园里已经存在大量微信群在自发做二手交易需求是被验证过的数据可以自己生产演示时也可以直接让一个观众现场发布一件“商品”。2.3 确定“校园二手交易平台”作为切入点最终我们选择了二手交易平台并且将题目收敛为“基于微信小程序的校园二手交易平台”理由是微信小程序是校园场景中最自然的存在形式学生不需要额外安装App扫码即用。技术上基于uni-app一次开发能同时输出小程序和H5对前端同学压力可控。校园二手交易存在明确痛点微信群信息流刷新太快商品无人索引搜索靠翻聊天记录没有信用体系买家卖家无法互评交易纠纷无第三方仲裁交易状态无法跟踪。这些痛点正好可以用软件工程的方式系统解决。功能边界清晰可以做成一个完整闭环发布商品→搜索浏览→发起购买→订单管理→支付确认→互评再加上管理端的审核和举报处理。这里我要给大家一个非常实在的建议如果你的创新实训周期只有十几周尽量选择“业务逻辑完整但复杂度适中”的行业比如校内交易、赛事报名、课程管理、宿舍服务。这类项目你身边就有用户需求调研非常方便演示效果也真实不容易翻车。3. 需求分析与用例建模把“感觉”变成“边界”3.1 访谈和问卷中的典型反馈选题确定后我们用了整整一周做需求调研。这一阶段不能省因为它直接决定后续的数据库设计和接口设计。我们做的事情分三块线下访谈找了10个不同年级的同学每人聊20分钟重点问他们在二手交易中的真实经历。线上问卷通过班级群、宿舍群发了150份问卷回收有效问卷126份问卷里包含“你最常买哪类二手物品”“之前通过什么渠道交易”“你在交易中遇到的最大问题”等内容。竞品分析我们跑通了“闲鱼”“转转”的完整流程记录它们的页面结构和核心功能讨论哪些放到校园场景下合适哪些不合适。调研结果有几个共性反馈超过70%的人用过校园二手群但吐槽“找东西太难了”“经常被刷屏错过秒杀”。50%以上的人表示不知道怎么确认对方信誉“只能赌对方是校友”。很多人提到“面交最安全但不知道对方宿舍在哪”“希望有一个虚拟位置沟通机制”。有部分卖家表示“定价很费劲不知道自己东西该卖多少钱”这个需求我们定义为“估价辅助”放在P2优先级因为功能价值有但实现成本高。这些反馈没有一条是脑补出来的全部来自真实用户。需求分析阶段最大的收获就是把“我觉得用户需要什么”换成“用户告诉我他们需要什么”。对创新实训来说这就是得分的核心点。3.2 用户故事与用例优先级我们按敏捷习惯写用户故事格式是“作为XX角色我希望能够XX以便XX”。下面是几个典型故事作为买家我希望能够按照商品分类和关键词搜索闲置物品以便快速找到我想要的东西。作为卖家我希望能够拍照发布商品并设置价格和可议价范围以便我的闲置物品可以被同学看到。作为买家我希望能够查看卖家的历史交易评价和完成次数以便判断这次交易是否可信。作为管理员我希望能够审核可疑的商品发布和举报以便维护平台的基本秩序。这些用户故事直接转化成了用例图我们用的是draw.io画的不推荐Word画图。系统用例可以分成两个角色组普通用户含买家和卖家注册登录、浏览商品、搜索商品、发布商品、修改商品状态、下单、取消订单、确认收货、评价、收藏、举报。管理员用户管理、商品审核、举报处理、公告发布、订单仲裁。用例确定后我们用MoSCoW法排优先级。P0是登录、发布、浏览、搜索、下单、订单状态流转P1是评价、举报、个人中心P2是收藏、消息推送、估价辅助。P0和P1是第一阶段开发范围P2预留到第二阶段如果有余力再做。这里的关键教训是如果一开始把全部功能都设计进去开发时间一定不够。实训项目的成功不是做得多而是把承诺的功能全部保质交付。3.3 原型设计与需求文档的落地需求文档方面我们写了一约30页的《需求规格说明书》包含背景、用户画像、功能需求、非功能需求、界面草图。界面草图用Axure画了低保真原型每个页面只标注功能区域和跳转关系不纠结配色。低保真原型的作用非常大。我们把原型拿给几个目标用户看他们当时就提出来“发布按钮怎么这么隐蔽”“搜索结果能不能按新旧排序”这些都是看文字需求时发现不了的直观问题。我们根据反馈快速迭代了原型版本在进入编码前就把核心交互逻辑敲定。第一阶段的交付物当然不是只有代码需求文档、原型、用例图、流程图都是考核材料。我们约定所有文档统一使用Markdown格式存放在Git仓库的docs目录下并使用飞书文档做评审留痕。这里插一句工具统一真的很重要上学期小组作业吃过“文档格式百花齐放”的亏这次从第一天起就定规矩。4. 技术选型与系统架构设计别一上来就写代码4.1 技术选型打分表技术选型我们用了三天核心准则是“团队最熟悉的技术能满足需求的稳定方案”而不是“最新最潮的方案”。我们组基本情况是T熟悉Java和Spring BootL熟悉uni-app和Vue我熟悉MySQL和RedisW能做一些基本的接口测试。最终技术栈如下层次选型理由前端uni-app Vue 3一套代码可输出微信小程序和H5开发效率高学生社区资料多后端Spring Boot 3.xJava生态成熟团队熟练后续调试维护成本低数据库MySQL 8.0 Redis 7MySQL存业务数据Redis存会话和热门商品缓存对象存储阿里云OSS图片存储稳定接口简单有免费额度部署腾讯云轻量服务器 Docker学生认证有优惠Docker Compose一键部署很多组会纠结要不要上微服务架构、服务网格、消息队列。我的建议是团队里如果没有一个人有绝对把握驾驭这些技术就不要上。我们第一阶段明确采用单体应用模块化分包的方式把所有业务代码放在一个Spring Boot工程里通过包名区分用户、商品、订单、管理四个模块。这样做的好处是构建和部署简单联调方便出现问题时可以快速定位。等到第二阶段如果并发性能真的成了瓶颈再考虑服务拆分也不迟。4.2 模块划分与软件架构图我们画的架构图分三层客户端层、服务层、数据层。客户端层包括微信小程序和H5两个入口统一通过HTTPS调用后端API。服务层部署在Docker容器里核心是一个Spring Boot应用内部按业务拆成controller、service、mapper三层模块之间只通过接口通信。数据层包含MySQL主库和Redis缓存其中MySQL用主从同步做备份Redis负责缓存首页热门商品和商品浏览量计数。模块划分上我们拆成四个模块用户模块注册、登录微信授权登录、个人信息管理、评价聚合。商品模块商品发布、商品列表、搜索、分类筛选、商品详情、下架。订单模块创建订单、状态流转待支付→已支付→待发货→已发货→已确认→已评价、订单列表。管理模块后台管理界面使用H5实现、商品审核、用户封禁、举报处理。每个模块由一个人作为负责人接口定义通过Swagger自动生成。这里有一个重要经验接口定义必须放在开发前先完成字段名、参数类型、错误码要形成文档前后端联调才不吵架。我们第一周就定义好了主要接口用Postman做了Mock数据让前端同学可以并行开发。4.3 数据库设计的关键考虑数据库设计是第一阶段里相对枯燥但绝对不能出错的部分。我们画了ER图核心表包括user用户表product商品表category分类表order订单表order_item订单明细表comment评价表report举报表review_record审核记录表商品表是重点字段除了基本的信息还包含condition物品成色九成新/八成新等、price、original_price用于显示降价力度满足用户砍价心理、status在售/已预留/已售出/下架、latitude和longitude用于展示交易地点的大致方位。我们特别注意了索引设计搜索会用到category_id和status的组合列表中按create_time倒序因此在product上建了复合索引(category_id, status, create_time)。订单表考虑到可能的状态变化用了状态机设计而不是单纯存一个字符串。我们定义了一个枚举OrderStatus包含CREATED、PAID、DELIVERED、RECEIVED、COMMENTED、CANCELLED、REFUNDING等状态每种状态只允许特定的流转方向。这样后续代码写起来很清晰不会出现字符串到处传递、状态不可控的问题。数据库同步和备份问题我们第一阶段做得比较简单MySQL开启binlog日志每天凌晨通过cron任务用mysqldump自动备份到对象存储。备份只是兜底方案真正重要的是把开发库和测试库分开。我们约定本地开发各自用各自的MySQL线上环境只部署一份用于演示。这么做是因为如果是多人连接同一个开发库表结构变更很容易互相干扰。5. 项目管理的具体落地看板、例会、版本控制5.1 敏捷迭代和任务拆解实训不是一个人的战斗项目管理能力是隐性考核项。我们选择了极简的Scrum模式每周一个Sprint周五开Sprint Review和Retrospective周六到下周四编码用飞书看板管理任务。看板列划分为待办、设计、开发中、待测试、已完成。每个任务卡片必须包含三个信息任务描述、验收标准、预估时间。比如“发布商品页表单校验”这张卡验收标准是“标题必填、分类必选、图片必传、价格大于0无效输入时页面提示具体错误”。没有验收标准的任务就是耍流氓下会评审时很难判断是否真的完成。任务拆解我们做得比较细比如“商品模块”拆成十几张小卡。一个经验是每个人手头同时只保留一到两个“开发中”的任务而不是一口气拿一堆任务进去做。因为频繁切换任务的心理成本很高而且容易造成半成品堆积影响团队透明度。5.2 Git分支与团队协作规范版本控制我们使用Gitee私有仓库因为国内访问速度快免费版够用。分支策略采用简化版Git Flowmain分支永远保持可部署状态每轮评审通过后再合并。develop分支日常开发集成分支。feature/xxx分支每个功能从develop切出完成后合并回develop。代码评审流程是这样的每个功能分支开发完成后提交Pull Request给至少一位组员审查审查通过后才能合并。审查重点关注这几点命名是否清晰、有没有魔法值、SQL是否有全表扫描风险、是否处理了空指针。这个流程刚开始大家都嫌麻烦但到第二轮Sprint时合并后的代码明显更稳定几乎没有出现“改了A模块导致B模块崩”的情况。我们还在仓库增加了版本标签tag每个里程碑打一个tag比如v0.1.0是原型设计完成v0.2.0是第一个可运行的前后端联调Demo。这方便后期查阅也方便写得奖材料。5.3 例会与沟通机制每周固定两次会周一中午10分钟同步进度周五下午两小时的Sprint Review。周一短会只回答三个问题上周完成了什么、这周打算完成什么、有没有阻碍。周五评审则是全组演示功能W作为测试负责人会现场点。这里我们踩过一个坑开始几周会议记录没有规范保存导致有人迟到错过信息后面再问很浪费时间。后来我们规定会议记录由W负责统一记录到飞书文档并且用加粗标出“行动项负责人DDL”三个字段。行动项不接受模糊表述必须是“L在周三前完成商品搜索接口的Mock数据并提供给前端”。6. 第一阶段执行过程中的常见问题与避坑实录6.1 典型问题速查表十几周下来我们遇到的最典型的几个问题这里统一整理成表格方便后面的人直接对号入座问题现象排查思路我们的解法需求蔓延开发到一半队友提出新功能问清楚是P0还是P2再问是否影响当前迭代把需求写进Backlog排到下个Sprint接口字段不一致前端拿不到userNickname后端叫nickName前后端从第一天起共用API文档使用Swagger并约定所有字段名用驼峰数据库锁表多人同时操作开发表导致阻塞检查是否一个连接池被多个服务共用本地库彻底隔离线上只留演示环境代码冲突两个人改了同一个文件拆任务时没有按模块边界分强制模块负责人制尽量不跨模块修改Git提交信息混乱一堆“update”“bug fix”看不出做了什么没有规范提交信息约定feat/fix/docs/style前缀描述必须能看懂6.2 经验与后续规划第一阶段结束验收那天我们演示了完整的用户发布商品到下单的核心链路虽然还有几处UI比较粗糙但评委老师认为需求分析和架构设计文档扎实给了不错的评价。我的体会是创新实训的考核重点不是代码量而是“你有没有建立一个完整的工程思维”。哪怕你的项目很小只要能清晰地回答“用户是谁、要什么、你的系统如何满足、边界在哪里、出了问题怎么办”就已经合格了。最后分享一个小小的技巧每一次会议结束记得将近期的关键决策写进项目根目录的DECISIONS.md文件。这个文件记录“我们为什么弃用了NFT方案”“为什么选用单体架构”“为什么评价功能放到P1”等写实训报告时直接引用特别省力而且能让指导老师看到你们组的思考过程。这比花大量时间写没实质内容的“心得体会”要值钱得多。创新实训的第一阶段到这里就告一段落。后续第二阶段我们将开始全面编码包括订单状态机、支付模拟和部署上线到时候我还会继续记录。如果你也在做类似的实训项目欢迎对照我们走过的路看看自己是不是也掉进了同样的坑。祝你的实训顺利。