【译】React团队的技术准则

更新日期: 2020-01-06阅读: 1.8k标签: 技术
本文翻译自react团队核心成员Dan Abramov的技术博客。地址:https://overreacted.io/
本文首发于公众号:符合预期的CoyPan

我React团队工作的这段时间,很幸运能够看见 JordanSebastianSophie 和其他团队成员是如何解决问题的。在本文中,我会把从他们身上学到的,浓缩为一篇较高层次的技术准则。这些准则未必详细。它们都是我对React团队的观察和整理 —— 其他团队成员或许有其他的观点。


UI优先于api

当我们把抽象概念大规模用于实践时,难免会有怪异之处。这些怪异之处是如何在用户界面上呈现的呢?你能看出一个应用中包含了哪些特定的抽象概念么?

抽象概念对用户体验有直接的影响 —— 它能创造好的、延续性的的体验或者限制某些东西。这也是为什么我们在设计API时,并不会从抽象本身开始。相反地,我们会从用户体验开始,然后再回到抽象概念。

有时候当我们回到抽象概念时,会发现必须更改整个方法,才能达到正确的用户体验。如果我们先从API下手,就无法察觉到这点。所以,我们将UI放在API之前考虑。


吸收复杂性

简化React内部的实现并不是我们的目标。如果产品开发者可以使用React写出更易于理解、易于修改的代码,我们乐于把React的内部实现变得复杂。

我们想把产品的开发变得更加职责分明,易于合作。这意味着我们必须把负责的部分封装在React的内部。React不能被切分为小规模、耦合松散的模块,因为这样便无法工作。React的使命是成为协调者的角色。

通过提升抽象层级,使得产品开发者更加有力。产品开发会从React的可预测的完备系统中受益。这意味着我们推出的每一个新功能,都必须兼容已经存在的功能。设计和实现React的新功能十分困难。这也是我们核心功能并没有收到太多开源贡献的原因。

我们吸收了复杂的部分,防止他们污染产品的代码。


从Hacks到Idioms

每一个Api都有一些局限性。有时,这些限制会妨碍我们打造良好的使用者体验。为此,我们提供了一些后路(escape hatches)以供需要时使用。

Hacks并不是长久之计,因为他们很脆弱。开发者必须决定他们是否维护,支持这些Hack,或者移除hack而牺牲用户体验。通常大多数人会牺牲用户体验,不然这些hack也会有可能阻碍用户的优化。

我们需要让产品开发者使用这个后路,并观察在他们实践中都是如何使用的。我们的目标是提供这类实现一个常用的解决方法(idiomatic solution),目的是达成更好的用户体验。有时候,一个解决方案,会花费我们数年的时间。我们更倾向于有弹性的hack来确立完整的习惯用法(a poor idiom)。


实现局部开发

你无法在代码编辑器做太多的事情。你可以增加几行,移除几行。或者复制粘贴。但许多抽象概念让这些基本操作变得困难。

比如,MVC框架让删除一些render的操作变得不可靠。这是因为及即使你删除了childern的方法,parent仍有可能执行它。相比之下,React的优势在于:你通常能安全的删除某些render tree内的代码。

在设计API时,我们会假设使用它的人只熟悉他们会用到的局部代码的相关知识。如果预期发生的影响只发生在这局部的代码中,我们将会避免意料之外的结果。例如,我们通常假设新增代码时安全的。在移除和修改代码时,应该清楚指出这些改动会连带影响、应该被考虑到的部分。我们不应该假设改动单一文件需要对整个代码都了解。

如果某一项改动不安全,我们希望开发者能够尽早发现这个改动所带来的的影响。虽然可以使用警告、类型检查和开发者工具来帮忙,但它们都受限于API的设计。如果API不够局部性,局部开发就不可能实现。例如,finddomNode就不是一个好的API,因为它需要全面的了解。


渐进的复杂度

有些框架会选择在开发的路上分出岔路,提供两种路线:简单的方法或强大、完整的方法。简单的方法容易学习,但你终究会走到他的极限。这个时候,你必须推倒重来,重新使用另外一套方法来实现。

我们认为实现一个复杂的东西,和实现一个简单的东西,在结构上没有太大的差别。我们并不会简单的状态提供简单的写法,因为这样会使开发中出现岔路。如果我们认为开发者在开发过程中想要完整的开发工具,我们愿意牺牲低门槛来达成这件事。

有时,【简单】和【强大】代表两种不同的框架,那么你扔需要换框架重写,最好能避免这种事。以React为例,增加服务端的render这类的优化会需要付出额外的努力,但你不需要完全的重写。


控制损害

从上到下的解决方式很重要,例如代码评估。然后长时间下来,我们的标准会下降,功能会在dead line前完成,也有可能不继续维护产品。我们无法期待所有人都遵守规则,身为协调者的React必须控制损害。

如果有些UI相关的代码很慢,我们需要想尽一切办法,避免它拖慢载入时间,避免它影响其他的UI表现。最理想的状况是,开发者只会为了他们使用到的功能付出开发成本,而产品使用者只需要载入他们会用到的UI。Concurrent Mode ,包括 Time Slicing 和 Selective Hydration ,可以以不同的方式达到理想状态。

由于代码库本身的性能相对稳定,而应用的代码没有底线。因此我们倾向于在应用代码中去控制损害,而不是去修正代码库内的代码。


相信理论

有时我们会知道某些做法是死路一条。也许它现在可以运作,但可以想象它的局限。本质上无法依靠它来实现想要的用户体验。一旦有机会,我们会立刻从这种情况中抽身。

我们不想卡在这里。如果某种做法在理论上更站得住脚,就算画上好几年,我们也愿意在上面投入精力。在达成目标的过程中,会遇到许多障碍和务实的妥协。但我们详细,若持续的客服这些困难,理论终究会获胜。


你们团队的准则是什么

以上是我观察到的React团队在工作时的基本原则,但我可能漏了很多。我也还没提到React如何推出API,团队如何沟通未来的改动方向等等。或许下次可以再来谈谈这些。

链接: https://www.fly63.com/article/detial/7178

技术开发,如何与领导谈涨薪

归根结底,涨薪其实是达到自己价值与薪资的最佳匹配. 好比你就是一只股票,公司当然会选择那些估值远高于股指的股票. 所以唯有不断增长自己的价值,才会成为你在涨薪谈判中的重要筹码.

bt种子简介与magnet磁力介绍

BT下载相信老司机们都接触过,为什么BT种子会慢慢被磁链取而代之?它们都可以用于BT下载,除了文件和字符串这表面上的区别,背后的技术上又有何不同?

WebService的两种方式SOAP和REST,之间的区别与优缺点

SOAP用于在Web Service中把远程调用和返回封装成机器可读的格式化数据。REST形式上应该表述为客户端通过申请资源来实现状态的转换,在这个角度系统可以看成一台虚拟的状态机。

工作了四五年,感觉技术上依旧长进不大

技术精进是一个持续增长的过程,而非一朝一夕,即便你在最短时间的掌握了大量的技术点,如何不及时应用到实际问题中,也很容易被遗忘。有朋友会说,我平时也挺努力的,一直不间断的学习

在阿里做了五年技术主管,我有话想说

今天的文章,他将继续深入探讨这一话题,从管理的角度分享技术TL的核心职责,主要包括团队建设、团队管理、团队文化、沟通与辅导、招聘与解雇等,希望与大家共同探讨、交流。

你和阿里员工的技术水平到底差几个等级

根据近年数据,中国现有程序员500万左右,其中P1、P2数量占据了近100万,P8及以下程序员约有490万,P9及以上仅有10万。80后是企业的技术支柱,90后已开始逐步成为企业的中坚力量

程序员常逛的技术社区

技术的成长路上,少不了跟一些志同道合的人交流,阅读一些技术前辈们的经验分享。这一路走来,还是要感谢有技术社区的陪伴,让码字之余,在技术、以及技术以外,都有不少收获。

未来,哪些技术在前端开发的地位会越来越高?

过去的这段时间里,不论是互联网巨头还是初创企业,都纷纷进行了一波优化。渐趋理智的资本淘汰了一批不能适应市场的业务,而业务的紧缩也淘汰了一批不能适应市场的程序员。

合格PHP程序员应该掌握哪些技术?

除了能够完成基本的PHP业务开发,还能够解决大部分深入复杂的技术问题,并且可以独立设计完成中大型的系统设计和开发工作;自己能够独立hold深入某个技术方向,在这块比较专业

技术追求的误区[观点与思考]

认识的一个 10 人左右的团队,本来是用 PHP 的,这些年看到网上很多用 / 转 Go 的消息,于是团队里有不少人就焦虑了,希望找一个合适的切入时间,能够试一把 Go

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!