我带的毕业设计小组里去年有三位同学不约而同选到了“影院管理系统”这个题目。其中一个花了半个月用JSP撸了个能跑的版本答辩前一晚找我彻夜调Session另一个用了SpringBootVue的前后端分离方案三天就把核心功能跑通了最后还有时间把选座交互打磨得很漂亮。同一个题目技术选型不同过程和结果天差地别。这篇文章就围绕“基于SpringBootVue的小徐影城管理系统”展开把整套系统的设计与实现思路拆开讲清楚包括数据库怎么设计、后端核心业务怎么写、前端那些真正难啃的地方在哪以及我这边见过的、容易让人卡住的坑。无论你是准备拿它做毕业设计还是想找一个完整的Java全栈练手项目这篇文章都能让你少走不少弯路。1. 影院管理系统的真实业务边界不只是“卖票”这么简单很多人一听“影院管理系统”第一反应就是“做几个增删改查页面卖卖电影票”。真上手做才会发现哪怕是最简化的版本它也是一个同时涉及权限体系、排片数据建模、库存并发处理、订单状态流转的综合性管理系统几乎覆盖了企业级业务系统的所有核心环节。1.1 两种核心角色两条完全不同的操作主线系统里天然存在两类用户管理员和普通用户。这两类人的诉求完全不同系统也必须围绕他们分别设计功能入口。管理员侧侧重的是运营管理。电影信息的上架、下架影厅的维护放映场次的排布订单的查看与统计这些都是高频操作。我见很多学生项目在这里犯一个典型错误把管理端功能塞进和用户端一样的页面里用权限字段去隐藏按钮导致代码里到处是“if(role1)”维护成本极高。正确做法是从工程结构上就把两端拆开。前端拆成两套路由体系后端拆成两套控制器前缀比如 /admin/** 和 /api/**权限通过拦截器做统一校验。这样不仅代码清晰答辨的时候讲“权限划分”也远比“我加了个判断”要有说服力得多。用户侧核心是**找片、选场、选座、下单、支付模拟**这一条完整链路。注意这里的“选座”不是简单记录一个座位号而是要让用户在前端看到座位图、选中的座位高亮、计算价格、提交后锁定座位。这个交互设计的好坏直接决定了项目看起来是“课设水准”还是“能演示的水准”。1.2 功能模块的划分一共六大块缺一块都不闭环我习惯把整个系统拆成六个模块用户模块注册、登录、个人信息维护。注册时需要注意用户名唯一性校验密码不能明文存储。电影模块电影信息的增删改查前端按照“正在热映”和“即将上映”分类展示支持模糊搜索。影厅与排片模块影厅信息管理、座位布局定义、为每部电影创建具体场次某影厅某时刻放某部电影。选座购票模块前端选座、后端校验座位是否被占用、生成订单、锁定座位。订单模块订单列表、订单状态待支付/已支付/已取消/已使用、支付完成后更新座位状态。统计模块这是一个加分项比如每个电影的票房统计、每日订单量图表用前端图表库画出来视觉效果很好。从这六大模块也能看出来单说“卖票”其实只占一小部分真正花时间的是把不同模块之间的关系理清楚。而理关系这件事第一步就是设计好数据库。2. 技术选型分析为什么是SpringBootVue而不是其他组合这套系统名叫“小徐影城管理系统”从标题就能看出技术栈是JavaMySQLMyBatis。我可以负责任地说SpringBoot2.x Vue2/Vue3 MySQL MyBatis 这套组合是目前毕业生做管理系统类项目最稳的选择。它稳就稳在每样技术都是该领域最主流、最不容易出幺蛾子的方案社区资料极其丰富遇到报错一搜就有答案。2.1 为什么不选JSP/Servlet也不选SpringCloud早期很多教材还在教JSPServletJDBC那套但如果现在做新项目还选它纯属给自己挖坑。JSP在前后端分离时代已经明显落伍页面里嵌Java代码美术和逻辑强耦合改个样式都要重新编译。更重要的是JSP项目的接口和页面混在一起答辨时根本没法讲清楚“前后端交互”这个过程。反过来也不要因为追求简历好看就上SpringCloud微服务那套。影院管理系统这种规模业务逻辑不过十几个接口强行拆成多个微服务光服务注册发现、配置中心、网关、链路追踪这些基础设施就够喝一壶的最后往往淹没在环境问题里核心业务代码反而没写几行。这种过度设计在答辩时最容易暴露老师问一个业务逻辑问题学生答不上来只会说“我们用了Nacos”。2.2 SpringBoot解决了什么问题SpringBoot最大的价值是约定优于配置。内嵌Tomcatjava -jar就能跑自动化配置帮你把数据源、MyBatis、JSON序列化这些以前要写一堆XML的东西全部搞定。对于做毕设和练手项目来说它让你把注意力集中在业务代码上而不是浪费在“如何把Spring和SpringMVC整合起来”这种纯配置劳动上。版本选择上我建议SpringBoot 2.7.x JDK 8/11。这个组合最成熟网上的博客教程基本都是针对这个版本写的。SpringBoot 3.x要求JDK17起步虽然也可以用但在学校机房和老电脑上JDK环境不如8普及遇到问题排查难度更高。没必要在版本上标新立异。2.3 Vue的作用与MyBatis的取舍前端用Vue核心原因是组件化和数据驱动。座位选择器、影片卡片、订单列表都是一眼就能看出来的组件边界Vue的单文件组件写法天然适合做这种界面。配合Vue Router做路由控制、Axios做HTTP请求、Vuex/Pinia管理登录状态这一套本身就是一个完整、自洽的前端工程化方案。至于为什么用MyBatis而不是JPA更多是从可控性角度考虑的。影院系统里有大量的多表联查比如“查询某场次座位及对应订单状态”这种SQL用MyBatis写XML可以精确控制每一条SQL语句排查问题、性能调优都直观。JPA虽然也能做但很多初学者会被它的懒加载、级联操作搞晕一旦陷入“为什么查出来是空指针”的泥潭项目进度基本就停摆了。下面这张表是我做选型汇报时给学弟学妹看的对比放到这里供参考技术选型优点缺点适用场景JSPServlet教材体系全上手门槛最低前后端耦合严重项目难扩展面试/答辨减分学校课程设计最低要求SpringBootThymeleaf搭建快单体渲染页面仍属于服务端渲染前端交互受限页面简单、无复杂交互的系统SpringBootVue前后端分离职责清晰交互流畅简历/答辨最加分需要掌握前端工程化和跨域调试管理系统类项目的当前主流方案SpringCloud微服务分布式能力完整基础设施成本极高杀鸡用牛刀并发量大、系统复杂的企业项目3. 数据库设计核心表结构拆解与关键设计决策数据库设计是整个系统的地基也是很多初学者体制最薄弱的一环。影院系统的表结构有一个非常有趣的难点座位数据怎么建模。我见过有人把座位设计成“张三:1排2号,李四:3排5号”这种拼接字符串存进一个字段的当场血压就上来了。正确的做法是把座位拆成几层来理解下面我按实际设计顺序来讲。3.1 基础表用户、电影、影厅、场次首先是用户表 t_user。核心字段包括主键、用户名、密码、昵称、手机号、角色、创建时间。密码务必使用MD5加盐或BCrypt加密明文存储的项目在我这里是不可能通过的。电影表 t_movie字段比较多片名、导演、主演、类型剧情/动作/科幻、片长分钟、上映日期、海报URL、简介、上映状态0未上映 1已上映 2已下架。海报URL这里有个小细节很多人把图片直接传到服务器本地然后存一个相对路径但前端部署在另一个端口时图片就全裂了。稳妥做法是通过后端接口返回图片或者干脆存一个完整的可访问URL。影厅表 t_hall必须单独建不能偷懒。设计字段为主键、影厅名称、座位总行数、每行列数、放映厅类型普通厅/IMAX厅/VIP厅。为什么必须单独建因为不同的影厅座位规模不同而且后续如果要做“该影厅某个座位的长期占用状态”没有影厅表根本没法建模。场次表 t_session是连接电影和影厅的桥梁也是后续选座的核心字段如下字段名类型说明idbigint主键movie_idbigint关联电影表hall_idbigint关联影厅表start_timedatetime放映开始时间end_timedatetime放映结束时间可由片长推算pricedecimal(10,2)该场次基础票价statustinyint0未开场 1放映中 2已结束这里有个容易忽略的点同一影厅同一时间段不能排两个场次。这个约束最好在插入数据时做一次时间重叠校验否则到后面选座阶段会出现“两个用户用同一个座位看不同电影”的灵异事件。3.2 核心设计订单表和座位关系表接下来是系统最关键的部分——怎么把座位和订单关联起来。我的设计是建立一个独立的t_order_seat 表专门记录“某个订单占了哪个场次的哪个座位”order_id关联订单表session_id关联场次表seat_row / seat_col行号和列号不做独立座位字典表的原因很简单每个场次的座位由“影厅规模”决定座位本身不是实体“场次行列”三元组才能唯一确定一个可用座位。用 t_order_seat 这个关系表天然天然就解决了“同一场次的同一座位不能被两个有效订单占用”的问题——只要插入时先查一下这个三元组是否存在且订单未取消。再回头看订单表 t_order字段名类型说明order_novarchar订单编号雪花或时间戳生成user_idbigint下单用户session_idbigint关联场次total_pricedecimal(10,2)订单总金额statustinyint0待支付 1已支付 2已取消 3已使用create_timedatetime下单时间为什么订单表里不直接存座位列表因为一个订单可能买多张票用1排2号,1排3号这种逗号拼接字段虽然简单但之后如果想做“查看某场次哪些座位已售出”的查询就要在Java代码里解析字符串又慢又丑。订单和座位拆成主表和明细表是关系型数据库设计的标准做法答辨时这也是一个可以重点展开的亮点。3.3 索引设计与初始化数据要点索引方面t_order_seat 表要给 (session_id, seat_row, seat_col) 建联合唯一下标这是防止座位超卖的第一道物理防线。t_order 表的 user_id 和 status 建普通索引列表查询会快很多。t_session 表给 start_time 建索引以后做“某天的排片表”查询会用到。初始化数据也是很多人忽略的一步。我当时在那个Demo项目里预先导入了10部电影、3个影厅、每个影厅生成当天的5场内次这样一打开页面就有内容可以演示。如果只建表不导数据前端界面空空如也答辩演示的节奏感就全没了。4. 后端核心实现登录鉴权、排片查询与选座下单后端是这套系统的中枢我按“从底层到业务”的顺序讲。跑通一套SpringBoot工程并不难难的是把登录鉴权和事务控制下的座位锁定这两件事做好。4.1 后端工程结构与统一响应体建议的包结构长这样com.example.cinema ├── controller // 控制层接收请求返回结果 ├── service // 业务层核心逻辑都在这 ├── mapper // 数据访问层MyBatis接口 ├── entity // 实体类 ├── config // 配置CORS、拦截器、JWT等 ├── common // 通用类统一响应、异常处理 └── util // 工具类JWT、密码加密等所有接口统一返回一个 Result 对象里面有 code200成功/400业务错误/401未登录、message、data 三个字段。不要用Map或者裸JSON返回不然前端每次都要猜数据结构。4.2 登录鉴权拦截器 JWT而不是SessionSpringBoot里做登录态管理有两种主流方案Session和JWT。我强烈建议用JWT理由有两个一是前后端分离后后端不维护会话状态扩展性好二是JWT本身携带用户身份答辨时能讲清楚“无状态鉴权”这个概念。核心流程是用户登录成功后后端生成Token返回前端前端存在localStorage里每次请求在请求头带Authorization: Bearer token后端用一个拦截器校验Token解析出用户ID放入ThreadLocal。我这里给出一个最简可用的拦截器写法public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { response.setStatus(401); return false; } try { Long userId JwtUtil.parseToken(token.replace(Bearer , )); UserContext.set(userId); return true; } catch (Exception e) { response.setStatus(401); return false; } } }Token的密钥要放配置文件里不要硬编码在类里。我还建议Token里只放userId不放密码等敏感信息过期时间设置成2小时演示时时间长了容易忘记处理过期逻辑短了又老是要重新登录2小时比较折中。4.3 核心业务流程选座下单必须开启事务选座下单是整个系统业务复杂度最高、最容易出bug的地方。基本流程如下前端把场次ID、座位坐标列表、用户ID提交过来。后端计算总价。检查每个座位是否已被占用查 t_order_seat 是否存在有效记录。如果全部空闲创建订单状态为待支付批量插入 t_order_seat。返回订单ID给前端前端模拟支付支付成功后回调接口更新订单状态。第3步和第4步之间有一个经典的安全隐患叫做并发超卖两个用户同时看到同一个座位是空的都去提交订单如果查空和插入之间没有锁有极小概率两个人都会下单成功。解决的思路是给 t_order_seat 表建立前面第3.3节提到的唯一索引然后在插入时捕获 DuplicateKeyException捕获到就说明座位被抢了回滚整个订单。这是靠数据库约束兜底的方案。同时整个“查-插-更新订单”的过程必须包在同一个事务里。我见过太多半路出家的项目下单逻辑不写Transactional结果订单建了一半座位占用写失败了订单表里躺着一条“幽灵订单”用户界面显示“下单失败”数据库里却有脏数据。核心代码示意Transactional(rollbackFor Exception.class) public Order createOrder(Long userId, Long sessionId, ListSeatVO seats) { // 1. 查询场次信息计算总价 Session session sessionMapper.selectById(sessionId); BigDecimal total session.getPrice().multiply(BigDecimal.valueOf(seats.size())); // 2. 生成订单号并插入订单表 Order order new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setSessionId(sessionId); order.setTotalPrice(total); order.setStatus(0); orderMapper.insert(order); // 3. 批量插入座位关系记录靠唯一索引防超卖 for (SeatVO seat : seats) { try { orderSeatMapper.insert(order.getId(), sessionId, seat.getRow(), seat.getCol()); } catch (DuplicateKeyException e) { throw new BusinessException(座位已被选走请刷新后重新选择); } } return order; }这里有个细节事务切的是service层的方法不要把半截逻辑写在Controller里再调service否则事务注解容易失效。4.4 电影列表与多条件搜索的动态SQL管理端电影列表几乎都必须支持“按片名模糊搜索 按类型筛选 按状态筛选 分页”这时候MyBatis的动态SQL就派上用场了。XML写法大致这样select idselectMoviePage resultTypecom.example.cinema.entity.Movie select * from t_movie where if testname ! null and name ! and movie_name like concat(%, #{name}, %) /if if testtype ! null and type ! and movie_type #{type} /if if teststatus ! null and status #{status} /if /where order by release_date desc /select注意where标签会自动处理语句前多余的AND这个细节写在XML里比在Java里拼SQL优雅得多。5. 前端关键实现路由守卫、Axios封装与座位选择器前端我用的是Vue2 Vue Router Vuex Axios的标准组合。Vue2虽然官方进入维护期了但这套生态的教学资源最丰富对毕设项目来说稳定性比追新重要。前端真正考验水平的地方集中在三块请求封装、路由守卫、座位选择交互。5.1 Axios封装与请求拦截器不要每个页面都写一遍this.$http.post(...)那样的话后端接口一旦调整前端所有页面都要跟着改。正确做法是在src/utils/request.js里创建一个统一封装的Axios实例import axios from axios const request axios.create({ baseURL: /api, timeout: 10000 }) // 请求拦截器统一携带Token request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer token } return config }) // 响应拦截器统一处理401和业务错误 request.interceptors.response.use( response { const res response.data if (res.code ! 200) { Message.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res.data }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push(/login) } return Promise.reject(error) } ) export default request这套封装做完以后每个接口调用就是两三行代码前端整体的整洁度会上一个档次。5.2 路由守卫别让未登录用户摸进管理页Vue Router的路由守卫是权限控制的第一道关卡。在router/index.js里配置即可router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) return } if (to.path /login token) { next(/) return } next() })还可以从Token里解析角色来判断是否能进入管理端页面。注意一点前端路由守卫只控制页面跳转真正的安全校验永远在后端拦截器里前端只是用户体验层面的事情。5.3 座位选择器的设计思路这是整个前端最核心的交互组件。基本实现逻辑是页面加载时请求后端接口获取影厅的行列数和已被占用的座位坐标。用二维数组维护座位状态0为空闲1为已售出2为当前选中。点击座位时切换状态并计算已选数量。提交时把选中的坐标列表传给后端。座位组件一个很实际的展示方式是每一排用flex布局渲染一排按钮按钮的class根据座位状态动态切换。已售出的座位设为disabled并变灰空闲的座位可点击选中的座位变主题色。这里提供一个简化版的座位状态判断逻辑const seatStatus (row, col) { if (occupiedMap.has(row - col)) return 1 // 已占 if (selectedSeats.some(s s.row row s.col col)) return 2 // 已选 return 0 // 空闲 }提交前要在前端先把“已占座互斥”校验做掉后端还要再查一次库双重校验才稳妥。很多学员在这里会忽略一个小坑用户选好座位后页面长时间停留期间按刷新之前选的座位可能已被别人买走。因此提交订单前最好重新请求一次座位状态发现冲突就弹窗提示用户重新选择。另外别忘了展示影厅的“银幕位置”放在座位区上方加一行灰色边框的横条视觉上立刻就有影厅的感觉了。这种小细节很能提升答辩演示的观赏性。6. 完整源码的目录结构与本地运行指南拿到一套完整的SpringBootVue源码最怕的不是代码看不懂而是跑不起来。我按“后端→前端→数据库”的顺序把从零到一跑通的步骤和常见报错整理一遍。这套操作我陪不同的人做过至少五遍按下面步骤来基本半小时内能看到页面。6.1 环境准备清单跑通这套系统需要本地安装以下软件软件版本建议用途JDK1.8或11编译运行后端Maven3.6及以上管理后端依赖MySQL5.7或8.0数据存储Node.js14以上最好16前端构建运行开发IDEIDEA或VS Code写代码、启动调试数据库导入时要注意字符集建库语句最好显式指定utf8mb4避免存入emoji或生僻字时乱码。命令行导入方式mysql -u root -p -e create database cinema charset utf8mb4; mysql -u root -p cinema cinema.sql6.2 后端配置与启动配置文件在application.yml核心配置项如下server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/cinema?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.cinema.entity三个最容易踩的坑serverTimezone必须写Asia/Shanghai。不写的话高版本MySQL驱动会报时区错误或者日期时间差8小时。MySQL8.0要用 com.mysql.cj.jdbc.DriverMySQL5.7用 com.mysql.jdbc.Driver。版本不对会直接报ClassNotFound。如果密码含特殊字符yml里记得加引号否则SpringBoot读取配置时会把YAML语法搞崩。启动后端就是运行主类的main方法或者打包后mvn clean package -DskipTests再java -jar xxx.jar。看到控制台打印Tomcat started的日志就说明成功了。6.3 前端启动与代理配置前端目录下先执行npm install npm run dev这里90%的问题出在依赖安装失败网络原因或Node版本不兼容。换国内镜像源能解决一大半npm config set registry https://registry.npmmirror.com前端默认端口一般是Vite的5173或Vue CLI的8080。为了和后端端口错开需要在vue.config.js或vite.config.js里配置代理把/api开头的请求转发到http://localhost:8080这样才能解决开发环境的跨域问题。配置示例以Vite为例export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })建议前端所有请求路径都以/api开头这样一个代理规则就把所有跨域问题解决了不需要在后端单独配置CORS。6.4 首次启动的自检顺序跑通之后我建议按下面的顺序自检一下确认整套系统是健康的打开首页确认电影列表加载出来图片能正常显示。注册一个新用户成功后自动跳转到登录页。登录后进入某部电影的场次列表点进一个场次能看到座位图。选两个相邻座位提交订单模拟支付然后在“我的订单”里看到订单状态变成了已支付。用管理员账号登录后台能看到该订单的统计数据和这个订单的座位占用情况。自检过程中每通过一步就说明对应的模块没有问题如果某一步卡住了跟着下一章的排查思路走大部分问题都能定位到具体原因。7. 实测排错记录这套系统最容易踩的五个坑最后这部分我集中记录一下带人做这套系统时真实遇到过的、最有代表性的五个坑。这些内容都不在官方文档里但每一个都能浪费你大半天时间。7.1 坑一MyBatis字段映射不上查出来全是null实体类里有个字段叫movieName数据库列名是movie_name如果MyBatis没有开启驼峰映射查询结果里这个字段就是null。这是管理系统项目里出现频率最高的问题。解决办法是在application.yml中开启驼峰映射开关mybatis: configuration: map-underscore-to-camel-case: true如果用了MyBatis-Plus这个功能默认是开的但原生MyBatis必须手动配。如果你已经配了还是null检查一下XML的resultType如果返回的是Map而不是实体类那实体类的格式转换就不会生效。7.2 坑二时间差8小时这个坑几乎是必踩。页面显示电影场次时间是晚上20:00数据库里存的却是中午12:00前后端和数据库中总有一个差8个小时。产生原因有三层数据库连接时区没设对、JSON序列化时区没设对、前端本地时间解析时区没设对。最省心的方案是数据库url带上serverTimezoneAsia/Shanghai后端在实体类的LocalDateTime字段上不额外配置SpringBoot默认按ISO格式输出前端用日期库plus处理时固定用dayjs()并手动指定不使用UTC。三层统一用东八区问题就消失了。7.3 坑三前端请求报跨域但同时CORS和后端代理都配了好多同学前后端都配置了跨域处理结果反而因为代理标记冲突请求失败。记住一个原则开发环境用Vite/VueCLI代理生产环境用Nginx反向代理二者选一个就够了。如果后端再配置CrossOrigin或全局CORS等于双重处理反而可能出现预请求失败。如果你用的是代理方案前端请求的baseURL就写相对路径/api后端不要加额外的CORS配置。如果图省事想在后端CORS解决那前端Axios的baseURL就必须写全路径比如http://localhost:8080/api此时不要再配代理。7.4 坑四并发抢不到座位自定义锁又锁不住有个学员自己实现了一个“本地锁”方案在Java代码里用synchronized块包住查座和插座的逻辑结果测试时发现完全没用——因为SpringBoot是多实例部署或者业务代码分布在不同事务边界里的情况下本地锁根本锁不住分布式场景。而且即便是单机多线程synchronized锁住的是JVM内部多线程同时进来依然会穿透MyBatis的一级缓存直达数据库。不要自造锁方案直接依赖数据库唯一索引配合DuplicateKeyException捕获这是最简单也最可靠的方案。不要把简单问题复杂化。7.5 坑五图片上传到本地后刷新就没了管理端上传电影海报时有些人把文件写到项目根目录下的uploads文件夹结果重新打包部署或者浏览器重新请求后图片404了。原因是打成的jar包是一个压缩包运行时内部文件不能随意写。稳妥的处理方式有两种。一是配置一个本地磁盘绝对路径作为图片存储目录比如/data/cinema/upload/后端通过一个/files/**的映射暴露出来二是直接用云存储或图床对象存储的地址。小项目用第一种就够了但一定要保证上传路径和访问路径指向的是同一个磁盘位置不要写在jar内部目录里。这个坑贯穿了从删库到交付的全过程每次都有人栽在这里。8. 从这套系统里我能带走的经验做完这个影院系统我最大的感受是它不是一个“看完就会”的架子而是一块绝佳的试金石。它把真实业务系统中三件最常考的事浓缩到了一起——数据建模、权限控制、并发下的数据一致性。在第一个项目里就想明白这三件事后面做任何管理系统类项目都会顺手很多。如果你打算拿这套系统参加答辩建议在介绍时不要只讲“我实现了什么”而是多讲“我为什么这么设计”。比如订单和座位为什么要拆表为什么用唯一索引做兜底而不是依赖Java代码手写判断为什么前端要有路由守卫而后端依然必须有拦截器。把这些设计理由讲清楚评委听到的不是一个“会写CRUD的学生”而是一个“会做工程决策的开发者”。如果在开发过程中卡在某一步超过半天停下来检查是不是前面某个设计环节出了问题。绝大多数进展缓慢不是代码写得差而是表和接口之间的契约没定义清楚。先把接口字段列出来再把每个状态列出来再动手写速度反而快得多。
