从一开始就设计出完美的产品是不可能的。在某种程度上，你意识到你关心的用户类型已经改变，或者你为1999年设计了一些东西，或者你雇佣的设计师比你（工程师）有更好的想法。人们很容易忘记为未来而构建产品，尤其是当你认为自己知道产品的发展方向时。在过去的几年里，很多事情在设计和产品方面都发生了变化，这让我们重新思考我们的前端架构。这已经是很长的一段时间了，但是我们设计了一个新的前端架构，我们称之为Lightning，它能够处理我们即将到来的所有变化，而不会牺牲我们的构建速度。这篇文章是对我们提出一个新的前端架构的动机和我们采用的基本方法的初步了解。我们将在接下来的帖子中更具体地讨论我们所学到的东西。我们从哪里开始的当你认为你知道自己的方向时，你经常会写一些很难改变和重组的软件。这就是振幅前端架构所发生的事情。振幅最初是以一种非常特别的方式进行设计和设计的。它一开始只是一些选项卡：用户组合、事件、漏斗、保留等。随着时间的推移，这些选项卡随着产品的发展而成倍增加。保留发展为保留和粘性。用户会话和时间表诞生了。出现了一个SQL查询选项卡。以及增长发现引擎。向前，向上…。一次建立一个选项卡的振幅。每个选项卡都是一个独立的世界视图。当然，有些页面组件是可重用的——日期选择器、表视图、核心图呈现——但有相当数量的组件是一次性的。有一次，我们在产品中没有一个，不是两个，而是34个不同的日期选择器。较大的组件通常复制较小的通用构建块，而不是共享它们。更糟糕的是，每个选项卡获取并管理自己的状态，每个选项卡都加入了自己的本地风格，以了解如何处理它。为什么这是个问题？一切都慢下来了。每次改进或重构现有功能时，我们都会面临严重的业务成本：开发非常耗时。很难预测开发需要多长时间。引入回归很容易。在这个世界上生活了一段时间后，我们认为这是不可持续的。雷击！为了能够快速移动，我们需要一个基于组件和可重用构建块的体系结构。这成了Lightning的核心原则：创建构建块，而不是视图。同样重要的是，能够重新组织事物的布局方式，而不需要从头开始重新构建它们，并且能够在水平方向上改进特性，而不会在一个充满痛苦倒退的世界中结束。考虑到这三个目标，我们还必须后退一步，考虑我们需要将哪些工具和最佳实践融入到Lightning中。我们决定做出的一个重大改变是从角度出发，转而使用占地面积更小的框架/库，这将使我们能够灵活地选择适合工作的最佳工具。在这方面，React和Redux是两个明显的赢家。我们将在以后的文章中对此进行更多的技术细节。一次一个街区在充实了闪电之后，我们潜入并开始在我们的新架构中构建一个功能。第一个特性是痛苦的，原因很明显；我们不仅要从头开始找出最佳实践，还需要构建一个大型的组件库，以供将来使用。但当我们开始开发第二个功能时，投资开始有了回报。还有第三个。还有第四个。到目前为止，我们已经在我们的新架构中构建了几个特性，并从旧架构中迁移了一些旧的特性。我们看到了结果。我们看到了一致性、可靠性和开发速度的提高。我们在新体系结构中构建的特性的水平改进要比仍然在旧的遗留代码上运行的功能更快。我们正在利用我们已经打下的所有基础，非常快地迁移遗留功能。下一个是什么？我们已经看到了Lightning的许多改进，但有一个秘密：我们新架构的关键优势还没有到来。几个月前，我们聘请了我们的设计主管，并责成她重新思考"易于访问"的分析平台意味着什么。我们如何建立一个新手用户容易理解的平台？一个让人愉悦的平台？一个向客户传授分析价值的平台？我们还不知道这些问题的答案是什么，但我们知道这意味着改变。我们可能会彻底改革我们的信息体系结构，重新组织产品中的所有内容。否则我们可能不会。关键是，在前端工程方面，我们正在为自己做好准备，以便能够轻松应对这种变化。通过将组件和状态与它们在产品中的位置分离，新设计的细节并不重要。当然，当一个设计最终落地时，仍有许多工作要做，但我们将能够快速移动并更加灵活。当设计最终在最后关头给我们一个曲线球时，我们就准备好了。你对前端架构有自己的看法吗？我们正在招聘前端工程师，我们很乐意听到他们的声音！查看我们的职业页面了解更多信息。评论布伦南·克莱恩：对你为什么选择反应vs角度感兴趣。这个决定是否也考虑了Angular 2.0，还是仅仅选择React而不是pre-2.0 Angular？格雷格·琼斯：我们确实考虑过Angular2.0，但出于各种原因，我们选择了React。FE团队中的每个人都曾与React合作过，并有过非常积极的经验。对组合和高阶组件的关注也确实与我们的架构心智模型一致。最后，更广泛的FE社区似乎在React背后投下了很大的砝码，而Angular 2.0还没有证明自己——React感觉更安全一些。PersonalLife:Lightning框架是否是使用React+redux+routing、执行工作流任务等的特定方式？