不：從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 。小細節會降低開發人員的創造力，而只是遵循聲納程式碼品質標準的要求。從第一天起，即使是遵循這些細節的程式碼庫也很容易編碼。

結論

這就是我目前的所有看法。有了一個強制模式的程式碼庫，人們可以從程式碼庫的其他地方取得一段程式碼，貼上它，稍微改變一下措辭等等，你就擁有了一個以各種可能的方式滿足生產標準的功能。雖然有一些觀點，但至少在撰寫本文時確實存在著最有效率的做事方式。可能會出現其他方法，但在編寫程式碼時最高效的編寫程式碼的方法是編寫程式碼的唯一方法。說起來容易做起來難，直到你遇到最後期限的怪物。