1. 从“能跑就行”到“可交付”：开发阶段到底在解决什么问题

很多人第一次接触软件工程导论，看到“开发阶段”这四个字，脑子里浮现的画面就是一群人坐在电脑前敲代码。如果你也这么想，那这门课大概率会学得很痛苦，因为考试和实际项目里真正拉开差距的，恰恰是那些“代码之外”的东西。我带过几届课程设计，也参与过几个校企合作项目的评审，发现一个很普遍的现象：学生团队在需求分析阶段做得有模有样，文档写得漂漂亮亮，一到开发阶段就原形毕露——进度失控、模块对不上、改一处崩三处。问题出在哪？出在大家把“开发”等同于“写代码”，而忽略了它本质上是一个把设计蓝图转化为可运行、可验证、可维护的软件实体的系统工程过程。

软件系统的开发阶段，在整个软件生命周期里处于一个承上启下的位置。上游是需求分析和概要设计，下游是测试和维护。它的核心任务不是“把功能做出来”这么简单，而是要在时间、成本、质量这三个约束条件下，把设计文档里的抽象描述变成实实在在的代码、数据库脚本、配置文件、接口文档和部署包。换句话说，开发阶段要交付的不是“我觉得能跑”的程序，而是一个别人能看懂、能接手、能部署、能扩展的软件产品。

这个阶段适合谁来深入理解？如果你是软件工程、计算机科学相关专业的学生，这是你课程设计和毕业设计能否顺利推进的关键；如果你刚入行做开发，理解开发阶段的工程化思维能让你从“码农”往“工程师”方向走；如果你是项目负责人或技术组长，这部分内容直接关系到你怎么拆任务、控进度、保质量。我见过太多团队在开发阶段靠“人肉堆时间”硬扛，最后交付的东西连自己都不想维护，根源就是没有把开发阶段当成一个需要精心组织的工程过程来对待。

接下来我会从开发阶段的核心任务拆解、主流开发模型的选择逻辑、模块划分与接口约定的实操方法、编码规范与代码审查的落地技巧、版本控制与持续集成的工程实践，以及开发阶段最常见的几个坑和排查思路这几个维度，把这件事讲透。每个部分我都会结合课程设计和实际项目里反复出现的场景来说明，尽量让你看完就能用到自己的项目里。

2. 开发阶段的核心任务拆解：不只是写代码

2.1 编码实现：从设计文档到可执行代码的翻译过程

编码实现是开发阶段最直观的任务，但它的难点不在于“写”，而在于“翻译”。概要设计文档里写的是“系统分为用户管理、订单处理、支付结算三个模块”，详细设计文档里写的是“订单处理模块包含订单创建、订单查询、订单状态流转三个子功能”，到了编码阶段，你需要把这些抽象描述变成具体的类、方法、接口和数据库表。这个翻译过程的质量，直接决定了后续测试和维护的成本。

我观察到一个很典型的现象：新手在编码时容易陷入“功能导向”思维，就是只关心这个功能能不能跑通，不关心代码结构是否合理。比如做一个订单创建功能，他会在一个方法里把参数校验、库存扣减、订单入库、日志记录全塞进去，两百行代码一气呵成。功能确实能跑，但等到要加一个“下单前先检查用户优惠券”的需求时，他就懵了——改哪里？怎么改？改完会不会影响库存扣减？这就是典型的“能跑就行”思维带来的技术债。

正确的做法是在编码前先做一次模块内设计。还是以订单创建为例，你应该先想清楚：参数校验是独立的一层，库存扣减应该封装成服务方法，订单入库是数据访问层的职责，日志记录可以用切面统一处理。这样拆完之后，每个方法只做一件事，加需求时只需要在对应的层里扩展，不会牵一发动全身。这个思路其实就是软件工程里常说的“高内聚、低耦合”，但很多人在赶进度的时候会把它抛到脑后。

提示：编码阶段最容易被忽略的一件事是“写注释”。不是那种“i++ // i加1”的废话注释，而是说明“这个方法为什么需要加分布式锁”“这个字段为什么用字符串而不是枚举”这类决策背景。三个月后回头看代码的人，很可能就是你自己。

2.2 单元测试：开发者的第一道质量防线

单元测试在课程设计里经常被当成“额外负担”，很多人觉得“我手动点一下页面不就知道对不对了吗”。这种想法在小型Demo里勉强能混过去，但一旦模块多起来、依赖关系复杂起来，手动测试的覆盖率根本跟不上。单元测试的核心价值不是“证明代码是对的”，而是“在改代码的时候能快速知道有没有改坏东西”。

我一般建议在开发阶段至少做到两件事：第一，核心业务逻辑的方法必须有单元测试，比如金额计算、状态流转、权限判断这些；第二，每次修完Bug之后，补一个能复现该Bug的测试用例。第二点特别重要，因为很多Bug会反复出现，有了测试用例之后，下次再改相关代码时，跑一遍测试就能确认没有回归。

写单元测试时最容易踩的坑是“测试依赖外部环境”。比如测试一个查询方法，直接连真实数据库，结果测试跑得慢不说，还经常因为数据被其他测试改掉而失败。正确的做法是用Mock对象隔离外部依赖，让单元测试只关注当前方法的逻辑。这个习惯在课程设计阶段可能看不出多大好处，但到了实际工作中，一个能快速跑完的测试套件能帮你省下大量调试时间。

2.3 代码审查：把问题拦在合并之前

代码审查（Code Review）是开发阶段另一个容易被形式化的环节。很多团队的做法是“提交前随便看一眼，点个通过”，这等于没做。真正有效的代码审查应该关注三件事：逻辑正确性、边界条件处理、代码可读性。

逻辑正确性不用多说，就是看代码有没有实现设计文档里描述的功能。边界条件处理是新手最容易漏的，比如空值、零值、超长字符串、并发访问这些场景。我见过一个课程设计项目，用户注册功能在正常输入下没问题，但输入一个超长用户名就直接数据库报错，这就是典型的边界条件没考虑。代码可读性则关系到后续维护成本，变量命名是否清晰、方法职责是否单一、注释是否到位，这些在审查时都应该关注。

代码审查的节奏也很重要。我建议每次审查的代码量不要超过400行，超过这个量级审查质量会急剧下降。另外，审查意见要具体，不要只说“这里有问题”，要说“这里在用户名为空时会抛空指针，建议加一个前置判断”。这样提交者才知道怎么改，而不是反复猜你的意思。

2.4 构建与部署脚本：让“在我电脑上能跑”成为过去式

“在我电脑上能跑”是开发阶段最经典的甩锅语录。这个问题的根源是开发环境和运行环境不一致，依赖版本不同、配置文件不同、环境变量不同。解决这个问题的标准做法是把构建和部署过程脚本化、自动化。

具体来说，你需要做到：所有依赖用包管理工具声明（比如Java用Maven或Gradle，Python用pip或poetry，前端用npm或yarn），配置文件按环境分离（开发、测试、生产各一套），构建过程用脚本一键完成。这样任何人拿到代码后，只需要执行一条命令就能把项目跑起来，而不是对着README里的十几步手动操作一步步折腾。

我在评审课程设计时经常看到README里写着“先安装XX，再配置YY，然后修改ZZ文件里的路径”，这种项目基本可以判定工程化程度不及格。正确的做法是把这些步骤全部写进构建脚本里，让机器去执行，而不是让人去记忆。

3. 开发模型的选择逻辑：瀑布、迭代还是敏捷

3.1 瀑布模型：适合需求稳定的场景

瀑布模型是最经典的开发模型，把开发阶段严格划分为编码、测试、集成等步骤，每个步骤完成后才进入下一个。它的优点是阶段清晰、文档齐全、便于管理，缺点是对需求变化的适应能力极差。一旦在编码阶段发现设计有问题，往回改的成本非常高。

那瀑布模型是不是就一无是处？也不是。如果你的项目需求非常明确且稳定，比如做一个课程设计里的图书管理系统，功能就是增删改查加统计报表，需求不会中途大变，那瀑布模型完全够用，而且阶段划分清晰，适合学生团队按部就班推进。我一般建议课程设计项目如果周期在两个月以内、需求明确，就用瀑布模型，把编码阶段集中在一到两周内完成，剩下的时间留给测试和文档。

3.2 迭代模型：把大目标拆成小版本

迭代模型的核心思想是“分批次交付”。不是等所有功能都开发完才交付，而是先做一个能跑通核心流程的版本，然后再迭代增加功能。比如做一个电商系统，第一个迭代只做用户注册登录和商品展示，第二个迭代加购物车和下单，第三个迭代加支付和订单管理。每个迭代结束时都有一个可运行的版本，这样即使中途需求有变化，调整的成本也相对可控。

迭代模型在开发阶段的关键是版本规划。你需要明确每个迭代要交付哪些功能、优先级怎么排、迭代周期多长。我一般建议课程设计项目把迭代周期定在一到两周，太短了做不出东西，太长了反馈不及时。另外，每个迭代结束时一定要做一次演示和回顾，确认做出来的东西是不是想要的，避免方向跑偏。

3.3 敏捷开发：小步快跑，拥抱变化

敏捷开发是现在业界最主流的开发模式，核心是快速响应变化、持续交付价值。它和迭代模型有相似之处，但更强调短周期、自组织团队和客户协作。敏捷开发里有很多具体实践，比如每日站会、看板管理、结对编程、持续集成等。

对于学生团队来说，完全照搬敏捷开发可能不太现实，因为敏捷对团队成熟度和客户参与度要求很高。但敏捷里的一些实践是可以借鉴的，比如每日站会（每天花五分钟同步进度和问题）、看板管理（把任务贴在墙上或看板上，谁做什么一目了然）、持续集成（每次提交代码都自动构建和测试）。这些实践能显著提升开发阶段的透明度和协作效率。

3.4 模型选择的核心判断依据

到底选哪个模型，不要拍脑袋决定，可以从三个维度来判断：需求稳定性、团队规模和项目周期。需求越不稳定，越应该选迭代或敏捷；团队越大，越需要清晰的阶段划分和文档规范；项目周期越短，越应该选轻量级的模型。

我整理了一个简单的对照表，你可以根据自己的项目情况对号入座：

注意：模型选择不是非此即彼的，实际项目中经常是混合使用。比如整体用迭代模型，但每个迭代内部用瀑布模型来组织编码和测试。

4. 模块划分与接口约定：让并行开发成为可能

4.1 模块划分的原则与常见误区

模块划分是开发阶段开始前最重要的一件事。划分得好，大家可以并行开发、互不干扰；划分得不好，就会出现“你改了我的代码”“我等你的接口”这种互相阻塞的情况。模块划分的核心原则是高内聚、低耦合，具体来说就是：一个模块内部的功能应该紧密相关，模块之间的依赖应该尽可能少且清晰。

常见的误区是按“技术分层”来划分模块，比如所有Controller放一个模块、所有Service放一个模块、所有DAO放一个模块。这种划分方式在小型项目里问题不大，但在中大型项目里会导致一个业务功能的修改要跨多个模块，非常不方便。更好的做法是按业务领域划分模块，比如用户模块、订单模块、支付模块，每个模块内部再分层。这样修改一个业务功能时，只需要在一个模块内改动，影响范围可控。

4.2 接口约定的文档化与版本管理

接口约定是并行开发的前提。如果A负责用户模块，B负责订单模块，订单模块需要调用用户模块查询用户信息，那双方必须先约定好接口的URL、请求参数、响应格式、错误码。这个约定必须文档化，不能只是口头说说。

我推荐用接口文档工具来管理这些约定，比如Swagger或YApi。开发前先把接口定义写好，双方确认后各自开发，联调时按文档来对。这样能避免“我以为你传的是字符串，结果你传的是数字”这类低级问题。另外，接口一旦约定好就不要随意改，如果确实需要改，必须通知所有依赖方，并且做好版本管理。比如原来的接口是/api/v1/user/{id}，新接口改成/api/v2/user/{id}，老接口保留一段时间，给调用方迁移的时间。

4.3 数据库设计的评审要点

数据库设计是开发阶段另一个容易出问题的地方。很多团队在编码前不认真做数据库设计，写到哪张表就建哪张表，结果后期发现字段不够用、索引没加、关联关系混乱。我建议在开发阶段开始前，至少做一次数据库设计评审，重点检查几个方面：表结构是否满足第三范式、关键字段是否有索引、关联关系是否清晰、是否有冗余字段的必要。

第三范式简单说就是每张表只存自己该存的数据，不要存其他表的非主键字段。比如订单表里不要存用户名，只存用户ID，需要用户名时关联查询。这样做的好处是数据一致性有保障，不会出现用户改了名字但订单表里的用户名还是旧的这种情况。当然，实际项目中为了查询性能，有时候会故意冗余一些字段，但这是有意识的权衡，不是设计疏忽。

4.4 并行开发的协调机制

模块划分和接口约定做好之后，理论上大家可以并行开发了。但实际过程中还是会有各种协调问题，比如某个接口的实现比预期复杂，导致依赖方等不及；或者某个模块的Bug影响了其他模块的测试。这时候需要一套协调机制。

我一般建议做两件事：第一，每日同步进度和阻塞点，可以用站会的形式，每个人说昨天做了什么、今天打算做什么、有没有被卡住；第二，建立Mock服务，对于还没实现完的接口，先提供一个Mock返回假数据，让依赖方可以继续开发和测试，不用干等。这两件事看起来简单，但能显著减少开发阶段的等待和返工。

5. 编码规范与代码审查的落地方法

5.1 编码规范：统一风格比追求完美更重要

编码规范这件事，很多团队要么不做，要么做得太复杂。我见过一个团队搞了一份五十页的编码规范文档，结果没人看，代码风格还是五花八门。其实编码规范的核心不是“写出完美的代码”，而是“让团队成员的代码风格统一”，这样互相看代码时不会因为风格差异而分心。

我建议编码规范只规定最关键的几条：命名规则（类名用大驼峰、方法名用小驼峰、常量全大写）、缩进和换行规则、注释要求、异常处理方式。其他的比如用不用final、用不用var，可以交给代码格式化工具去统一。现在主流的IDE都支持代码格式化配置，团队共享一份配置文件，提交前自动格式化，比写一堆规范文档管用得多。

5.2 代码审查的流程与关注点

代码审查的流程一般是：开发者提交合并请求（Merge Request），审查者查看代码并给出意见，开发者根据意见修改，审查者确认后合并。这个流程看起来简单，但实际执行时容易走样。最常见的问题是审查者只看“代码能不能跑”，不看“代码写得好不好”。

我在做代码审查时会重点关注几个方面：方法职责是否单一、边界条件是否处理、异常是否被吞掉、日志是否合理、是否有重复代码。方法职责单一前面说过了，边界条件也是老生常谈。异常被吞掉是新手常犯的错误，比如try { ... } catch (Exception e) { }，出了问题连日志都没有，排查起来非常痛苦。日志要合理是指关键操作要有日志，但不要打太多无意义的日志，否则日志文件会爆炸。重复代码则是代码坏味道的典型信号，看到重复代码就应该考虑抽取公共方法。

5.3 静态代码分析工具的使用

人工审查毕竟精力有限，很多低级问题可以交给静态代码分析工具去发现。Java生态里有CheckStyle、PMD、SpotBugs，Python有Pylint、Flake8，前端有ESLint。这些工具能自动检查代码风格、潜在Bug、安全漏洞等问题，集成到构建流程里，每次提交代码时自动跑一遍，不通过就不让合并。

我建议在课程设计项目里至少配一个静态分析工具，不用追求零告警，但至少要把严重级别的告警处理掉。这样能帮你养成好的编码习惯，也能让代码审查的精力集中在逻辑和设计层面，而不是纠结命名和格式。

5.4 代码审查中的沟通技巧

代码审查本质上是一种技术沟通，沟通方式直接影响效果。我见过一些审查者喜欢用命令式语气，比如“这里必须改成XXX”，这种语气容易引起抵触情绪。更好的方式是提问式，比如“这里如果传入空值会怎么样？”或者建议式，“这里可以考虑用XXX方式，你觉得呢？”

另外，审查意见要区分优先级。有些是必须改的（比如逻辑错误、安全问题），有些是建议改的（比如命名可以更清晰），有些是个人偏好（比如用不用某种语法糖）。审查者应该明确标注哪些是阻塞性问题，哪些是可选建议，这样开发者知道哪些必须处理，哪些可以讨论。

6. 版本控制与持续集成的工程实践

6.1 分支管理策略：Git Flow还是Trunk-Based

版本控制是开发阶段的基础设施，但很多团队只用到了最基础的功能——提交和拉取。分支管理策略决定了团队协作的效率和代码的稳定性。常见的策略有Git Flow和Trunk-Based两种。

Git Flow的核心是维护两条长期分支（master和develop）和三条短期分支（feature、release、hotfix）。功能开发在feature分支上进行，完成后合并到develop；发布时从develop拉出release分支，测试通过后合并到master。这种策略适合版本发布周期较长的项目，比如课程设计这种有明确交付节点的。

Trunk-Based的核心是所有人都在一条主干分支上开发，功能通过特性开关控制是否上线。这种策略适合持续交付的互联网产品，但对团队的自动化测试和部署能力要求很高。对于学生团队，我一般建议用简化版的Git Flow：master分支存放稳定版本，develop分支用于日常开发，每个功能开一个feature分支，完成后合并到develop。

6.2 提交信息的规范与价值

提交信息（Commit Message）是很多人忽略的一个细节。我见过大量提交信息写着“修改”“更新”“fix bug”这种毫无信息量的内容。等到需要回溯某个改动时，根本不知道哪个提交做了什么。规范的提交信息应该包含三部分：类型、范围、描述。比如feat(order): 增加订单取消功能，类型是feat（新功能），范围是order（订单模块），描述是增加订单取消功能。

这样做的好处是，你可以用工具自动生成变更日志（Changelog），也可以快速筛选出某类提交。比如要发版了，把所有feat类型的提交列出来，就是本次版本的新功能列表。这个习惯在课程设计里可能看不出多大价值，但到了工作中，一个清晰的提交历史能帮你省下大量排查时间。

6.3 持续集成的搭建与维护

持续集成（CI）的核心是“每次提交都自动构建和测试”。这样做的好处是问题发现得早，不会等到集成时才爆出一堆冲突和Bug。搭建CI的基本步骤是：选择一个CI工具（比如Jenkins、GitLab CI、GitHub Actions），配置构建脚本，设置触发条件（比如每次推送到develop分支时触发），配置构建成功或失败的通知。

对于课程设计项目，我建议至少做到“每次提交自动编译和跑单元测试”。如果单元测试覆盖率不高，至少保证编译通过。这样能避免“提交了编译不过的代码”这种低级问题。另外，CI的构建结果要公开可见，比如在群里发通知或者在项目看板上展示构建状态，让所有人都知道当前代码的健康状况。

6.4 构建失败的处理流程

CI构建失败是开发阶段的常态，关键是怎么处理。我见过一些团队构建失败了没人管，红了一整天也没人修，这样CI就形同虚设了。正确的做法是：构建失败后，第一时间修复，修复之前不合并新的代码。这条规则听起来简单，但执行起来需要团队有共识。

如果构建失败的原因一时半会儿查不出来，可以先回滚到上一个成功的版本，保证主干分支始终是可构建的。然后在一个独立的分支上排查问题，找到原因后再重新提交。这样能避免因为一个构建失败阻塞所有人的开发进度。

7. 开发阶段最容易踩的五个坑与排查思路

7.1 进度失控：为什么总是前松后紧

进度失控是开发阶段最普遍的问题。典型的表现是：前两周大家觉得时间还多，慢慢做；第三周发现做不完了，开始加班赶工；最后一周疯狂堆代码，质量一塌糊涂。这个问题的根源是任务拆解不够细、进度跟踪不够频繁。

解决思路是把开发任务拆到“天”级别，每个任务不超过一天的工作量。然后每天同步一次进度，看看实际进度和计划进度的偏差。如果发现某个任务比预期多花了两天，就要及时调整计划，要么砍功能，要么加人手，而不是等到最后才发现来不及。我在课程设计里一般建议用看板管理任务，每个任务一张卡片，从“待开发”移到“开发中”再移到“已完成”，进度一目了然。

7.2 接口对不上：联调时的经典翻车现场

接口对不上是并行开发时最常见的问题。A以为B传的是JSON，B以为A传的是表单；A以为返回的是数组，B以为返回的是对象。联调时一跑，全是错。这个问题的根源是接口约定没有文档化，或者文档更新不及时。

解决思路前面说过，用接口文档工具管理约定，开发前双方确认。另外，联调时不要等到所有功能都开发完才开始，应该尽早联调。比如用户模块和订单模块的接口约定好了，用户模块先实现一个最简单的版本，订单模块就可以开始联调了，不用等用户模块所有功能都做完。早联调早发现问题，修复成本也低。

7.3 改一处崩三处：回归Bug的排查与预防

回归Bug是指修改一个功能时，意外破坏了另一个功能。这个问题的根源通常是模块之间耦合太紧，或者缺少回归测试。比如订单模块直接依赖了用户模块的内部数据结构，用户模块一改，订单模块就崩了。

预防回归Bug的核心手段是单元测试和集成测试。每次修改代码后，跑一遍测试套件，如果测试通过，说明没有破坏已有功能。另外，模块之间要通过接口交互，不要直接访问对方的内部数据。接口是稳定的契约，内部实现可以变，只要接口不变，调用方就不受影响。

7.4 环境不一致：本地能跑服务器跑不了

环境不一致的问题前面提过，根源是依赖和配置没有统一管理。排查这个问题的思路是：先确认本地和服务器的依赖版本是否一致，再确认配置文件是否一致，最后确认环境变量是否一致。我一般建议用容器化技术（比如Docker）来统一环境，把应用和依赖打包成一个镜像，本地和服务器跑同一个镜像，环境差异问题基本就消失了。

如果不用容器，至少要做到依赖用包管理工具声明、配置文件按环境分离、部署脚本自动化。这样即使环境有差异，也能快速定位是哪个环节的问题。

7.5 技术债累积：什么时候该重构

技术债是指为了赶进度而做出的妥协，比如硬编码、重复代码、临时方案。技术债不是不能欠，但要控制规模，及时偿还。如果技术债累积太多，后续开发会越来越慢，Bug越来越多，最后陷入“改不动”的困境。

判断什么时候该重构，我一般看两个信号：修改一个功能需要改多个地方，或者新增一个功能需要复制大量代码。出现这两个信号时，说明代码结构已经不合理了，应该安排时间重构。重构不是重写，而是在不改变外部行为的前提下，调整内部结构。重构时要有测试保护，确保重构后功能不变。

8. 从开发阶段到可交付状态：我的一些经验体会

开发阶段做得好不好，最终体现在交付物上。一个合格的交付物应该包含：可运行的代码、完整的构建脚本、清晰的部署文档、通过测试的证明、以及必要的用户手册。我评审过很多课程设计项目，发现一个规律：那些在开发阶段就注重工程化的团队，交付物质量普遍更高，答辩时也更有底气。

我个人在实际操作中的体会是，开发阶段最值得投入时间的三件事是：接口约定、单元测试、持续集成。接口约定做好了，并行开发不阻塞；单元测试做好了，改代码不心虚；持续集成做好了，问题发现得早。这三件事在项目初期看起来像是“额外工作”，但到了项目中后期，它们节省的时间远超投入。

另外，不要追求一步到位。开发阶段是一个渐进的过程，代码从能跑到跑得好，需要不断迭代。关键是保持代码始终处于可构建、可测试、可部署的状态，这样无论需求怎么变，你都有调整的余地。最后再分享一个小技巧：每天结束开发前，花五分钟把当天的代码提交并推送，确保第二天来的时候能接着昨天的进度继续，而不是面对一堆未提交的改动不知道从哪下手。