1、把 35 课串成一条线前面 35 课，我们像拆零件一样，把软件生命周期的每一环都讲了一遍。但真实的项目不是按课本章节顺序发生的——它是交织的、迭代的、充满取舍的。这最后一课，我们用一个完整的虚构案例，把六阶段从头到尾走一遍，看看这些知识在实际中怎么串起来用。这也是全课程的收束。2、案例背景：校园二手交易平台 "CampusTrade"项目：校园二手交易平台 CampusTrade 团队：3 …

1、"这个系统早该关了，但没人敢关"公司里常有这么一套"僵尸系统"：五年前的老后台，界面丑陋、文档全无，但还有几个老客户在用，还连着几个下游接口，还有定时任务在跑。没人想维护它，也没人敢关它。系统退役（Decommissioning / Sunsetting） 是生命周期的最后一环，也是最容易被忽视的一环。本课讲：怎么安全、体面地"送走"一个系统。2、退役不是"关机"，是一场手术为什么不能直接 …

1、代码能回滚，数据不能一次发布：新版本把 user.name 拆成了 first_name + last_name，代码写得漂漂亮亮。上线后发现问题，回滚——新版本已经把 1000 条数据写成了新格式，旧代码读不懂了。服务彻底瘫痪。应用代码可以回滚，数据库变更往往"覆水难收"。 这使得数据库演进（Database Evolution）成为发布中最危险、最需要谨慎的一环。本课专门讲它。2、为什 …

1、为什么要"体面地"送走一个系统从第 1 课到现在，我们走完了一个软件的整条生命线：立项 → 需求 → 设计 → 开发 → 测试 → 交付 → 运维 → 维护。而每一条生命线都有终点。终点的形式有很多：被新系统取代（重构重写、架构升级）；业务被砍掉（战略调整、产品合并）；技术被淘汰（框架停止维护、平台关停）;干脆是寿终正寝（完成了历史使命）。很多团队的失败，不是失败在"上线"，而是失败在"下 …

1、上线不是终点，安全是持续的过程第 23 课我们讲过"性能与安全测试"，但那是上线前的一次性检查。上线之后呢？现实是：你依赖的某个库，今天被爆出一个高危漏洞；某个攻击手法（比如某类注入）三年前还没人用，现在已成常规武器；法规更新了，你的数据处理方式忽然不合规了。安全不是一个"做完就勾掉"的任务，而是一项需要长期维护的能力。很多团队把安全当"上线前跑一次扫描"，结果系统上线半年，依赖里躺着一堆 …

1、软件是"活"的：演进是常态前面 30 课，我们讲完了从立项、上线到长期维护的全过程。这一课换个视角：软件一旦上线，就进入了"持续演进"的长跑。看看真实世界里每天都在发生的事：用户提新需求："能不能加个批量导出？"市场在变："竞品上了协同编辑，我们有吗？"依赖在老化："这个库两年没更新了，被标记为不维护。"合规在收紧："新法规要求用户能一键删除自己的数据。"演进（Evolution）不是意外 …

1、"先这样，回头再改"——那个回头永远没来为了赶上线，你把一段逻辑硬编码进去，心里想："先能跑，回头再改。" 三个月后，这段代码扩散成了 5 个地方，没人敢改、没人记得为什么这么写，而"回头"始终没来。这就是技术债（Technical Debt）——一个由 Ward Cunningham 提出的绝妙比喻：为了短期速度而做的妥协，会在未来收取"利息"。 本课讲：什么是技术债、怎么识别、怎么还， …

1、上线之后，故事才过了一半一个软件的生命周期里，开发只占一小部分，维护才是大部分。业界的经验数据是：维护成本可能占到总成本的 60%~80%。但"维护"常被误解为"修 bug"。其实它是一个更广的概念。本课讲清维护的四种类型，以及那条著名的维护成本"微笑曲线"。2、维护的四种类型软件维护（Software Maintenance）标准分为四类：类型目的触发占比（经验值）纠错性维护修 bug用 …

1、凌晨 3 点的电话监控告警响起：支付接口错误率 100%。值班工程师睡眼惺忪地打开电脑——手在抖、脑子乱、不知道从哪查起。半小时过去了，用户还在骂，群里消息刷屏，老板在问"还有多久"。事故响应拼的不是"个人英雄主义"，而是制度、预案和冷静的流程。本课讲：事故来了怎么办（响应），事后怎么学（复盘）。2、事故分级：先定"严重度"不是所有事故都要"全员拉群、CEO 到场"。先分级：等级定义响应P …

1、上线不是终点，是起点很多人以为"代码上线"就完事了。可系统的真正考验在上线之后：它要一天 24 小时运行、要面对真实流量、会悄悄退化、会半夜出故障。运维不是"给服务器续命"，而是"让系统持续健康地服务用户"。 本课讲运维的核心：可观测性（日志/指标/链路）、告警设计、以及SLO 与错误预算。2、可观测性三大支柱系统出问题时，你需要"看见内部发生了什么"。靠三样东西：支柱回答什么例子日志（L …