⚙️ 工程师偏差地图

选型过程：
1. 朋友/CTO/KOL推荐框架X
2. 你搜"为什么X好"和"X vs Y X更好"——而非"X vs Y Y更好"
3. 你找到10篇赞X的文章，2篇批评X的→忽视后者
4. 在团队会议上，你展示了"调研结果"——其实是在为已选方案辩护

数据库选型：决定用MongoDB后搜"MongoDB优势"→找到"灵活Schema、水平扩展"→满意。不搜"MongoDB数据丢失案例"、"MongoDB事务问题"。
编程语言：Python用户搜"为什么Python是最好的语言"，而不是"Python的缺点"。

重写 vs 打补丁：
系统A：5万行遗留代码，技术债利息高涨（每次改功能花3天），新功能开发慢
选项1：继续打补丁——"已经写了5万行，不能浪费"
选项2：重写核心模块——6个月，但之后新功能1天搞定

5万行代码是沉没成本——无论继续还是重写，写那5万行的时间都回不来了。正确比较的是：未来继续维护的成本 vs 重写的成本+未来维护的成本。

Netscape故事：Netscape决定重写浏览器→6年未发布新版本→IE趁势而起。反面教训：重写也要有策略，不是全推翻。Joel Spolsky的经典文章《Things You Should Never Do》。

技术栈迁移：
"我们一直用MySQL"→即使需求已经变化（需要图数据库/时序数据库）
"我们一直用单体架构"→即使团队已经发展到需要微服务的规模
"我们一直用Jenkins"→即使GitHub Actions更简单高效

为什么现状偏见特别强：
1. 改变有显性成本（学习、迁移、短期风险），维持没有
2. 维持的隐性成本（机会成本、技术债利息）不可见
3. 改变需要主动决策→认知负荷→拖延
4. "如果改了出了问题是我的锅，不改出了问题可以怪'一直这样'"

重复造轮子：
• 自建日志库→已有Log4j/Serilog/Winston
• 自建HTTP客户端→已有Axios/Got/Reqwest
• 自建ORM→已有TypeORM/Prisma/SQLAlchemy
• 自建认证系统→已有Auth0/Keycloak/Casdoor

为什么？
1. 不信任外部代码："不确定质量/安全"
2. 控制欲："我们需要完全控制"
3. 学习/成就感："自己写更有意思"
4. 宜家效应："自己做的更了解"

但自建也有成本：维护负担、bug修复、安全更新、文档、社区支持——这些都是外部方案"免费"提供的。

反面——过度依赖外部：left-pad事件（2016）——删除11行代码的NPM包导致全球构建失败。平衡是关键。

Sprint中的技术债：
Sprint 1：赶deadline→写quick fix，标记"TODO: refactor"
Sprint 2：新需求来了→在quick fix上堆更多quick fix
Sprint 3：代码已经很难改了→改一个功能要理解整个链路
Sprint 4：每次修改都引入新bug→团队速度下降50%

心理账户陷阱：
• "这个Sprint先赶需求，下个Sprint还技术债"→但下个Sprint又有新需求
• "技术债"和"新功能"被当作两个独立账户→但它们实际互相影响
• 0%利率幻觉：以为技术债利息为0，实际是复利增长

量化（McConnell, 2007）：技术债的"利息"=每次修改多花的时间×修改频率。例如：每次修改多花2小时×每月修改10次=每月20小时=2.5个工作日。

性能高估：
• "这个架构轻松支撑百万QPS"→实际500 QPS就崩了
• "数据库可以水平扩展"→实际上JOIN查询无法分片
• "缓存命中率会>95%"→实际冷启动时<30%

规划谬误（Planning Fallacy）：Kahneman & Lovallo(2003)发现IT项目：
• 估计2周完成→实际4-6周
• 估计预算$50万→实际$80-150万
• 估计可用性99.99%→实际99.9%（差10倍）

为什么架构师特别容易过度自信：
1. 没有历史数据校准（每个系统都"不一样"）
2. 乐观偏差：只考虑顺利路径，不考虑失败路径
3. 内部视角：只看自己方案，不看同类项目的失败率
4. 专家盲区：越专业越容易忽略边界条件