我们重写公司电子商务网站的目标只有一个：利用 SSR 服务器端渲染技术提供极快的性能。

在此之前，网站运行状况良好的时候，JavaScript 包大小为 168MB。在一台顶级 MacBook Pro 上，开发环境需要 3 分钟才能有响应。工程师们经常来上班，输入 npm run dev，然后去喝杯咖啡，而这些机器的风扇却始终无法满足我们庞大的项目对他们的要求。

到底是哪里出了问题？

背景介绍

公司的第一个网站是一个使用 AngularJS 开发的单页面应用程序。AngularJS 不支持服务器端渲染，因此网站在首次加载时渲染速度较慢，但在下载所有内容后速度很快。

对于 Web 而言，响应的毫秒至关重要，对于电子商务来说更是如此。所以我们需要缩短首次渲染的时间。

Angular 2 进入了团队的视线，虽然它与 AngularJS 大不相同，但似乎是新网站开发的合理基础。甚至还有一个试验性的服务器端渲染功能正在积极开发中！在准备交付，这项功能肯定已经准备就绪了！

团队在构建网站时，定期将实验分支中的最新变更合并到代码库中，并处理可能出现的任何 Bug。

我是在网站功能完成前两周加入团队的。虽然最后期限早过了，但大部分页面已经完成，关键功能也都正常运行。我的工作就是完成并交付项目。

然而，唯一缺少的功能就是完整的 SSR （Server-Side Rendering）的全面支持。SSR 可以工作，但并不能摇树优化（tree- shaking）去除死代码，而且 AOT Complier（Angular 构建管道中的关键步骤）会产生巨大的包。

我们花了三周时间从积压的工作中挑选出 "必备功能"，其中包括令人印象深刻的 nginx 图像缓存（这是另一个故事了）。我们每天都会检查 Angular 储存库，希望关键的修复能够落实。

我们用完了所有的 "必备功能"，又花了两周时间在 Angular 团队的 SSR 分支上进行黑客攻击，但庞大、陌生的代码库和难以克服的错误让我们陷入了一场艰苦的战斗。这个项目属于探索性质的开发，而实验性质就意味着文档的匮乏。

我们耗费了大量时间，却一无所获，但在离终点如此之近的时候放弃，又觉得是一种浪费！

经过一周的时间，我们没有取得任何实质意义的进展，上游也没有采取任何行动，我一筹莫展。管理层给我的压力越来越大，我们的竞争对手当然不会等着我们迎头赶上，而企业又需要这个项目。

我们没有明确的产品交付途径，但我们有能力重新开始吗？

💡 我们陷入了 "沉没成本误区"（Sunk Cost Fallacy）：因为害怕失去已经投入的资源，我们在一个失败的项目上投入了更多的资金、时间和资源。

如果不加以解决，必然会导致更大的损失。

我度过了一个不眠之夜，思考所有导致我们如今处境的决策。根据经验，我知道 React-Redux 状态管理库拥有成熟的 SSR 支持。

我曾亲眼目睹过一个积极进取的团队使用该堆栈的进展有多快，但放弃将近一年的工作会严重打击团队的士气，也很难向上层管理者交差，因为他们一直在等待这项工作取得成果。

这也违背了我对”大爆炸式“改写的所有初始看法。

从新开始

这项工作最难的部分不是技术，而是人。第一个挑战是获得创始人的支持。为此，我承诺了两件事：

1. 我将保持对 Angular SSR 项目的跟进，如果项目完成，我们将立即发布 Angular 网站，并且：

2. React 网站将在 6 周内实现功能和性能，并在 10 周内发布。如果没有，我就会辞职，然后招聘一个人接替我。

第一个承诺是常识，第二个承诺则是从经验中树立的自信。我曾用 React 构建过一个 SSR 网站，知道它的工作原理。从创始人的角度来看，如果事情不成功，他们已经有了明确的止损方案。

更关键的挑战在于如何获得团队的支持。在我加入之前，他们已经在这个项目上花了几个月的时间，而现在我却提出要毁掉这些辛勤工作。更糟糕的是，我设定了一个疯狂的最后期限！他们需要相信这是可行的，而且是正确的选择。

我必须向团队推销 React 堆栈，我想唯一的办法就是 DevEx。我必须向他们展示，在没有工具阻碍的情况下，他们的工作效率会有多高。

基于此，我启动了一个服务器端渲染的 React 项目，并选择了一个单一的流程来实施。我设定了一个雄心勃勃的目标，即在一天内交付完全相应并支持 SSR 的网站主页。

每个人都被浏览器中的热模块重载和实时重新渲染所震撼。在之前的项目中，在状况良好的时候，他们需要等待长达一分钟才能看到自己的修改，而现在这就像变魔术一样。虽然还有人对网站其他部分建成后是否仍能保持这种性能持怀疑态度，但这次演示足以让团队投入到自己的尝试中。

💡每个人都喜欢得到快速的反馈。即使等待很短的时间才能看到变更的影响，也会扼杀效率。

注重投资可以加速测试套件或寻找性能更高的构建系统，可以收紧这一环路，并直接提高团队的参与度和工作效率。

第 2 天，我们将网站分成 20-30 个关键用户故事（User Story），其中许多是第一次尝试时重复使用的，确定优先级后开始交付。

新的试运行网站已经上线，并向整个公司开放。在第一周结束时，看到团队在如此短的时间内取得了如此大的进展，任何可能还存在的怀疑都被打消了。

最终交付 

经过团队 7 周的集中努力，我们及时交付了新版网站，赶上了本年度最大的购物活动之一。新版网站运行速度极快，使用的资源远远少于我们最初的 AngularJS 网站，而且我们编写的代码在几年后的今天仍在生产中使用，尽管网站从那时起已经发生了很大变化。

具有一流 SSR 支持的 Angular Universal 最终也出现在 2018 年 4 月发布的 Angular v5 中，此时距离我们完成重写只过去了 6 个月。

这个项目打破了软件项目管理的两个基本规则：

1. 不要使用实验性技术构建生产应用程序

该网站的 Angular 版本是基于实验性的、未经证实的、仍在积极开发中的技术构建的。

这是一个完全无法管理的巨大外部风险--Angular 团队交付产品的能力未知，而他们对我们企业而言并无特别责任。

如果我们继续等待，那么我们将在 9 个月的时间里毫无业务价值可言，项目时间也将延长一倍。

1. 不要进行 "大爆炸式 "重写

决定用 Angular 2 重写整个网站，而不使用逐步发布的强制功能，这一决定导致团队早早地陷入了最大风险之中。

如果项目成功的衡量标准中包含了逐步发布的要求，那么在开发周期的更早阶段就会出现如何真正发布网站的讨论。

“等等，"精明的读者可能会说，"React 项目不是一个大爆炸式的重写吗？“

1. 额外收获：了解规则，才能知道何时打破规则

为了保持团队士气，我有意识地决定打破这一规则。

我寄希望于最先进的 React 项目所提供的良好开发人员体验来保持团队的积极性。将 React 强加到传统的 AngularJS 项目中是无法实现这一目标的，而且在构建了几个月的 "下一个 "之后再回到旧代码会给团队带来沉重的打击。

这是一个非常审时度势的决定。如果我们没有摆脱失败的 Angular 2 项目，我肯定会推动使用 React 和 AngularJS 之间兼容技术，从网站发布第一天起就逐步过渡。

💡作为一名主管，你必须打好手中的牌，而不是你希望自己手中有的牌。每种情况都是独一无二的，你所做的每个决定不仅要考虑到产品，还要考虑到打造产品的人。

有时，这意味着你要打破既定规则，但这些规则是有原因的，所以不要养成习惯。

推荐阅读：

▶每天工作 1 小时，谷歌程序员“摸鱼”后年入 15 万美金，其他时间搞副业？

▶三天召集 2200+ 名黑客，齐向 AI “投毒”：“50 分钟内骗过 AI，第一名可获英伟达高端 GPU！”

▶“从未写过一行代码的我，刚刚通过了谷歌系统设计面试！”