https://www.pivotaltracker.com/blog/Elm-pivotal-tracker/

Jeff Schomay•2017 年 1 月 31 日，星期二

在 Pivotal Tracker 中，我们拥有许多不同技术堆栈的大型产品，其中有些是 Rails RJS，有些是纯粹的 jQuery，很多是 Backbone，有些是 React。我们尝试了 Redux 一段时间，虽然架构很好，但它增加了太多的复杂性，特别是当我们尝试将其与现有的 Backbone 代码进行整合时。

然后我们尝试了榆树。起初有很多怀疑，怀疑和恐惧，但是在通过几次试运行后，它证明了自己的最大可能的方式。我们获得批准在榆树建造新的仪表板。虽然我们一开始就和榆树一起长大了，但总体来说还是很好，最近才发布。

体验

如果您已阅读任何使用榆树的公司的其他帐户，本节可能会听起来像是破碎的记录。起初，新的奇怪的语法和功能范式吓倒了一些开发人员，但是我们大多数人在不到两天的时间里就被抓住了。学习思考“FP”可能具有挑战性，但 Elm 可以帮助您。

更好的是，与榆树工作是非常愉快的。这些工具使开发变得如此容易和无摩擦，并且编译器使得重构系统成为可能。我们已经在一天内重构了整个文件系统，没有任何回归，这在我们的其他代码库中几乎是不可能的。

总而言之，开发人员正是在早晨的阵容中投标 Elm 工作的故事。

产品

我们的最终成果一直很好。我们没有运行时失败，文件大小可以小得多，而且运行速度比我们的代码库中的任何事情都要快。我们也有更少的错误，主要是因为 Elm 的类型系统强制您更仔细地对域进行建模。

总而言之，我们的经理要求所有新的代码都写在榆树中。

挑战

尽管有积极的经验，我们仍然面临挑战。学习如何组织一个大型应用程序需要一段时间才能得到正确的解决方案 - 但仍然可能会让新来的人感到困惑 - 但是我们已经到达了一个我们很高兴的地方。与我们的 Rails 应用程序和构建/ CI 周期集成是棘手的。我们最终找到了一个反应轨道和 webpack 的组合，以允许“热重新加载”开发环境，并编制铁路资产管道使用的静态资产。我们使用 package.json 脚本将它们捆绑在一起，包括我们的 Elm 测试。

我们在 Pivotal 的一个特别障碍是将我们的思维从传统的“TDD”方法转变为“类型驱动开发”方法，并学习如何编写不需要测试的代码，同时仍然能够充分覆盖我们的业务逻辑。

最后，我们想出了对我们工作很好的模式。

樱桃在上面

Elm 0.18 增加了一个“时差调试器” - 一个很快成为不可或缺的工具。在以前的版本中，我们仅限于使用日志语句来检测我们的代码，需要清理并猜测代码路径。新的调试器在开发构建中始终处于活动状态，这意味着我们可以在发现错误状态之后打开它，并进行更深入的调查。另外一个优点：在您的懒加载消息回来之前，可以快退，以检查加载状态，而不会在开发工具的限制设置中出现问题。

另外，我想象大多数开发人员恐惧的挑战是完全被打败的：IE 独家的 bug。调试器的状态表立即显示原因：输入事件触发的更新消息被频繁发送。这个导致我们直接向 MSDN 提供了一个错误报告。从复制直到识别，无需特殊仪器！ （只是一些额外的逻辑在缺陷周围工作。）

结论

榆树的贡献者理查德·费尔德曼（Richard Feldman）曾经在介绍 Elm 的时候表示：“让后台团队嫉妒”。在我们使用榆树的经历之后，我们可以确认这一情绪。