我React團(tuán)隊(duì)工作的這段時(shí)間，很幸運(yùn)能夠看見(jiàn) Jordan、Sebastian、Sophie 和其他團(tuán)隊(duì)成員是如何解決問(wèn)題的。在本文中，我會(huì)把從他們身上學(xué)到的，濃縮為一篇較高層次的技術(shù)準(zhǔn)則。這些準(zhǔn)則未必詳細(xì)。它們都是我對(duì)React團(tuán)隊(duì)的觀察和整理 —— 其他團(tuán)隊(duì)成員或許有其他的觀點(diǎn)。

成都創(chuàng)新互聯(lián)公司專(zhuān)注為客戶(hù)提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于做網(wǎng)站、成都網(wǎng)站建設(shè)、樂(lè)亭網(wǎng)絡(luò)推廣、微信平臺(tái)小程序開(kāi)發(fā)、樂(lè)亭網(wǎng)絡(luò)營(yíng)銷(xiāo)、樂(lè)亭企業(yè)策劃、樂(lè)亭品牌公關(guān)、搜索引擎seo、人物專(zhuān)訪(fǎng)、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等，從售前售中售后，我們都將竭誠(chéng)為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；成都創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供樂(lè)亭建站搭建服務(wù)，24小時(shí)服務(wù)熱線(xiàn)：13518219792，官方網(wǎng)址：www.cdcxhl.com

UI優(yōu)先于API

當(dāng)我們把抽象概念大規(guī)模用于實(shí)踐時(shí)，難免會(huì)有怪異之處。這些怪異之處是如何在用戶(hù)界面上呈現(xiàn)的呢?你能看出一個(gè)應(yīng)用中包含了哪些特定的抽象概念么?

抽象概念對(duì)用戶(hù)體驗(yàn)有直接的影響 —— 它能創(chuàng)造好的、延續(xù)性的的體驗(yàn)或者限制某些東西。這也是為什么我們?cè)谠O(shè)計(jì)API時(shí)，并不會(huì)從抽象本身開(kāi)始。相反地，我們會(huì)從用戶(hù)體驗(yàn)開(kāi)始，然后再回到抽象概念。

有時(shí)候當(dāng)我們回到抽象概念時(shí)，會(huì)發(fā)現(xiàn)必須更改整個(gè)方法，才能達(dá)到正確的用戶(hù)體驗(yàn)。如果我們先從API下手，就無(wú)法察覺(jué)到這點(diǎn)。所以，我們將UI放在API之前考慮。

吸收復(fù)雜性

簡(jiǎn)化React內(nèi)部的實(shí)現(xiàn)并不是我們的目標(biāo)。如果產(chǎn)品開(kāi)發(fā)者可以使用React寫(xiě)出更易于理解、易于修改的代碼，我們樂(lè)于把React的內(nèi)部實(shí)現(xiàn)變得復(fù)雜。

我們想把產(chǎn)品的開(kāi)發(fā)變得更加職責(zé)分明，易于合作。這意味著我們必須把負(fù)責(zé)的部分封裝在React的內(nèi)部。React不能被切分為小規(guī)模、耦合松散的模塊，因?yàn)檫@樣便無(wú)法工作。React的使命是成為協(xié)調(diào)者的角色。

通過(guò)提升抽象層級(jí)，使得產(chǎn)品開(kāi)發(fā)者更加有力。產(chǎn)品開(kāi)發(fā)會(huì)從React的可預(yù)測(cè)的完備系統(tǒng)中受益。這意味著我們推出的每一個(gè)新功能，都必須兼容已經(jīng)存在的功能。設(shè)計(jì)和實(shí)現(xiàn)React的新功能十分困難。這也是我們核心功能并沒(méi)有收到太多開(kāi)源貢獻(xiàn)的原因。

我們吸收了復(fù)雜的部分，防止他們污染產(chǎn)品的代碼。

從Hacks到Idioms

每一個(gè)Api都有一些局限性。有時(shí)，這些限制會(huì)妨礙我們打造良好的使用者體驗(yàn)。為此，我們提供了一些后路(escape hatches)以供需要時(shí)使用。

Hacks并不是長(zhǎng)久之計(jì)，因?yàn)樗麄兒艽嗳酢ｉ_(kāi)發(fā)者必須決定他們是否維護(hù)，支持這些Hack，或者移除hack而犧牲用戶(hù)體驗(yàn)。通常大多數(shù)人會(huì)犧牲用戶(hù)體驗(yàn)，不然這些hack也會(huì)有可能阻礙用戶(hù)的優(yōu)化。

我們需要讓產(chǎn)品開(kāi)發(fā)者使用這個(gè)后路，并觀察在他們實(shí)踐中都是如何使用的。我們的目標(biāo)是提供這類(lèi)實(shí)現(xiàn)一個(gè)常用的解決方法(idiomatic solution)，目的是達(dá)成更好的用戶(hù)體驗(yàn)。有時(shí)候，一個(gè)解決方案，會(huì)花費(fèi)我們數(shù)年的時(shí)間。我們更傾向于有彈性的hack來(lái)確立完整的習(xí)慣用法(a poor idiom)。

實(shí)現(xiàn)局部開(kāi)發(fā)

你無(wú)法在代碼編輯器做太多的事情。你可以增加幾行，移除幾行。或者復(fù)制粘貼。但許多抽象概念讓這些基本操作變得困難。

比如，MVC框架讓刪除一些render的操作變得不可靠。這是因?yàn)榧凹词鼓銊h除了childern的方法，parent仍有可能執(zhí)行它。相比之下，React的優(yōu)勢(shì)在于：你通常能安全的刪除某些render tree內(nèi)的代碼。

在設(shè)計(jì)API時(shí)，我們會(huì)假設(shè)使用它的人只熟悉他們會(huì)用到的局部代碼的相關(guān)知識(shí)。如果預(yù)期發(fā)生的影響只發(fā)生在這局部的代碼中，我們將會(huì)避免意料之外的結(jié)果。例如，我們通常假設(shè)新增代碼時(shí)安全的。在移除和修改代碼時(shí)，應(yīng)該清楚指出這些改動(dòng)會(huì)連帶影響、應(yīng)該被考慮到的部分。我們不應(yīng)該假設(shè)改動(dòng)單一文件需要對(duì)整個(gè)代碼都了解。

如果某一項(xiàng)改動(dòng)不安全，我們希望開(kāi)發(fā)者能夠盡早發(fā)現(xiàn)這個(gè)改動(dòng)所帶來(lái)的的影響。雖然可以使用警告、類(lèi)型檢查和開(kāi)發(fā)者工具來(lái)幫忙，但它們都受限于API的設(shè)計(jì)。如果API不夠局部性，局部開(kāi)發(fā)就不可能實(shí)現(xiàn)。例如，findDOMNode就不是一個(gè)好的API，因?yàn)樗枰娴牧私狻?/p>

漸進(jìn)的復(fù)雜度

有些框架會(huì)選擇在開(kāi)發(fā)的路上分出岔路，提供兩種路線(xiàn)：簡(jiǎn)單的方法或強(qiáng)大、完整的方法。簡(jiǎn)單的方法容易學(xué)習(xí)，但你終究會(huì)走到他的極限。這個(gè)時(shí)候，你必須推倒重來(lái)，重新使用另外一套方法來(lái)實(shí)現(xiàn)。

我們認(rèn)為實(shí)現(xiàn)一個(gè)復(fù)雜的東西，和實(shí)現(xiàn)一個(gè)簡(jiǎn)單的東西，在結(jié)構(gòu)上沒(méi)有太大的差別。我們并不會(huì)簡(jiǎn)單的狀態(tài)提供簡(jiǎn)單的寫(xiě)法，因?yàn)檫@樣會(huì)使開(kāi)發(fā)中出現(xiàn)岔路。如果我們認(rèn)為開(kāi)發(fā)者在開(kāi)發(fā)過(guò)程中想要完整的開(kāi)發(fā)工具，我們?cè)敢鉅奚烷T(mén)檻來(lái)達(dá)成這件事。

有時(shí)，【簡(jiǎn)單】和【強(qiáng)大】代表兩種不同的框架，那么你扔需要換框架重寫(xiě)，最好能避免這種事。以React為例，增加服務(wù)端的render這類(lèi)的優(yōu)化會(huì)需要付出額外的努力，但你不需要完全的重寫(xiě)。

控制損害

從上到下的解決方式很重要，例如代碼評(píng)估。然后長(zhǎng)時(shí)間下來(lái)，我們的標(biāo)準(zhǔn)會(huì)下降，功能會(huì)在dead line前完成，也有可能不繼續(xù)維護(hù)產(chǎn)品。我們無(wú)法期待所有人都遵守規(guī)則，身為協(xié)調(diào)者的React必須控制損害。

如果有些UI相關(guān)的代碼很慢，我們需要想盡一切辦法，避免它拖慢載入時(shí)間，避免它影響其他的UI表現(xiàn)。最理想的狀況是，開(kāi)發(fā)者只會(huì)為了他們使用到的功能付出開(kāi)發(fā)成本，而產(chǎn)品使用者只需要載入他們會(huì)用到的UI。Concurrent Mode ，包括 Time Slicing 和 Selective Hydration ，可以以不同的方式達(dá)到理想狀態(tài)。

由于代碼庫(kù)本身的性能相對(duì)穩(wěn)定，而應(yīng)用的代碼沒(méi)有底線(xiàn)。因此我們傾向于在應(yīng)用代碼中去控制損害，而不是去修正代碼庫(kù)內(nèi)的代碼。

相信理論

有時(shí)我們會(huì)知道某些做法是死路一條。也許它現(xiàn)在可以運(yùn)作，但可以想象它的局限。本質(zhì)上無(wú)法依靠它來(lái)實(shí)現(xiàn)想要的用戶(hù)體驗(yàn)。一旦有機(jī)會(huì)，我們會(huì)立刻從這種情況中抽身。

我們不想卡在這里。如果某種做法在理論上更站得住腳，就算畫(huà)上好幾年，我們也愿意在上面投入精力。在達(dá)成目標(biāo)的過(guò)程中，會(huì)遇到許多障礙和務(wù)實(shí)的妥協(xié)。但我們?cè)敿?xì)，若持續(xù)的客服這些困難，理論終究會(huì)獲勝。

你們團(tuán)隊(duì)的準(zhǔn)則是什么

以上是我觀察到的React團(tuán)隊(duì)在工作時(shí)的基本原則，但我可能漏了很多。我也還沒(méi)提到React如何推出API，團(tuán)隊(duì)如何溝通未來(lái)的改動(dòng)方向等等。或許下次可以再來(lái)談?wù)勥@些。

你們團(tuán)隊(duì)有什么準(zhǔn)則呢?我洗耳恭聽(tīng)。

本文名稱(chēng)：React團(tuán)隊(duì)的技術(shù)準(zhǔn)則
URL標(biāo)題：http://uogjgqi.cn/article/cogdjcg.html