离开 LinkedIn

代码库规模、复杂性与性能

• 文中提到的约 200 万行前端代码，对习惯于大型应用的人来说并不算震惊；也有人将其视为臃肿的证据。
• 解释包括：多年累积的众多功能、JS/HTML/CSS 的冗长、”代际臃肿“——新开发者只会继续加代码、多套重叠的 UI 系统，以及跟踪/分析代码。
• 多位评论者认为 LOC 是个糟糕的指标；真正重要的是工程师需要接触多少代码，以及边界是否合理。
• 用户反馈 LinkedIn 很慢、CPU 占用高，页面加载时间长、消息功能卡顿、后退按钮行为异常，以及搜索/职位提醒效果差。通知普遍被认为充满垃圾信息且具有操纵性。

构建时间与工具链

• 这个单体 Web 应用 17 分钟的构建时间引发分歧：有人认为在这个规模下可以接受，另一些人则认为明显太慢。
• 许多人强调增量构建延迟才是关键指标；完整的干净构建可以缓存或卸载出去。
• 建议的改进包括：更好的项目结构、密封式构建系统、并行化和云端缓存——但这类工作需要持续的组织投入，而这在现实中很难获得批准并长期维持。

Conway 定律、组织结构与变革

• 大量讨论把这份混乱的代码库与 Conway 定律联系起来，并指出它随着时间演变成一种“噩梦”：软件反映的不是某一张组织架构图，而是多次重组、并购与历史层层叠加的结果。
• 有人认为，大规模技术变革只有在强有力的自上而下推动者存在时才会成功；也有人讲述了罕见的自下而上成功案例，通常都以外部利益相关者关心的指标为锚点。
• 对 Conway 定律究竟有多“像定律”存在分歧，但普遍同意：沟通结构深刻塑造系统设计，而改变组织行为比改代码更难。

迁移 vs. 大重写（“手枪手势”）

• 播客将谨慎的多年渐进迁移与热情洋溢的从零重写方案进行了对比。
• 评论者指出，长期、稳妥的基础设施方案在政治上更难争取资金；而那些被包装成“很快”的炫目重写，往往一拖就是多年，并留下大量遗留残余。
• 许多人赞同由资深小团队来构建新系统，但也警告要防范第二系统症候群、过度架构，以及维护缺乏激励的问题。

资深/Staff 工程师的角色与政治

• 讨论中有一条强烈的主线：到了资深层级，技术上“正确”是不够的；真正的工作是对齐共识、经营关系，以及把工作与业务联系起来。
• 有些人认为主人公很理想主义，但在政治上无效；也有人认为，在一个失调的环境里，拒绝只为“底线”最优化，是一种合理的价值选择。

文化、激励与内部质量

• 多位现任/前任员工描述了脆弱的内部工具、漫长的构建与部署路径、很少的 QA，以及奖励可见功能而非清理工作的晋升体系。
• 也有人认为，与行业整体相比，LinkedIn 的后端代码质量处于中上水平，痛点主要集中在旗舰 Web 前端。