这些原则告诉我们，我们应该只提供组件发挥其功能所需的功能，并且我们应该始终通过高级代码中的一些抽象来行动。这些的目的是能够大幅度更改实现细节，例如数据库提供程序，而不必重写大面积的高级代码
DIP 告诉我们，我们应该始终通过抽象与低级细节进行交互，从而“将布线隐藏在墙后”。[13]这与上面详述的 SRP 和 ISP 有很强的联系。实际上，对于 React 前端，这意味着我们高级代码中的函数不应该关心特定任务是如何完成的。例如，假设我们想调用一个 API 来获取待办事项列表——就像我们在上面的 SRP 部分中所做的一样
们可以读懂这个原则背后的想法，并将其转化为我们可以在 React 代码中使用的东西：只给组件提供它们需要的东西。这意味着实现细节对任何特定的高级功能都无关紧要。
如果 B extendsA，那么我们应该能够在我们使用 A 的任何地方使用 B，而无需改变任何功能。我会直言不讳：我们只是没有真正在 React 中使用它。如今，无论如何，所有代码都应该使用类上的钩子来编写，因此类在现代 React 代码中的作用应该非常小。本节为后代而存在，但这肯定是应用于前端设计的不太相关的原则之一
我们应该能够添加新功能而不必重写部分代码库。
每个函数/类/组件都应该只做一件事
一般来说，好的代码的特点是混合了三样东西： 功能性：代码组合在一起以创建所需的功能。 可维护性：很容易进行更改、添加新功能以及让其他开发人员理解代码的功能。 健壮的：由于有一个很好的测试套件，软件很难被破坏，并且在错误发生时会适当地处理错误。 然而，这引出了我们如何才能实现这三件事的问题。
最近公司做整合，因为母公司收购了很多子公司，打算统一团队，统一技术，前后端都采用typescript做开发，分成了二三十个团队，每个团队十个人左右。最终我们选择了敏捷框架 (SAFe)进行团队的管理。
现在流行使用typescript进行申明，很多初学者只能使用一些简单的声明，当类型复杂之后就会不知所措。
使用react-testing-library常用的错误
