不：从mapStateToProps返回新数组或新对象。如果要返回一个对象，请确保它以后不会被更改。当该对象发生哪怕最轻微的变化时，这可能会导致整个组件和子树被重新渲染。 

Do：mapstateToProps 应该只返回直接来自状态的基元和数组（不要从 mapStateToProps 创建新数组，如果需要，创建一个选择器来缓存参数计算结果数组）。稍后将迭代的数组应包含要呈现的项目的字符串 id。列表项负责使用从 props 传递的 id 查找全局状态信息。

Do：构建您自己的自定义钩子时，请确保要返回的数组也被记住。不成熟的优化不被认可，但为什么不以最优化的方式构建一些东西，它不需要花费大量的精力，并且可以促进其他处理代码的工程师的学习。提升团队技能！

Do：构建大型对象时，按字母顺序对键进行排序。对象的大小可能会增加，并且搜索属性可能非常耗时。尤其是商店，请确保减速器按字母顺序排序。

不要：构建特定于您正在构建的页面/屏幕的减速器。想想它如何扩展到其他页面/屏幕。咨询团队以了解您正在构建的页面/屏幕未来可能的用途。

Do：确保使用定制的 API 封装与外部 api 的通信。将来如果需要更换服务，可以通过这个定制的 API 来完成。以 Bugsnag 为例。将那个男婴包装在定制的 API 上，以防万一您想使用 Sentry。

Do：同样的注释。请标准化后端和前端处理错误的方式。应用程序中的每个操作都应该包装在 try/catch 块上，并且 catch 块将报告发送到错误报告工具。您的应用程序还应该用错误边界包装整个应用程序。我相信有一种适当的方法可以建立正确的模式。一种能够捕获所有错误并报告有意义的信息的模式。

Do：使用 Sonar 等强制代码质量的工具，这将在代码审查期间节省大量时间，因为有人决定使用 if ... else 而不是 if ... return 。小细节会降低开发人员的创造力，而只是遵循声纳代码质量标准的要求。从第一天起，即使是遵循这些细节的代码库也很容易编码。

结论

这就是我目前的所有看法。有了一个强制模式的代码库，人们可以从代码库的其他地方获取一段代码，粘贴它，稍微改变一下措辞等等，你就拥有了一个以各种可能的方式满足生产标准的功能。虽然有一些观点，但至少在撰写本文时确实存在一种最高效的做事方式。可能会出现其他方法，但在编写代码时最高效的编写代码的方法是编写代码的唯一方法。说起来容易做起来难，直到你遇到最后期限的怪物。