本文翻譯自React團隊核心成員Dan Abramov的技術部落格。地址：overreacted.io/what-are-th…
本文首發於公眾號：符合預期的CoyPan
我React團隊工作的這段時間，很幸運能夠看見 Jordan、Sebastian、Sophie 和其他團隊成員是如何解決問題的。在本文中，我會把從他們身上學到的，濃縮為一篇較高層次的技術準則。這些準則未必詳細。它們都是我對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，團隊如何溝通未來的改動方向等等。或許下次可以再來談談這些。
你們團隊有什麼準則呢？我洗耳恭聽。