LinkedIn 作为全球最大的职业社交平台，拥有数亿用户，其代码库规模也是相当宏大。2019 年时，其前端代码量就到达了 200 万行，构建时光长达 17 分钟。后端还有支撑LinkedIn功效、广告出售平台等数以千计的服务。如此宏大的代码量，给保护和更新带来了伟大的挑衅。

更糟糕的是，由于长期以来为了快速推出新功效而疏忽代码质量，导致体系问题频出，开发团队疲于敷衍：无论在 QA 环节上付出多少尽力，都不可能彻底清除隐患。而且，LinkedIn 技巧架构一度还停留在比拟早期的阶段，比如应用 Ember.js 框架。

作为 LinkedIn 官网的技巧负责人，Chris Krycho 在这里工作了将近五年，致力于更新 LinkedIn 代码库。Chris 表示 LinkedIn 是“世界上最大的 Ember.js 用户”，但他以为 Ember.js 并不是最佳解决计划。

为解决这些问题，他制订了一个迁移计划，筹划将代码从 Ember.js 迁移到 React。另外 LinkedIn 公司还有一些政策限制，例如涉及多个团队的流程不能占用超过 10% 的开发时光。那么，如何在不违背 10% 规矩的情形下，迁移包括了 300 万行代码的体系呢？

Chris 以为他的计划是一个可行的渐进式重构筹划，不过须要“三到五年。而三年甚至还是非常乐观的估量。” 该筹划同样须要开发自动化工具，但不会影响到业务的正常运行，“产品团队将永远不必真正停下来”。

与此同时，公司内部另一个团队提出了一个大爆炸式的替代计划：“重写移动端和桌面端运用”。与 Chris 的五年筹划相比，后者却能投引导所好。“我的提议落选了”，但Chris以为公司没有看重代码质量和技巧债务问题，并暗示替代计划仍然可能会重蹈覆辙，再次陷入技巧债务的泥潭。

最终，因为对公司技巧文化的绝望，Chris Krycho 选择分开了LinkedIn。

对于 Chris Krycho 描写的问题，一位网友用了一次性账号做了如下评论：“我是一位在 LinkedIn 工作多年的工程师。虽然没有与 Chris合作过，但我完整懂得并认同文中所表达的挫败感。如今，LinkedIn 的管理模式已变得愈发自上而下...... 为了尽快交付功效，LinkedIn 内部弥漫着一种急功近利的气氛。这种急躁的心态导致了大批技巧债务的积聚，速度与质量之间的平衡荡然无存。新功效的开发往往疏忽边沿情形，留下许多破绽和缺点。尽管许诺会进行修复，但最终却不了了之。高层只知道我们上线了新功效，没人告知他们这些功效烂到基本无法应用。在绩效考察的压力下，工程师们只能忍气吞声，疲于奔命地完成一项项义务。他们无暇顾及代码的质量和可保护性，长此以往，技巧债务只会越积越厚。”

下面我们来一起看看 Chris Krycho 的自述：

2019 年 1 月末，我正式参加 LinkedIn 公司。

我之前工作过的初创公司都有一套相对尺度且比拟完美的整体后端，再加上数据库、配套服务之类。但在进入 LinkedIn 之后，我发现：第一，大部分工程师其实是在前端客户端运用上工作，而且前端中的代码行数比我之前负责过的项目标整体业务代码还要多。后端里也运行着数以千计的服务，这些恐怖的 API 服务器让我之前见识过的任何项目在体量上都相形见绌。而且这还只是一个 API 服务器，也就是大家熟习的 LinkedIn.com 客户端。我们还有广告出售平台、LinkedIn Learning，等等。所以刚入职那段时光，我就是在从震惊到再一次震惊之间逐渐懂得 LinkedIn 这家公司及其项目标宏大体量。

其实我之前工作过的公司已经有一款……至少在当时的我看来非常宏大的运用程序了，足足有 15 万行代码。但在看到 LinkedIn 前端的时候，它有 200 万行……几乎相当于我之前项目标 20 倍大小，新构建须要 17 分钟。

我所在的团队被称为基本设施团队，但这并不代表我们负责树立服务器，实际工作更接近工程支撑或者说开发者体验。我的职责就是让 LinkedIn 的宏大桌面运用程序前端更易于应用。

每个季度，都有 150 到 200 名工程师要对运用程序提交更新，大家可以想象一下这是什么概念。将来的代码行越来越多，我们该怎么在这种横跨几十个团队、数百名工程师的情形下打造出真正有凝集力的产品？

刚开端我实在有点不知所措。虽然如此伟大的项目本身就很酷，但我感到无从下手。而且在这样的规模之下，一切技巧债务和技巧改良都将比无限放大——胜利则是伟大的胜利，失败也是伟大的失败。所以大家可以想见，对于 200 万行代码，任何小小的技巧债在乘以这个数字后都将无比夸大。

我在 LinkedIn 协助推进的第一个重大转变，就是引入了 JavaScript 类。JavaScript 本身已经引入了类，但当时他们应用的是 Ember 框架，而且须要对代码进行谨严更新。

起初我们要做的就是在这 200 万行代码中转变类的编写方法，把本来直接将对象传递至函数，转变成应用 class foo 扩展子类 bar 或者超类 bar。

为了能在如此宏大的规模下完成迁移，全部进程必需尽量自动化，否则单靠人力永远做不完。究竟手动重写 200 万行代码想想就令人胆寒，哪怕是昼夜不休的铁人，全部工程也须要连续几个月的时光。而且我们也不可能让产品团队放下手头的工作，全体跑去为原有 JS 代码添加英俊的新语法。哪怕这能带来性能优势，哪怕能改良最终用户的体验，我们也得斟酌实现成本的问题。

说起产品团队，虽然我们团队致力于改良开发者体验，但还须要其他团队的协助。也就是说无论怎样的优化和调剂，我们首先得取得忙于交付功效的产品团队的认可。

LinkedIn 在这方面的流程其实还比拟完美，随时随地都有某种水平的修正在进行当中。关于大规模技巧投资的争辩可以追溯到 2010 年代初，当时 LinkedIn 的整体架构已经到达了规模扩大的极限，因此不得不转向面向服务架构——也就是微服务架构的早期雏形。当时的用户规模还仅是目前的十分之一，产品团队几乎是整整停摆了一年，专门跑去研讨架构转换。后来他们心有余悸地表示，永远不想再来一次了。确切，对于任何一家企业，把手头的工作放掉一年确切成本太高。

所以我们就树立起一套针对此类横向串连的制度，之所以强调横向，就是因为有些工作须要跨越大批团队，得逐一说服相干负责人才可能履行。还有专门的委员会负责对全公司的员工进行审查，确保大家都能坚持必定的参与度水平。这些团队一般也就能许诺拿出 10% 的时光和精神来配合，所以哪怕我们的技巧计划再先进、再精妙，产品团队也绝对不可能 100% 投入进来，再次放下手头的所有事务。

我们会尽量以自动化情势操作，在对方的代码库上运行和测试。我们会非常友善地跟对方沟通，比如讯问对方能否懂得添加后的输出结果、当前提案是否适合进行合并等等。总之，直接把结果递交给产品团队的负责人，肯定比要求对方替我们做测试和评估要简略得多。

我们整整花了 18 个月时光才完成 Ember 的调换工作。

其实大部分工作在六个月内就已经完成了，但这是那种典范的长尾项目，所以我们不得不一再推迟交付日期。期间由于 CEO 本人的否决，我们尝试推出新产品的提议没能通过，这也给另一个团队造成了不小的打击。究竟在公司里，没人能跟 CEO 正面反抗。所以说技巧自动性确切主要，但效果也着实有限，至少我们不可能光靠自己的道理就压倒 CEO 的断定。

跟大多数公司一样，LinkedIn 也有针对此类异常的毛病日志记载。初创公司广泛会应用扫描工具来提取这些记载，但 LinkedIn 拥有自己的内部基本设施，究竟我们的业务规模太大了，每个小时都会冒出大批毛病。

其实我并没有讥讽 LinkedIn 的意思，而是在严正认真地讨论这个问题。在认真视察软件之后，我发现 LinkedIn 的很多既有软件都很糟糕。而之所以会闹出问题，往往不是因为工程师们漠不关怀，而是至少两种构造因素协同影响的结果。其一就是很多朋友都阅历过的情形：我们的业务大船已经启航，这时候再想要调头就相当艰苦了。有些工程师总想把功效打磨再打磨，但实际上我们往往另无选择，时光到了就得把哪怕还不成熟的产品推向市场。

但这并不必定是坏事，究竟灵活灵活才是保持业务运转的诀窍。可质量上的让步确切存在，再加上缺少足够壮大的工程文化来消解，最终这种支离破碎感就开端体现在用户体验层面。虽然这在短期之内并不必定会拖垮 LinkedIn，但从长远来看必定有损公司的市场形象。

其二，哪怕我们已经尽了最大的尽力，最终也仍有可能遇上各种稀奇异僻的代码问题。我们的冒烟测试可能发现不了问题，QA 也有可能无法察觉，但就是这个毫不起眼的隐患点没准会在用户数目突破十亿的瞬间突然爆发。

实际上在我离职的时候，LinkedIn 已经拥有十亿用户，而业务整体 repo 共有 320 万行代码——其中一半是测试代码，一半是生产代码。到了这个规模，无论我们在 QA 环节上付出多少尽力，都不可能彻底清除隐患。总会有大家以为没问题、但实际有问题的部分，总会存在测试进程中意想不到的路径和组合在现实中引发故障。

所以最终肯定会有故障涌现，也许是页面挂起，也许是界面白屏了，也可能是移动端运用重载。反正用户们已经习惯了，重启或者刷新一下就是。究竟奇奇异怪的状况 bug 总会涌现，而先关闭再重新打开确切能解决很多问题。

但 JavaScript 引发的毛病太多了，有些毛病是无法捕捉的，我们只能尽力而为。在这个进程中，我们不禁思考如果用 TypeScript 结果会不会更好些。

TypeScript 很庞杂，JavaScript 也很庞杂，但我们至少可以搞清晰如果真的进行整体迁移，那些有多少种毛病类别不会再涌现在我们的日志当中？面对每天数以百万计的毛病条目，我们也会将其转化为实际可操作的数字，比如思考能不能想方法把运用程序的日志记载量减少四分之一。

没错，能减少 25% 就算胜利。实际比例可能更高，但低限就是四分之一。

TypeScript 曾有一句口号，“我们是可扩展的 JavaScript”。

面对这几百万行代码和所有这些毛病，LinkedIn 很显著须要借助 TypeScript 的扩展性优势。

所以，我们开端提交申请，尝试转向 TypeScript。好资讯是上头表示支撑，赞成以分步方法完成向 TypeScript 的迁移。之前已经有很多代码库完成了迁移。但坏资讯是，产品团队能够蒙受的 10% 时光预算不足以全面完成这项工作，这是一项相当艰难的义务。因此，我们跳过了横向串连，选择以自下而上的方法推进这场变更。

之前我曾制订过一项筹划，让 LinkedIn 解脱 Ember 并全面转向 React。事情一开端很顺利，但随着项目标推进，新的问题又来了。我们的高层引导表示 LinkedIn 的迁移成本太高。虽然我们聊了很多也做了很多，但现在的重点就是让基本设施团队尽一切方法降低迁移工作的成本。

总之成本还是太高，而这笔成本主要来自公司对于产品宣布速度的高等待。

而在我们看来，产品宣布速度的降低在很大水平恰恰源自这款运用程序中的 300 万行代码，它们已经应用了 7 年，其中积聚了相当多的债务——技巧债务和产品债务都有。

随着时光推移，产品的宣布速度只会越来越慢，永远坚持早期的快速宣布几乎就不可能。哪怕只是一丁点调剂，也可能给用户体验带来伟大损坏。也正因为如此，产品设计工作也变得艰苦重重，因为在这样的规模下，开发团队很难搞清哪些处所能改、如何适应原有产品。

但无论如何，引导层那边给出的指导就是尽可能降低迁移成本。所以问题就很明确了：想方法以低成本方法将 300 万行 Ember 代码转换成 React 代码。

既要开展大规模迁移，又要保证在迁移进程中不拖慢其他团队的开发速度。这确切是个大难题。

既须要大规模重写，又限于引导的这些条件，于是我们想到一种策略，应当能够满足引导层的要求，粗略估量大约须要三到五年时光，哪怕最乐观的情形也得三年时光。

我们的想法是在自动化方面多下工夫，尽可能减少须要由产品团队承担的工作。当时的思路是对具体工作进行排序，并多种方法将其拆分成块、按线索组合，这样就能一次解决一条线上的所有问题，然后再处置下一条线索。

另外还有些义务可以并行履行。对于那些没有明确排序、难以具体分块的工作，并行化能赞助我们高效调剂构建管线、更改数据层、更改路由层、为响应式体系找到可操作的路由与视图层迁移路径，最后再把响应体系中的视图层从 Ember 迁出。

最后一步才是迁入 React，全部进程都靠编写的自动化工具实现。这就是我们的基本思路。如我所说，三到五年对应着伟大的工作量，但这能保证产品团队不会受到重大影响、至少不会像之前那样彻底停摆。

这是一项艰难的义务，就像在汽车行驶进程中一点点改换零件、再造车体一样。尽管艰苦重重，但三到五年也确切能够做成很多事情。

与此同时，另一团队（我们称之为 Fingerguns 团队）出手了，当时他们也有一项筹划，盘算解决相似的问题，但思路不同。他们采取的是一种“重写移动和桌面运用程序”大爆炸式重写提案。

在我看来，双方最大的共鸣就是工程主管和高层团队都不愿望迁移影响到产品宣布速度。我们要如何更快地交付功效和思路？我们要如何快速迭代？我们该如何将想法快速转化成 A/B 测试？我们能不能把几个月的筹划缩短到几个礼拜？究竟在项目敲定的时候，时光已经过去几个月了。但他们也知道，我们的堆栈存在严重决裂：我们既控制着宏大的桌面堆栈，也有截然不同的移动 Web 堆栈。我们的 iOS 和 Android 版运用更新周期很长。能不能让一切都运转得更快些？

回忆起来，当初引导层一直提醒我们要注意迁移疲劳问题。但迁移疲劳只是表象，各方真正关怀的还是能不能加快迭代速度、尝试新想法，并在想法不够好或者无法马上施展作用时及时废弃。而迁移可能会阻碍这一切，究竟他们的工程师往往须要把 10%、20% 甚至 25% 的时光和精神消费在迁移上，而不是他们最关怀的功效迭代上。而我们提出的筹划并没能解决这个最大的痛点。

所以，在这种形势下，另一个团队的表示在全 LinkedIn 之内引起了轰动。Finger Gun 模式就像是在用手势指挥和调度千军万马——不纠结于具体问题，单纯指引各方投入行为。

乍听之下我简直要气炸了，但我很快意识到，由于我们习惯于支撑十几位工程师，所以并不清晰跟上百名、甚至是几千工程师打交道究竟是怎么一回事。我压根不觉得自己能够指挥全局，要求各团队放下手里的工作，重新开端参与到一个宏大的项目当中，再用这种方法满足各方对于速度的极致寻求。

Finger Gun 团队的高等工程师 Jim 倒是非常乐观，他跟我在软件工程的懂得方面甚至可以说是截然不同。而对于我提交的五年筹划，引导们很不爱好。这个筹划表面是从 Ember 迁移至 React，但问题背后的核心在于应当如何改革一切，确保业务的运行速度能够加快、推进 LinkedIn 能够更快实行变更。而高管团队有须要达成的指标，他们面对市场压力，还要斟酌微软那边的回报要求。

随后一次圣诞假期，公司网站出了问题，LinkedIn 的大部分用户在长达 20 分钟的时光里无法正常拜访内容，连 LinkedIn.com 的页面都刷不出来。在接下来的三个月中，我得连续跟进这项工作，搞清晰到底是哪里出了问题。

事故的原因是预渲染服务中的内存泄露，再加上一个自动进程，该进程会在服务器应用内存过多时重启服务器。由于配置毛病，导致过多的服务器同时重启，进而导致剩余的服务器也产生故障。

实际上我们设计了一套体系，提醒内存用量已经超过上限，这时候重启装备就能解决问题。暂时算是敷衍过去了，但这并不是基本的解决方法。另外还有一项设置，决议我们同时最多能接收重启多少个容器。这项设置来自 YAML 配置文件中的一个键。不知道什么时候有人为其设置了相应的值，值本身倒是合法的，但对实际体系需求来讲可能设置不当。具体来讲，这个数值大约是正在运行的全体服务的总数。由于各服务的容器几乎同时启动，收到到的要求数目也大致雷同，所以它们的内存占用量也基本上是在同步增长。

这种情形的产生频率开端上升，而且逐渐逼近用户和 LinkedIn 都无法接收的田地。刚开端只是某个长周末或者因特定原因引发的暂停，但最终这个配置毛病到了临爆点上——于是所有服务器开端同时重启。结果大家可以想象，LinkedIn 的所有服务都不再响运用户们的要求。这是一种会快速蔓延的问题，最终压垮了全部 LinkedIn 平台。

部分服务器离线会给其他装备增长压力，于是后者吸收到的流量更大、内存应用量也随之增高。重启和负载转移反复进行，直到全部数据中心都离线了。在后台我们还有一个用于规模调剂的进程，我们想的是应当尽量减少全部机群的 CPU 和内存应用量、避免过度配置。究竟斟酌到 LinkedIn 的设施基本盘那么大，应当能够周转得过来。但事实证明，这些预想相互交错最终酿成了大祸。规模调剂降低了设施的容量上限，而内存泄露又拉高了资源需求量，突然之间资源用量到突破了上限，只剩下我们一脸无奈。

当时我和一群工程师们站在机房里，说起我们须要更好的警报体系和更全面的可视察设置。当然，还有更强的设施弹性，究竟节点服务器的离线不应当把管理该进程的主机进程也拖入瓦解。相反，我们应当针对此类警报终止节点进程并进行重启，这样我们就不须要关闭容器，从而彻底避免整体宕机的再次产生。

我从这次事故当中总结出了不少改良基本设施的经验：故障毕竟会涌现，人类就是会犯毛病。世上没有不中止的体系，也没有不瓦解的项目。这就是我对软件工程的意见。无论是编程失误还是黑客攻击，工程师们在设计自己的体系时不可能完美无瑕，我们交付的每款产品都或多或少存在缺点。

而解决的症结就是树立起多层弹性，确保我们能够发现问题，以安全的方法修复毛病，同时通过警报向管理员发出问题提醒。

而Finger Gun 模式下“重写移动和桌面运用程序”的计划解决不了这些问题，而且可能会反复同样的问题。他们许诺，虽然短期内会降低速度，但从长远来看会大大进步速度 。但症结的是，它并没有许诺改良代码质量或开发人员体验。我并不真正信任它会带来速度上的晋升，也没方法修复了足够多的问题，让体系稳固下来。

但面对问题，上级引导想要的只是尽快让事情过去。这就再次回归了关于速度的争端，总之现在的例会气氛越来越紧张了。

我们的例会越来越多了，引导层总在讯问项目状况如何、在哪些方面取得了进展。于是我们须要整理更多报告、告知高管团队我们取得了哪些进展，还得及时反馈团队须要哪些赞助。

而 Finger Gun 团队的负责人接收了事件响应工作。他又拉来了一大堆新成员。这些都是精彩的员工，但他们的介入其实反应出引导们的态度：我不信任你能解决这个问题，我也不信任你说出的答案，所以我叫来其他人代替你。

Finger Gun 团队的高等工程师 Jim 当时在电话会议上公开表面了这样的态度，随后情形开端一路走低。Jim 当时直接问：代码审查为什么没有发现问题？而我的答复是，就是没发现，而且以后也不可能发现。人就是种会犯错的生物，但他们会学着做得更好。更具体地讲，假设当时审查员刚好是位新手，而这条 PR 是由某位非常资深的 SRE（站点可靠性工程师）提交的，你猜会不会被快速通过？

审查员为什么要质疑这个值合不合理？很多东西看起来就是合理的，只有在极端条件下运行时才会出问题。所以对于任何一套工程体系，我们真正能够把握的就是它当下能不能运转、其中的进程能不能运转、特定的工具能不能运转。无论是高等工程师，还是刚刚入职的技巧新人，他们的心境都会有高潮、有低谷，所以对于他们编写的结果最合理的预期，也就是当下能够运转。

工作仍在推进，但压力却越来越大。Finger Gun 小组基本就不清晰问题的规模，只会问，“那为什么这个问题还没有解决？”“高管们对目前的进展速度不满意。”

当然不可能满意了，因为你们已经积聚了整整七年的技巧债和弹性缺失，而我们正在尽力修复。换句话说，我们须要在三个月之内填补七年来的疏漏。这样的进展已经相当不错了，至少我自己这么以为。我记得我还跟自己的前上司强调过，这应当是我这辈子参与过的最猖狂的项目。当时 Finger Gun 经理进来说我的工作做得不够好，因为修复的速度不符合引导的预期。那一刻我感到他们对于这种规模的工程项目缺少敬畏，意识不到其中的问题有多难解决。

我们有无限无尽的内存破绽问题须要修复，而这种特定内存泄露的根源，就在于它们都在引用同一个核心对象。所以哪怕是修复了其中一个，也无法转变体系的整体行为。这种感到太难受了。

而且我们还同时启动了替代试验，大家尝试之后觉得效果不错，应当可以解决问题。可那帮工程师就像听不懂人话一样，只会反问“那又怎样？”

大约就在同一时光，他的团队通过重组恶意兼并了我的团队。他成了我上司的上司。这样倒好，如果他是我的直属经理，我很可能会当场辞职。

现在想想，人就是在不同的地位上学到各种新东西的。

有篇文章提到，“在高等工程或者经理层级上，基本就不存在纯洁的行政或者技巧问题，一切都是行政与技巧的杂糅。”

是的，一切都是行政与技巧的杂糅，而我们须要肯定其中的边界在哪里。到底倾向行政方面，还是技巧方面，或者是二者特定比例的联合？我到底该做什么来解决这个问题？

Finger Gun 的筹划开端取得进展、吸引关注，而且规模仍在不断扩展。当前的工作就是重写移动端和桌面端运用程序。“我们盘算重新斟酌 LinkedIn 的产品构建方法”，这无疑令人高兴。而且必需承认一点，就是在面对雷同问题时，我和我的团队输了，Finger Gun 团队那边赢了。

但我愿意接收这样的现实。究竟我确切没能说服引导层，对方甚至没有耐烦认真听我做的讲述。或者说，除了我对项目本身表示出的热忱之外，他们基本不知道我在说些什么。我想让 LinkedIn 再次伟大———这个很好；但我们须要解决这些问题能力实现——哦，你不想听……

在跟经理的沟通中，他曾提醒我“你太幻想主义了，你对业务不够关注，最好能调剂一下价值观。”当时我完整无法懂得，因为你说的都是社交、都是行政，但我聊的可是纯技巧。

可现在我懂得了，因为我开端明确对方的立场。每个职位都有不同的立场，动身点上的差别决议了大家不可能处在同一频道。

我们在代码库里遇到的很多问题，都源自对速度的过度强调。因此哪怕发现了问题，出于对影响进度的担心，管理层都会把压力传递给工程部门。而我们面前就只有两个选项：要么想方法修复，要么直接跳过。

这两种都可以，但管理者压根不想做选择，他们只想知道下一项功效什么时候能宣布、还能不能再快一点。当速度成为压倒其他一切的核心驱动因素和价值取向时，我们就必定陷入这样的地步：刚开端项目推进速度很快，但越往后越保持不住，最终陷入债务的泥潭。

实际上，这在拥有漫长历史的代码库来说是种常见的通病。很多管理者只知道不断扩展资产，但却不看重投入和改良，于是最终一切只会回到原点。我看到的很多申报内容都在强调如何尽可能进步速度，但却没有对遗留的问题做出说明，甚至不提后续该如何整理残局。

而我一直在思考这些问题，想要尽量以温和的方法陈说这么干可能引发的效果。虽然期间也发现过一些有趣的技巧方向，但我最终还是觉得身心俱疲，并决议辞去这份工作。总之在那段时光，我开端涌现偏头痛和严重的胃痛，没方法正常活动，随时情感瓦解并陷入恐慌。那些日子真的太恐怖了。

其实我很清晰如果坚守在 LinkedIn，接下来的情形会如何发展。我要么留在那个随时可能给我的精神施以繁重一击的环境，要么就彻底摆烂，像具行尸走肉般依照上级下达的指导做事。前者可能摧毁我的身心，后者则会让工作变得枯燥乏味、毫无乐趣可言。

按前面那种方法，我当然可以试着用自己的小桨划水，让这艘泰坦尼克号转变航向。但这几乎不可能胜利，奋力抗争之下只会闹得自己遍体鳞伤。

如果是后一种，那我埋头划船就好，基本不用斟酌这艘巨轮是不是正驶向冰山。那座冰山就是规模扩展，这是 LinkedIn 终将面对的难题，而公司的基本设施基本就没有为此做好预备。

我最终选择了废弃。

这段阅历让我学到了很多，至少让我懂得到为一家科技大厂工作，尝试把 300 万行代码迁移至 TypeScript 到底是怎么回事。现在我可以转去做点别的事情，保留自己的精神或者说性命力。至少这样我用不着每天压制自己的情感，或者随时随地陷入瓦解。

人的一生如白驹过隙，我不想把名贵的几年时光糟蹋在自己基本不认同的工作方法上。请大家千万不要误解，我的分开不是出于怨恨、恶意或者其他负面原因，单纯是因为大家对人生的懂得有所不同。

也许 LinkedIn 的某些角落还残存着我所认同的、不那么让人反感的价值观，但很遗憾那并不是主流，我也无力转变。

参考链接：

https://devclass.com/2024/03/06/modernizing-legacy-code-at-linkedin-how-big-bang-versus-gradual-approach-caused-conflict/

https://corecursive.com/leaving-linkedin-with-chris-krycho/

https://www.youtube.com/watch?v=UOw7TydAT_s

https://www.reddit.com/r/programming/comments/1b69ntl/leaving_linkedin_choosing_engineering_excellence/

声明：本文为 InfoQ 翻译整理，未经允许制止转载。

摸索软件开发的新境界！QCon 全球软件开发大会迎来全新升级，现已华美转型为【QCon 全球软件开发大会暨智能软件开产生态展】。这不仅是一场技巧盛宴，更是深度交换与创新展现的交汇点。我们诚邀您于 2024 年 4 月 11 日至 13 日，莅临北京·国测国际会议会展中心，共同见证并参与这场融会技巧分享、深度研讨与前沿展览的综合性盛会。让我们携手开启智能软件开发的新篇章！

QCon 全球软件开发大会暨智能软件开产生态展即将揭幕，全面笼罩“人工智能 +”的典范案例！购票请接洽票务经理 17310043226 。查看「浏览原文」可懂得大会最新日程，等待与各位开发者现场交换。