构建我们桌面应用程序的未来
在过去几年中，我们已经通过为桌面应用程序和Web播放器创建一个桌面UI来实现Spotience客户端的使命。
我们无法使用我们的旧设置构建我们想要为用户的一切，所以我们决定做一些事情。
在2018年底，我们的团队是最近建造的Web播放器的所有者，以及Spotify的桌面客户端。桌面是我们丰富，全功能的经验，Web播放器是更轻，更简单的体验。由于Web播放器使用了现代React应用程序架构实现，因此我们将新工程师造成了成功的Web播放器代码。但同样的工程师遇到了桌面客户的困难，它使用了非常多样化的网络技术（归功于康威的法律）。由于必须在处理上下文切换的同时在不同程度的复杂程度下实现许多特征，我们不是在我们希望的步伐上发货。
此外，我们需要解决的客户中有可访问性问题。我们发现，让我们的网络播放器可访问，这将是一个困难，但可实现的，挑战。相比之下，使桌面应用程序可访问，几乎是不可能的。我们有很多关于如何解决这些问题的讨论。该团队认为，将客户融入单个代码库和用户体验将是前进的最佳方式。我们考虑了几种方法，并进行了技术飙升，以测试许多思想 - 组件共享，功能分享 - 始终试图在继续提高用户的经验时发现我们的技术债务问题之间的正确平衡。
我们知道我们正在开始长期的项目，所以我们最大的优先事项是向风险交付，避免将自己陷入大爆炸重写。我们解决了一个粗体解决方案：专注于迭代现有的Web播放器代码库，直到它到达桌面级功能集。由于我们的网络播放器被连续部署，我们可以通过针对我们最终目标所取得的每一项变更，以真正的用户发货和测试。
当然，有风险。 Desktop拥有（并且已经）更多的用户而不是Web播放器，而Spotify的桌面客户端是大多数Spotify的“Power用户”致电回家的地方。我们知道我们会有很多工作要做，使我们的网络播放器达到那些权力用户的严格标准。
现在，在2021年初，我们为我们的客户创建了一个可维护的代码库，具有我们希望的高标准的可访问性和发展速度。
让我们更详细地讨论我们如何将想法变为现实。
Spotify Desktop Client是一种Windows和Mac本机应用程序，它使用CEF（Chromium嵌入式框架）来显示基于Web的用户界面。今天仍然是真的，但对于先前的桌面版本，客户端中的每个“页面”都是一个独立的“应用程序”，以在自己的Iframe内运行。这种体系结构旨在促进自治，允许多个团队 - 以及潜在的合作伙伴 - 拥有特色的开发和维护。然而，最终，一个团队对整个应用程序的用户界面负责。
以前版本的桌面客户端具有许多优势，包括Spotify从其第一个客户端的原始“杀手功能”，这将允许播放只要侦听器点击即可。它还拥有一系列全面的功能，我们知道Spotify侦听器价值。但是，与此同时，这种架构对开发人员造成严重摩擦。
然而，Web播放器的Codebase被认为是一个更坚实的基础，以建立在上面。它允许我们快速开发新功能。它是用网眼商开发的，这意味着它的大小很小，更加表现，并与各种浏览器合作。客户端持续交付，允许更改几乎立即到达用户。然后，我们决定使用Web播放器作为Web播放器和桌面之间共享的单一用户体验的起点。我们遇到的主要挑战之一是这种方法将要求我们使用桌面容器运行Web播放器UI。 Web播放器也紧紧耦合到我们的Web服务器，依赖于所有数据和身份验证。 Web播放器使用的播放系统与桌面不兼容。身份验证的工作方式不同 - 我们需要在Web播放器上支持我们的Web OAuth登录，并在桌面上登录。桌面还需要其用户预期的功能，例如Web播放器不支持的下载和脱机播放。
在两个类似但不同的基础架构上运行相同的用户界面的这种概念是我们开发的架构的信息。为了保持UI平台不可知论，我们构建了摘要不同数据和不同播放堆栈的类型的标注平台API，以及为用户界面提供有用的信息，了解它是什么功能。我们还沿途重新写入整个客户端，因为我们正在重建逐点体验。
虽然在我们的团队之外完成工作以通过网络制作某些类型的数据，我们专注于不仅从Web服务器解耦，而且来自任何硬编码依赖性在正常浏览器中运行。
最终体系结构看起来像一层平台API，将底层Spotify生态系统公开给客户端，并通过基于反应的用户界面和通过React Hops公开的平台API。因此，新UI可以在Web上运行，并且如果数据来自我们的C ++堆栈或我们的Web基础架构，则可以在我们的桌面容器中运行，并且永远不会知道或护理。
通过这种架构到位，团队的速度开始迅速增加。我们添加了下载，脱机模式，本地文件，歌词，“现在播放”队列，以及播放列表和专辑的分类和过滤等高级功能。在一年多的时间里，新的共享UI包括原始桌面客户端的所有功能，并且在某些区域实际上是更高级的，包括先前仅在移动客户端上看到的功能。
从我们决定新桌面客户的产品战略的那一刻，我们开始解决工程挑战 - 但也有组织挑战：我们如何在不放弃每天的合理时间内怎样让这一切发生这种情况。像往常一样的业务“需要继续的工作？
还有一个很大的信息差距我们必须解决。现有桌面应用程序中的哪些功能必须在新的桌面应用程序中实施？新客户应该是什么样的？几乎立即立即设计和产品洞察团开始调查我们的用户如何使用我们的软件，以便我们可以朝向能够发货的路线图。
与此同时，我们创建了一个小型的“虚拟团队”由几个团队开始的工程师，开始第一个工程实验并回答一些基本问题：甚至可能是所需的解决方案吗？它实际需要多少工作？此虚拟团队的优先级简单地获取Web播放器，就像在桌面容器中运行一样。他们将解决播放和身份验证的问题，探索UI如何与容器捆绑在一起，并为其其余部分设置工程蓝图。该团队由Spotify中的其他团队辅导，以创建一个可以在具有不同功能的多个平台上运行的单个UI - 例如电视。由于以前的努力汇聚客户是促进这项任务的关键，因此代码库共同位于同一MONOREPO中。
三个月后，团队的工作成功结束。我们建立了我们的路线图和优先事项，我们确切地了解即将到来的年份。它需要我们更广泛的团队中的每个人都充满承诺，并持续测试和分析，以确保我们在正确的道路上。
实际上，这个项目才会发生，因为我们的工程，设计和产品管理团队设想了工程师可以快速迭代的产品，这将完全支持Spotify Vision。我们不得不迭代比我们在发货到用户之前的时间更长，但是团队能够在新的共享UI中实施这些功能的速度是让每个人都朝着正确的方向前进的信心。
我们在这个项目开始时有四个主要目标：使我们的代码可重复使用，统一用户体验和视觉设计，提高速度更快地提供，并在满足桌面和网络播放器用户的需求时进行所有这些。随着项目的结果现已发货，我们如何针对这些指标进行？
在多个客户端中重用相同的代码（即，Web播放器和桌面）允许我们编写一次代码并在多个位置中获益。当我们需要实现设计变更时，使其在一个位置中更有效，并且它将其传播到所有接收端点。我们希望在将来扩大我们的可重用性，将更多的平台API与更多的客户共享。
用户体验和视觉设计是在应用程序中改进的重要又耗时的区域。因此，具有一组服务多个客户端的组件可确保我们可以更彻底地实现设计，从而提高用户的经历。
批判性地，我们已经能够通过Spotify生态系统的其余部分实现一定程度的统一，使我们的客户迁移到Spotify的共享设计语言。结果是当用户在移动设备和桌面之间切换时更加一致的经验，以及为每个人提供更现代化的，现代，可访问的和面向用户的体验。
这个项目的一个重要理由是具有单一，易于理解的架构的现代化码布的论点将使我们的速度增加为工程师。虽然我们需要更多时间来长期证明成功，但是由于该项目开始以来，该团队已经完成的大量功能是一个积极的指标。然而，速度仅仅是一个结果 - 工程师的结果，具有清晰的目标，使用健康的码比。我们在测试覆盖范围，可维护性，可读性以及删除的简单代码方面测量代码健康。我们选择的架构在制作UI编码方面具有意外的好处，更简单，更容易理解开发人员，因此我们希望这个平台将成为我们在未来几年内建立的坚实基础。
新的经验已经通过Spotify用户 - 既有现有的桌面电源用户，以及来自移动应用程序的新用户或全新的Spotify Ecosystem。从一开始，我们一直在评估和测试我们在每步的进度，以确保我们提供满足用户需求的经验。我们已经在过去一年中开展了广泛的用户研究，并在过去一年中运行连续测试，我们向我们提供了我们应该采取的方向。我们已经使经验更容易获得，所以每个人都可以使用应用程序享受。
我们正在仔细研究收到的反馈，并不断塑造应用程序以满足用户的需求。新架构让我们更快地移动，用户可以预期客户比以往任何时候都更快地发展。
作为使用Spotify Desktop客户端或Web播放器的音乐监听器，我们希望它感觉像一个新的新体验，但是您使用的所有功能都在那里。您将注意到您在第一次出现的Mobile上可能看过的一些新功能。随着时间的推移，你会开始注意到更频繁地出现的全新功能，让您的音乐和播客更好。为我们推出新桌面，不是结束。它只是应用程序在Spotify的一切开始的应用程序。
想加入乐队并建立Spotify的未来？ 前往我们的工作委员会，看看有什么东西抓住你的眼睛。 我们刚刚宣布从任何地方的政策工作，这使员工可以在办公室全职或两者组合在办公室全职工作。 对那些为这个项目做出贡献的每个人，特别是Felix Bruns，Peter Johansson，AlbertonúñezAcosta，Guido Kessels，Tryggvi Gylfason，Craig Spence，Lucas Lencinas和Emma Bostian的每个人都会喊道。
