收尾权衡:开发周期、维护、团队、运维与五条教训¶

这一章没有新代码,只有过来人把「交付之后」摊开给你看: 依赖会老、团队要人、线上要盯。它是全书的镜子——前面每一章做的决定 (选哪个 crate、上不上缓存、 compose 还是 K8s),在这里都能看到后续的账单。 主线例子:我们的工单系统「上线一周年」——依赖 outdated、团队从 2 人涨到 8 人、第一次线上告警,本章的每一块都被这三天的事各触发一次。

1. 顶层全景¶

  开发周期:选库八问 → 依赖的生命周期六阶段 → deprecated 的平滑术
    ↓
  维护:应用依赖补丁 = 自己的义务;冻结依赖不是选项
    ↓
  管理工具:工单系统不是练习,是行业标配(我们自己写了一个)
    ↓
  团队组织:七种角色;5–10 人是上限,超出按边界拆队
    ↓
  运维:metrics(量)vs monitoring(盯);日志/指标/追踪四件套
    ↓
  五条教训:集体协作 / 巨人肩膀 / Web 长存 / Rust 标杆 / 无人支持=死

  图说:从代码到组织到运维,海拔一路升高,全是「工程」而不是「编程」。

2. 开发周期:选库是日常,依赖有寿命¶

除了写功能,开发日常里还有一摊子「元工作」,首当其中是评估库。 八问清单(第 4 章那六条军规的加强版):维护得好不好?社区多大? 文档如何?有没有好用的例子?和我们已在用的组件有没有直接集成? 依赖了什么(传递依赖)?测得充分吗?质量流水线绿不绿? 质量差异之外,更常是按这些「周边」决出胜负¹。

选了库,就接管了它的生命周期。 依赖出了漏洞,官方会打补丁—— 但补丁不会自己进你的项目,你得更新;而更新有阻力:依赖也是软件, 有自己的生命周期,不能冻结(冻结=裸奔),也不能指望旧版本被永远支持。按语义化版本,major 出破坏性变更后,旧 major 进入功能冻结—— 新特性全去新分支,安全补丁只打到「支持期」结束。「撑下去的收益小于迁移的成本」那一刻,就是这个版本的死期,你的项目必须跟着动²。

寿命参照系: 维护者很少同时撑超过两个 major; 要撑就给版本分短寿与长命(Ubuntu 半年一个大版本 + 五年支持期的 LTS 是教科书例子)³。

六阶段模型(选库时的体检表): 原型 → alpha(API 不稳、随时破) → beta/MVP/GA(功能全、待用户打磨) → release(生产可用——开发者只用第 3 到第 5 阶段之间的组件) → 维护模式(只修安全洞,新项目别用) → EOL(停止一切更新;开源的还能 fork 续命,否则等于死了)⁴。

deprecated 标记: 大版本之前,把将遭破坏的 API 标 deprecated—— 仍可用、已排期淘汰,并常伴一个替代 API 双轨并行。「目标是铺平迁往下一 major 的路,让开发者体验无缝。」⁵

3. 维护:一场不能辞职的义务¶

维护 = 给依赖打补丁 + 修自己代码里的 bug 和漏洞;团队必须为此常年 dedicate 一部分时间。 「任何团队都可以决定忽视这些职责—— 代价是严重漏洞和软件质量的显著滑坡。」这句话没有修辞,就是字面意思⁶。

4. 管理工具:我们自己写的就是行业标准¶

工单(ticketing)就是行业管理开发的通用答案——名单:Bugzilla (Mozilla 出身、开源)、Jira(事实标准;「Go-Jira」即哥斯拉的梗)、 ClickUp、monday dev、Asana、Zoho Projects。 书里那个温柔的闭环:本书开发的工单系统本身,就该拿来管本书没写完的 todo——「这是最真实的开发者体验。」⁷

5. 团队组织:七种角色与 5–10 人的天花板¶

角色	干什么
软件架构师	初始架构、平台与组件挑战、技术视角监督
开发工程师	写代码、参与技术讨论;再分后端/前端
项目经理/Product Owner	组织事务、传达产品目标、排优先级、保证透明
业务分析师	从数据侧做组织:洞察、瓶颈、功能与非功能需求、流程改进
团队 lead	团队层面的问题、知识共享、技术引导、沟通促进
UX 设计	体验、可用性、观感
QA 工程师	会写会跑的专职测试

规模经验值:5–10 人,别再多;超过就按架构或功能边界拆成两个小队 (前后端、基础设施-功能、对外-对内都是现成的拆法)。角色可以一人多兼、可以跨队半职共享——但心里要有这张清单, bottlenecks 出现时才知道缺的是什么⁸。

6. 运维:量(me metrics)与盯(monitoring)¶

两个相关但不同的子域: metrics/analytics = 测量性能指标、分析数据流与吞吐、找瓶颈;monitoring = 持续盯执行、出事及时告警。 后者靠前者的数据吃饭,同时给前者提供干净的洞察界面⁹。

落到活上:日志要收集+索引成可搜索(查个案)、负载要在撞墙之前介入;告警设在错误日志、高负载/低吞吐、内存/磁盘水位上; K8s 的健康检查(第 9 章)就是这套逻辑的编排器版¹⁰。

上线前的四件套: Elastic Stack(日志聚合/索引/分析,ELK)、 Prometheus(指标采集与告警)、Grafana(仪表盘可视化)、 OpenTelemetry(metrics/logs/traces 三合一的采集标准)。「部署后、活动期间、事故时——它们是开发者最好的朋友。」¹¹

7. 主线例子走一遍:上线一周年的三天¶

  第一天:cargo outdated 扫出三个库过了维护期
      │  ① 六阶段体检:一个在维护模式(只修洞)、一个已 EOL(列迁移计划)
      ▼
  第二天:团队从 2 人涨到 8 人,站会开始拥堵
      │  ② 5–10 人天花板触发:按「对外功能/内部平台」拆成两队;
      │     缺的 UX 与 QA 角色先由开发者兼任,写进招聘清单
      ▼
  第三天:凌晨 Pager 响——磁盘水位告警
      │  ③ Grafana 面板确认 Postgres  WAL 堆积;Prometheus 的告警规则立功
      ▼
  复盘进工单系统(我们自己的),优先级由 PO 排——开发周期、维护、
  管理工具、团队、运维,五块被一个真实事件全部点亮。

  图说:本章没有一行新代码,但每块都在这三天的某个小时里被用到。
  (事件经过为演示编的;工具名、角色表、六阶段出自原文。)

8. 五条教训(原书标题原样收)¶

开发是集体的努力(collective endeavor): 可以一个人起步, 但最佳结局需要协作;团队里每个人的最低义务是把信息透明出去—— 「你给了对的人对的信息,就是给了他们做对决定的能力」¹²。
站在巨人的肩膀上: 软件永远盖在既有软件之上(OS、库、crate、语言)—— 组合、remix、发布,每个人都在给行业添砖¹³。
Web 开发不会退场: 新平台出现时编程会短暂变简单,随后功能膨胀、与既有系统互联的需求回归——新技术的第一张牌几乎总是 web 服务¹⁴。
Rust 立下了安全与性能的标杆: 它用「不妥协」的做法震动了整个行业, 其他语言不得不跟进;哪怕你不用 Rust,也该拿它当比较基准¹⁵。
没人支持的软件等于死了: 谁没遇过「完美的库,最后更新在三年前, 已经编译不过」?「我们躲开这样的库,也应该从中吸取教训: 如果我们停止支持自己的软件,等待它的就是同一个命运」—— 用开源就准备接受社区贡献,有活社区比什么都强¹⁶。

9. 作者的判断与证据(分开标)¶

有出处的: 八问清单、六阶段模型、deprecated 机制、5–10 人上限、 metrics/monitoring 之分、四件套,均为原书原文或行业通行¹⁴⁵⁸⁹¹¹。

作者自己的评估:

「只用第 3–5 阶段的组件」是保守取向(初创项目常常不得不用 alpha 库, 第 13 章的 openai crate 就是——作者自己的两章打了个有趣的架);
五条教训是立场宣言,不是论证;
「自己写的工单系统管自己的 todo」是教学闭环的设计,也是真诚的推荐⁷。

10. 边界与局限¶

可观测性只有导览: 具体怎么在 Axum 里埋 tracing/metrics 端点, 本书没有实操(第 6 章的测试章节也没接覆盖率回传);
团队角色按传统软件公司画: 远程/开源协作的异步文化没展开;
成本与合规只字未提——真实世界的账本还有云账单和审计。

11. 可带走的¶

主线例子一行走完: 依赖过期 → 六阶段体检 → 团队拆队 → 告警排障 → 复盘进自家工单系统。

选库八问背下来; 质量之外,维护度、社区、文档、集成度是常态决胜项。
依赖有寿命:六阶段(原型/alpha/beta/发布/维护/EOL); 只用第 3–5 阶段的组件。
不能冻结依赖; 支持期结束那一刻,迁移成本必然到期。
deprecated = 还能用、已排期、有替代; 看到它就开始迁。
维护是 dedicate 的时间,不是业余爱好。
团队 5–10 人封顶; 超出按架构/功能边界拆队,角色可兼不可缺。
metrics 是量,monitoring 是盯; 上线前配齐 ELK/Prometheus/Grafana/OpenTelemetry 四件套。
五条教训里最有执行力的一条:信息透明是团队成员的最低义务。
「没人支持的软件等于死了」——对你用的库和你写的库同样成立。

12. 原文地图¶

主题	原书章	原文位置
选库八问	Drawing a Balance	`text/85-fm-introduction.txt:65`(搜「maintained」)、`:86`(搜「quality pipelines」)
依赖生命周期与不能冻结	同上	`text/85-fm-introduction.txt:93`(搜「semantic versioning」)、`:93`(搜「draw the line」)、`:96`(搜「forced to migrate」)
短寿与 LTS	同上	`text/85-fm-introduction.txt:99`(搜「long-term support」)
六阶段模型	同上	`text/85-fm-introduction.txt:106`(搜「Early prototype」)、`:120`(搜「Maintenance mode」)、`:123`(搜「End of life」)
只用 3–5 阶段	同上	`text/85-fm-introduction.txt:130`(搜「between phases 3 and 5」)
deprecated 机制	同上	`text/85-fm-introduction.txt:133`(搜「scheduled for phase-out」)
维护是 dedicate 的时间	同上	`text/85-fm-introduction.txt:139`(搜「dedicate a portion」)
管理工具名单	同上	`text/85-fm-introduction.txt:149`(搜「Bugzilla」)、`:154`(搜「Jira」)、`:169`(搜「next player」)
七种角色	同上	`text/85-fm-introduction.txt:196`(搜「Software architect」)、`:219`(搜「UX design」)、`:222`(搜「Quality assurance」)
5–10 人与拆队	同上	`text/85-fm-introduction.txt:226`(搜「5-10 people」)
metrics vs monitoring	同上	`text/85-fm-introduction.txt:242`(搜「Metrics and analytics」)、`:245`(搜「Monitoring」)
告警与健康检查	同上	`text/85-fm-introduction.txt:252`(搜「alerts for errors」)
可观测四件套	同上	`text/85-fm-introduction.txt:259`(搜「Elastic Stack」)、`:262`(搜「Prometheus」)、`:265`(搜「Grafana」)、`:270`(搜「OpenTelemetry」)
教训一:集体努力	同上	`text/85-fm-introduction.txt:283`(搜「collective endeavor」)、`:286`(搜「transparency」)
教训二:巨人肩膀	同上	`text/85-fm-introduction.txt:298`(搜「built on preexisting software」)
教训三:Web 长存	同上	`text/85-fm-introduction.txt:307`(搜「web service」)
教训四:Rust 标杆	同上	`text/85-fm-introduction.txt:313`(搜「trendsetter」)
教训五:无支持=死	同上	`text/85-fm-introduction.txt:319`(搜「last updated years ago」)、`:322`(搜「living community」)
Points to remember	同上	`text/85-fm-introduction.txt:338`(搜「repository」)、`:347`(搜「Patience is key」)

出处:「Development cycle」(text/85-fm-introduction.txt:65,搜「How well is a certain library maintained」)、:61(搜「find the right one」)。 ↩↩
出处:「Development cycle」(text/85-fm-introduction.txt:93,搜「We cannot just freeze our dependencies」)、:93(搜「end of its life」)。 ↩
出处:「Development cycle」(text/85-fm-introduction.txt:99,搜「long-term support version」)。 ↩
出处:「Development cycle」(text/85-fm-introduction.txt:106,搜「Early prototype」)、:109(搜「Alpha phase」)、:114(搜「Beta/minimum viable product」)、:117(搜「Release」)、:120(搜「Maintenance mode」)、:123(搜「End of life」)。 ↩↩
出处:「Maintenance」(text/85-fm-introduction.txt:133,搜「scheduled for phase-out」)。 ↩↩
出处:「Maintenance」(text/85-fm-introduction.txt:139,搜「dedicate a portion of their time」)。 ↩
出处:「Management tools」(text/85-fm-introduction.txt:149,搜「Bugzilla」)、:154(搜「Go-Jira」)、:169(搜「next player」)。 ↩↩
出处:「Team organization」(text/85-fm-introduction.txt:196,搜「Software architect」)、:226(搜「5-10 people」)、:229(搜「identify bottlenecks」)。 ↩↩
出处:「Operational tasks」(text/85-fm-introduction.txt:242,搜「Metrics and analytics」)、:245(搜「Continuously watching」)、:249(搜「relies on the former」)。 ↩↩
出处:「Operational tasks」(text/85-fm-introduction.txt:252,搜「alerts for errors」)。 ↩
出处:「Operational tasks」(text/85-fm-introduction.txt:259,搜「Elastic Stack」)、:262(搜「Prometheus」)、:265(搜「Grafana」)、:270(搜「OpenTelemetry」)、:274(搜「best friend」)。 ↩↩
出处:「Development is a collective endeavor」(text/85-fm-introduction.txt:286,搜「increase the transparency」)。 ↩
出处:「Develop on the shoulder of giants」(text/85-fm-introduction.txt:298,搜「built on preexisting software」)。 ↩
出处:「Web development is here to stay」(text/85-fm-introduction.txt:307,搜「one of the first things they will offer is a web service」)。 ↩
出处:「Rust set the bar in safety and performance」(text/85-fm-introduction.txt:313,搜「trendsetter」)。 ↩
出处:「Software without support is as good as dead」(text/85-fm-introduction.txt:319,搜「last updated years ago」)、:322(搜「living community is even better」)。 ↩