导读：LinkedIn 前高级工程师 Chris Krycho 谈到了对遗留代码进行现代化改造的复杂性，以及关于最佳实践方法的冲突如何导致他离开这家微软旗下的平台。
LinkedIn 前高级工程师 Chris Krycho 最近在自己的博客谈到对遗留代码现代化改造的复杂性，以及关于最佳实践方法的冲突，因何导致他离开这家微软旗下的社交平台。
从 2019 年 1 月至 2023 年 10 月，Krycho 在 LinkedIn 工作了近五年。根据他在网站上的简历，他是 LinkedIn.com 网站的技术主管。他的简历还写着，他“设计了一种远离 Ember 的迁移策略。但我们没有使用它——请问我吧！”
他在Corecursive 播客中深入阐述了 LinkedIn 背后的代码以及维护和现代化大型遗留代码库的挑战。
他提到，2019 年 LinkedIn 前端有 200 万行代码，构建耗时 17 分钟。后端有“巨大的 API 服务器”，支持 LinkedIn 主功能、广告服务器、LinkedIn 学习平台等。
Krycho 说，LinkedIn 提到网站使用Ember.js构建，他的第一个大项目是对代码进行现代化改造，并开始使用 JavaScript 类。他遇到了一些公司政策，其中涉及多个团队的流程占用的时间不能超过 10%。他提出的解决方案是尽可能自动化修改，但仍然需要 18 个月才能完成工作，但是仍然不断被团队拖延，人们表示因为其他需求而没有时间。
这次经历表明，组织和文化因素导致重大改进难以实施，即使所有人都同意这些改进是值得的。
尽管迁移到了类，但代码中仍然存在许多错误，Krycho 的下一个任务是逐步迁移到 TypeScript。尽管 TypeScript 迁移问题摆在他的办公桌上，这增加了他的工作量，但这一工作仍在继续。
Ember.js 的使用也仍然存在问题。
Krycho 提到，LinkedIn 是“世界上最大的 Ember.js 用户”，但他发现这在代码的许多部分都不是最佳解决方案。他决定从 Ember.js 转向 React。如何利用现在的 300 万行代码来完成这一任务，同时又不违反 10% 的规则？
Krycho 提出了一个他认为可行的计划，尽管这需要“三到五年的时间”。三年是非常乐观的。” 这将再次涉及开发自动化，“我们的想法是产品团队永远不必真正停止。”
与此同时，公司内的另一个团队也提出了一个替代方案，Krycho 总结为“重写移动和桌面应用程序”。他说，与 Krycho 的五年计划相比，这种“大爆发”式的方法更能引起 LinkedIn 管理层的共鸣。
在此过程中，Krycho 描述了 LinkedIn 代码库的一些深层次问题，其中之一导致圣诞节假期期间出现服务中断。原因是预渲染服务中的内存泄漏，以及如果服务器使用过多内存就会重新启动服务器的自动化流程。配置错误意味着太多服务器同时重新启动，导致其余服务器也出现故障。“我们最终会拆除整个数据中心的所有服务器，”他如此说道。
为什么代码会出现这么多问题？Krycho 将其归因于由于优先考虑新功能，而不是代码质量而造成的技术债务。
“当快速上线成为其他一切都服从的主要或驱动价值时，它会让你陷入这样的境地：一开始你可能拥有良好的速度，但随着时间的推移你将无法维护它”。
他的反思暗示 LinkedIn 大爆炸重写提案可能会重复同样的问题。
Krycho 在文章中强调，他“很喜欢在 LinkedIn 的时光”，并且“我学到了很多东西”，即使他的结果是“我不会花费多年的时间，尝试以某种方式构建那些我最终不相信的事情。” 他只给出了自己的观点，还有很多未知的事情，尤其是替代计划是如何进行的。
不管 LinkedIn 的结果如何，它都是一个经典案例，说明了对大型代码库进行现代化改造是非常地困难，技术债务的现实，以及平衡业务需求与提高代码性能和弹性这一不太令人兴奋的任务之间的挑战。
Krycho博文地址：
https://corecursive.com/leaving-linkedin-with-chris-krycho/
