L12·10^20 – 10^23

软件工程

Software Engineering

核心抽象协作与演化

当代码量大到一个人写不完,测试、重构、CI/CD 成为生存工具。

学习进度:
What

软件工程是将系统化、可量化方法应用于软件开发、运维和演化的学科。核心实践包括:版本控制(Git,分支策略如 Git Flow / Trunk-Based)、代码评审(Code Review,知识共享和质量把关)、测试金字塔(单元测试→集成测试→端到端测试)、持续集成/持续交付(CI/CD,自动化构建-测试-部署流水线)、重构(在不改变外部行为的前提下改善内部结构)、设计模式(可复用的面向对象设计方案,如工厂、策略、观察者)。架构模式包括分层架构、微服务架构、事件驱动架构、六边形架构。技术债务(Technical Debt)是为短期收益牺牲长期质量的代价。

Why

单个程序员可以写出几百行的程序,但现代软件系统通常有数十万到数百万行代码,由数十到数千名开发者协作完成。没有工程实践,代码会迅速腐化——重复代码增加、模块耦合加深、测试覆盖下降、部署变成噩梦。软件工程提供方法论和工具,使大型团队能在长期内持续交付高质量软件。版本控制使多人协作成为可能;自动化测试防止回归;CI/CD 使发布变得可预测和低风险。

How

程序员日常使用这些实践:git commit/push/pull 管理代码变更;PR/MR 进行代码评审;编写单元测试和集成测试;通过 Jenkins/GitHub Actions/GitLab CI 触发自动化流水线;使用 IDE 重构工具改善代码结构。理解软件工程有助于理解:为什么代码评审能减少 bug(多人视角);为什么测试覆盖率重要但不充分(测试质量同样重要);为什么小步发布比大版本更安全(减少风险);为什么技术债务需要持续偿还(否则利息越来越高)。

Bottom-up:由下层如何构建

本层建立在以下层级之上:

Top-down:向上暴露什么接口

版本控制测试CI/CD设计模式

Programmer View:程序员视角

我能操作吗?

直接操作。Git 管理代码变更,IDE 支持重构,测试框架(JUnit/pytest/Jest)编写测试,CI/CD 工具(GitHub Actions/Jenkins)自动化流水线。

成本模型

指标量级备注
代码评审时间~1-4 小时/PR取决于 PR 大小,建议 <400 行
单元测试执行毫秒到秒级/测试快速反馈是单元测试的核心价值
CI/CD 流水线5-30 分钟取决于构建复杂度和测试套件
部署频率每日到每周高频部署团队可达每日数次

常见陷阱

  • !技术债务累积:为赶进度写的'临时方案'如果不清理,会变成永久问题。应定期安排重构迭代
  • !测试反模式:测试过于依赖实现细节(而非行为)导致频繁失败;测试间有依赖导致不稳定(Flaky Test)
  • !过度流程:过多的审批环节和文档要求会降低开发速度。应在流程控制和开发效率间找到平衡