2026-第四十一周

该周报主要为各个地方内容的汇总整理

技术

单体优先

Martin Fowler 认为，新项目应优先采用“单体优先”策略：即使未来可能受益于微服务，也先从单体开始。因为成功微服务案例大多来自过大的单体拆分，而从零构建微服务常陷入严重麻烦；微服务适合复杂系统，但存在显著“微服务溢价”，早期应优先速度与反馈，待边界稳定后再逐步演进。

• 🏗️ 几乎所有成功的微服务故事，都始于一个变得过大、随后被拆分的单体。
• ⚠️ 几乎所有从零构建微服务系统的案例，最终都遇到了严重麻烦。
• 💸 微服务是有效架构，但有“微服务溢价”，即管理一组服务的成本会拖慢团队，简单应用更适合单体。
• 🚀 新应用初期应验证想法是否有用，优先快速迭代和反馈，避免承担微服务开销。
• 🧭 微服务只有在边界良好且稳定时才有效，但即使经验丰富的架构师在初期也很难划对边界。
• 🧩 单体优先可先探索正确边界，并逐步发展微服务所需的前提条件。
• 🛠️ 执行方式包括：精心设计模块化单体；从边缘逐步剥离微服务；整体替换并用“可牺牲架构”快速上市；先做粗粒度服务再细化。
• 🔁 不能假设任意单体都能拆成微服务；多数系统模块依赖过多，强行拆分容易混乱。
• 🤔 反方观点认为，从微服务开始可适应开发节奏、按服务划分团队、便于扩展，尤其适合系统替换；但团队最好已有微服务经验。
• 📊 目前证据仍少，关于单体优先的建议应视为暂定，远未达成一致。

工具

更新

设计

其他

TBM 436：基于张力的优先级排序（一种非框架）

John Cutler 在《TBM 436: Tension-Based Prioritization (A Non-Framework)》中主张：团队不该只沉迷于“要优先做哪些事项”和更精细的框架/表格，而应关注反复出现的张力。真正困难通常不在判断什么是重要的，而在执行层面：为什么大家明知该停止、该投入、该重置，却缺乏承诺、政治意愿和组织条件去行动。文章提出用“张力”作为信号，并给出填空练习，帮助团队先暴露真实取舍，再套用任何优先级框架。

• 🎯 优先级排序分为两部分：优先判断（什么值得投入）与优先执行（实际如何让资源与行动对齐）。
• 🧭 多数优先级讨论只是在制造可接受的叙事，避免困难对话，很少产生真正承诺。
• 🔁 回顾时人们很少谈框架，更多谈为何缺乏停止的勇气、为何惯性获胜、为何集体合理化。
• 🚫 团队通常不缺更多选项或表格，而是缺面对眼前不对称问题和应修复事项的意愿。
• ⚖️ 真正缺失的不是信念，而是在当下不便中仍愿意承诺。
• 🌫️ 对远期存在性威胁，大家往往同意却无法动员，因为威胁抽象、无明确负责人、跨团队且行动难想象。
• 🎉 对有趣、有意义、显性价值的优先事项容易习惯性说“是”，可能过度投入并挤占更重要但更难受的事。
• 🧩 常见张力模式包括：默认同意、需要大重置、永远差一点完成、反复回旋、早期培育、能力缺口、80/20 缩范围、真假紧迫窗口、间接价值与公地危机。
• 🧲 这些张力彼此对立，不能同时全做；更像管理风险组合：知道哪些张力要维持、释放或正视。
• 🧠 真正问题常在“已经知道该做什么”之后：如何创造组织条件去行动，而非再算一遍价值、风险与成本。
• 📝 练习方法是让团队填空，暴露反复回避的张力与潜在决策，再使用任何优先级框架。
• ✅ 目标不是更数学化地理性排序，而是用张力信号形成跨时间、价值与紧迫性的平衡下注组合。