软件工程关注的不只是写代码，还包括需求、设计、测试、部署、维护和协作。
SDLC
软件开发生命周期通常包括：
- 规划
- 需求分析
- 设计
- 开发
- 测试
- 部署
- 维护
常见模型包括瀑布模型、迭代模型、敏捷开发和 DevOps。
DevOps
DevOps 强调开发与运维协作，目标是更快、更稳定地交付软件。
核心概念：
- CI：持续集成
- CD：持续交付/部署
- IaC：基础设施即代码
- 监控与日志
- 自动化测试
OOP
面向对象的核心是封装、继承和多态。
封装隐藏内部实现；继承复用和扩展能力；多态让同一接口有不同实现。
SOLID
SOLID 五大原则：
- 单一职责
- 开闭原则
- 里氏替换
- 接口隔离
- 依赖倒置
这些原则的目标是降低耦合、提升可维护性。
设计模式
常见模式：
- Singleton：单例
- Factory：简单工厂
- Factory Method：工厂方法
- Adapter：适配器
- State：状态
- Strategy：策略
设计模式不是为了炫技，而是为了解决重复出现的结构性问题。
延伸理解
复习这篇时，不要只记住名词，要把重点放在 SDLC、DevOps、OOP、SOLID、设计模式和工程协作质量。这类知识如果只停留在定义层面，很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景：谁在调用它，输入从哪里来，失败后谁负责恢复，数据或状态会不会被重复处理。
- 软件工程不是概念集合，而是让需求、设计、实现、测试、发布和维护形成可持续闭环。
- 原则和模式只有在降低复杂度时才有价值，不能为了使用设计模式而引入抽象。
- 好的工程笔记应该能回答：为什么这样设计、替代方案是什么、失败后如何恢复。
在真实项目中，可以把它当成一个判断框架：先确认输入、约束、失败场景和可观测性，再决定具体工具或写法。 如果一个方案看起来很简单，要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。
实践检查清单
- 明确这个知识点在系统中的位置：是开发时约束、运行时能力、基础设施能力，还是协作流程。
- 写出一个最小可运行例子，并补一个失败例子；只会写 happy path 说明理解还不够稳。
- 记录常见误用：例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
- 把概念和项目经历关联起来：如果面试被追问，可以用自己的项目说明为什么这样选。
- 最后用一句话总结取舍：它牺牲了什么，换来了什么。
自测问题
- 这个主题解决的核心问题是什么？
- 如果不用当前方案，还有哪些替代方案？代价是什么？
- 最容易出错的边界条件在哪里？
- 如何在代码、测试或监控中验证它真的可靠？
项目化应用场景
可以把这类知识放到一个团队协作项目里理解：需求先被拆成可交付任务，代码通过分支和 PR 合并，测试保护关键行为，发布前有检查清单，线上问题能通过日志和监控定位。SOLID 和设计模式不是为了让代码看起来高级，而是为了让变化发生时影响范围更小。任何抽象都应该能解释它减少了哪类重复或复杂度。
常见误区：
- 为了模式而模式，增加不必要抽象。
- 没有测试就重构共享逻辑。
- 需求、实现和发布之间没有反馈闭环。