工程化实践
入门
这门课的目标不是“把工程化讲成理论”，而是帮你把课程项目、作品集和实习任务做成一版更像样的工程交付。你会发现，工程化最大的收益不是炫技，而是减少重复翻车、降低协作摩擦，并让后续维护变得更省力。
你将学会什么
Section titled “你将学会什么”- 建立“可运行、可维护、可协作”的项目交付习惯
- 掌握最小可用的工程化结构，避免一开始就过度设计
- 学会协作级提交习惯与合并前看 diff 的审查流程
- 管住依赖与环境边界，让项目两三条命令即可复现
- 把课程作业升级成能看懂、能复用、能展示的作品集项目
- 会用
git add、git commit、git push - 有一个能运行的课程项目或实验代码
- 建议先完成《Modern Git 进阶全攻略》
| 章节 | 内容 |
|---|---|
| 1. 最小工程结构 | 入口文件、README 与四条可运行约定 |
| 2. 协作级 Git 习惯 | 分类型提交、保持可回滚与合并前看 diff |
| 3. 依赖与环境边界 | 本地/全局依赖、最低版本记录与 .gitignore |
| 4. 从作业到作品集 | 用问题—方案—结果表达项目价值 |
| 5. 工程化取舍 | 简化与补结构的判断标准 |
学习路线建议
Section titled “学习路线建议”- 前三章解决“项目能不能被看懂、被跑起来”，后两章解决“值不值得展示、该投入多少”
- 每章末尾都有 3 道小测验，答错时解析会说明原因
课程作业要工程化到什么程度才算够？
Section titled “课程作业要工程化到什么程度才算够？”不需要一步到位。起点是四条可运行约定：入口文件说明用途、README 说清三问、命令原样可运行、配置及时清理。工程化程度的判断标准是是否降低了维护成本，而不是结构多全或文件多少。
只有我一个人写的项目，还需要 README 吗？
Section titled “只有我一个人写的项目，还需要 README 吗？”需要。README 至少回答三个问题：项目做什么、怎么跑起来、核心文件在哪。它不只是给队友看的，也给你几个月后的自己看。在最小工程结构里，README 是四条约定之一，也是把作业升级成作品集时的展示入口。
提交信息怎么写才算「协作级」？
Section titled “提交信息怎么写才算「协作级」？”先用类型前缀说明变更性质，再写清楚「为什么改」，例如 feat: 支持实验报告模板导出。功能、修复、文档修改分开提交，每条历史小而独立，回滚时只退回出问题的那一次修改。练习方法见协作级 Git 习惯。
合并队友分支前，一定要先看 diff 吗？
Section titled “合并队友分支前，一定要先看 diff 吗？”建议养成这个习惯。合并前看一次 diff 是最便宜的代码审查，能提前发现「改了不该改的文件」和「把调试代码也提交了」这类问题，避免合并后大量返工。具体做法见协作级 Git 习惯。
- 约定式提交规范（Conventional Commits）——提交信息类型与格式的官方规范，
feat:、fix:前缀的来源 - 十二要素应用（12-Factor）——面向部署与运维的应用设计方法论，依赖与环境边界的延伸参考
- 语义化版本 2.0.0（SemVer）——版本号递增规则的官方定义，记录最低版本时的参考
- semantic-release——基于规范提交自动判定版本并发布的工具
相关课程
- Modern Git 进阶全攻略
从常用工作流到提交规范，掌握团队协作必备的 Git 能力。
- 项目实战
从选题、执行到展示，建立完整项目节奏。