VIP Data

因此，我们没有重新实施此解决方法，而是与后端团队密切合作，以建立适当的端点。这稍微推迟了项目，但我们希望确保为团队建立更具可扩展性和面向未来的基础。

当我们开始一个新项目时，尝试新技术或新库是相当诱人的，尤其是当它们很流行时。

事实是，JavaScript 世界瞬息万变，今天流行的内容可能六个月后就不再流行。为了避免不得不重新开始，最好选择已经证明稳定的库。

此外，无论库多么流行，它都不一定能满足您的需求。要避免的一个错误是？修改代码以适应库（它应该始终以相反的方式工作）。

在我们的案例中，我们投资了 xState，认为它会让我们的代码更加健壮。我们围 波斯尼亚和黑塞哥维那数字数据集 绕它开发了一整套生态系统，以便尽可能顺利地将其集成到我们的代码中。

然而，经过几个月的测试，我们发现它并不适合我们。从那时起，我们不得不重构大量代码才能摆脱它。

如果我们坚持使用标准库，我们就可以避免这个问题。

每次只关注一个功能，并逐步交付
在重写仪表板时，我们决定一次性交付所有内容。我们认为这比逐步交付功能更容易。这无疑是我们最大的错误之一。

第一个问题是什么？我们没有在整个项目过程中设立多个里程碑，而是在项目结束时只设立了一个大里程碑。

结果，我们开始开发很多功能但仍然没有完成任何事情——即使经过几个月的开发。

从团队激励的角度来看，这显然不是一个很好的体验。除此之外，我们无法进行任何用户测试，所以我们不确定我们正在做的事情是否成功。

因此，我们最重要的收获是始终尝试找到一种方法来逐步实现您的功能。

在我们这边，我们将旧仪表板嵌入到新仪表板中，作为尚未重写的每个页面的后备。从那时起，我们逐渐能够用重写的页面替换嵌入的页面。

预测未来
从头开始重写应用程序固然令人兴奋，但一旦完成，您就不会想很快再做一次。为了确保这一点，您需要采取一些预防措施。

对于我们来说，我们知道我们最终会从REST API转向 GraphQL API。但是当我们开始重写时，GraphQL API 还远未准备好，所以我们必须使用 REST API。

问题是，我们知道迁移不会是一件容易的事。因此，我们从一开始就通过实现 Apollo 客户端（使用 apollo-link-rest）使迁移尽可能简单。