早读《What Are the React Team Principles?》

https://overreacted.io/what-are-the-react-team-principles/

这篇文章 Dan 帮我们看到 React 团队是如何运作的，有点意思，由于提取精髓，因此略有删减。

整个 APIs 的设计是从用户体验这个视角来出发的，因此这些 APIs 并不是纯的工程角度。那我们知道前端的用户体验主要还是在 UI 的还原上，抽象一层是不是能更好的还原 UI ，这是一个很有意思的设想（这个角度还是还原了前端的本质，我们是搞UI界面的啊，同学们）。

如果你看过 React 的源代码，就能明白其内部实现和结构有多复杂，他们的设想是希望产品的开发人员可以尽可能的简单，并从整个系统中受益，并且如果因为开发者的简单而使 React 变的复杂，他们也愿意进行改动（不怕说代码很脏，结构很乱，只要能解决问题）。

从安全的角度来说 React 团队希望开发者能尽早的发现变更的全部效果，因此会有很多警告以及文字性的描述来提醒开发者，这一点上我也觉得 React 团队的设计，是符合整个社区期望的，如果有一天我们也做开源的事情，我们就必须要很慎重的对待任何的变动，我们必须假设开发者无法理解你的所有实现（尽早的让开发者知道你的变更）。

在复杂和简单中做了一个权衡，选择一个适合自己的路去走，因此 React 的设计会照顾这方面，他们的设想是说，实现复杂的事情和实现简单的事情，并没有什么不同，如果为了实现简单的事情而造成了麻烦，这很不可取（尽早的让用户使用，并得到反馈）。

如果我们已经意识到了某种方法的局限性，并且很阻碍用户体验这一层，他们就会立即放弃，因为他们团队已经形成了一个最大公约数，就是如果有一个方法是有意义的，哪怕多年，他们也会去实现（目标明确，就撸起袖子开搞，直到胜利）。

那么从这个角度来看，我们就能看到很多 React 的运作思路，相信你在控制台肯定也看到过很多信息，这些信息有时候还是很有用的。另外每一个方案，React 团队都是很慎重的去考虑清楚，不过多的干扰，而是从本质上出发，我们的本质是什么？最优的 UI 实现其实就是用户体验。

其实这些设计原则，好像也是我们工作的原则，如果你维护一个产品，或是有一个大的团队一起协作，这些原则其实是可以适用的。