我们还知道熟悉原始技术堆栈（尤其是后端）至关重要，因为这是我们最依赖的。
在我们的案例中，API 的文档记录并不完善。因此，我们花了很多时间对现有仪表板进行逆向工程，以记录所有端点。
在此过程中，我们注意到了一些技术限制，这让我们重新考虑了为特定功能规划的规格和设计。
说到技术限制，我们还发现，为了在前端进行弥补，实施了一些肮脏的变通方法。
例如，在旧仪表板中，我们能够搜索号码、用户或团队。问题是，我们没有任 澳大利亚 WhatsApp 号码数据 何允许在后端使用搜索功能的端点。搜索实际上是在登录后加载所有客户数据在前端执行的。
一开始还好，因为 Aircall 主要与小型企业合作。随着规模扩大，仪表板开始出现延迟（有时需要几分钟才能加载）。
因此，我们没有重新实施此解决方法，而是与后端团队密切合作，以建立适当的端点。这稍微推迟了项目，但我们希望确保为团队建立更具可扩展性和面向未来的基础。
. 不要陷入“流行的第三方库”陷阱
当我们开始一个新项目时，尝试新技术或新库是相当诱人的，尤其是当它们很流行时。
事实是，JavaScript 世界瞬息万变，今天流行的内容可能六个月后就不再流行。为了避免不得不重新开始，最好选择已经证明稳定的库。
此外，无论库多么流行，它都不一定能满足您的需求。要避免的一个错误是？修改代码以适应库（它应该始终以相反的方式工作）。
在我们的案例中，我们投资了 xState，认为它会让我们的代码更加健壮。我们围绕它开发了一整套生态系统，以便尽可能顺利地将其集成到我们的代码中。
然而，经过几个月的测试，我们发现它并不适合我们。从那时起，我们不得不重构大量代码才能摆脱它。
如果我们坚持使用标准库，我们就可以避免这个问题。
. 每次只关注一个功能，并逐步交付
在重写仪表板时，我们决定一次性交付所有内容。我们认为这比逐步交付功能更容易。这无疑是我们最大的错误之一。
第一个问题是什么？我们没有在整个项目过程中设立多个里程碑，而是在项目结束时只设立了一个大里程碑。
结果，我们开始开发很多功能但仍然没有完成任何事情——即使经过几个月的开发。
从团队激励的角度来看，这显然不是一个很好的体验。除此之外，我们无法进行任何用户测试，所以我们不确定我们正在做的事情是否成功。