Slack 的后端是用Hack编写的，它在HHVM上运行。代码库在过去几年中显着增长，今天一个新的克隆需要近 30 分钟。由于这种尺寸，运行 HHVM 已经成为资源密集型的，并且除了影响其他应用程序的性能外，还因为让工程师的笔记本电脑听起来像发电机而臭名昭著。
尽管没有强制性的单一开发环境，但大多数 webapp 工程师使用VSCode来完成他们的工作。VSCode 提供了广泛的扩展来支持多种语言，包括 Hack，具有语法高亮、格式化程序和 linter 等功能。多年来，Slack 工程师投入了大量时间来提出不同的策略来改善我们的开发体验。虽然它运作得相当好，但它总是很脆弱。
最初的开发工作流程涉及直接在 macOS 上运行 HHVM，它遇到了自己的一组常见问题：自制程序破坏安装、升级失败以及在发布新版本的 HHVM 时必须赶上进度。由于 HHVM 更新的频率，这成为了一个主要的痛点，给工程师带来了开销和频繁的中断。
由于初始工作流程的限制，下一次迭代将所有 HHVM 依赖项移至本地 docker，使工程师更容易保持同步。这需要大量自定义脚本和服务来构建用于使用 HHVM 运行 webapp 的 docker 映像。尽管这个解决方案解决了很多不一致的问题，但它带来了新依赖项的开销，例如 docker、维护 HHVM 构建映像以及将所有内容放在一起的自动化脚本。
虽然这比以前的工作流程有了显着的改进，但从我们内部 docker 自助渠道的高流量来看，显然需要做更多工作才能获得顺畅的开发体验。
详细点击标题