Oursky 製作過很多跨平台 app，在使用 Redux 以前，我們並沒有依循一個共同的設計模式。每一個專案可能都有個別的資料流程、邏輯和設計原則。身為 Oursky 的技術長，我希望減輕工程師在專案中不必要的精神耗費，其中一個方向是思考是透過管理工程標準，令工程師集中精神處理重要問題。以下我會分享我們公司為何會選擇 Redux 設計模式作為管控專案成本和複雜度的手段。
避免重複同樣的工作
即便每個專案的內容都不一樣，高品質程式碼的原則都是一樣的。專案還是可以在某程度上依循一些原則，讓專案得以加速進行開發。尤其當我們在不同的平台上開發時，更需要一個方法去同步該專案的程式碼品質，以減輕轉換語言及平台的成本。把 Redux 設計模式套用到不同的平台上，正好幫助工程師減少轉換工作環境的成本。他們就可以在轉換到不同專案的時候，快速地參與討論和貢獻，把時間花在改進程式碼這種更有意義的事情上。
程式碼的一致性
在開發新專案時，如果欠缺一個標準，每位工程師就有可能想出一個不同的設計模式。我不是指 Redux 就是最佳設計模式，但是 Redux 簡單而易於理解，而且使用 Redux 可以限制元件的複雜度。以 Redux 作為設計模式的標準，可以為每一個專案設定基本框架，讓工程師們可以在同一個 Redux Store （single source of truth 單一數據源）工作，並無瑕地整合不同程式碼。有關 Redux Store、Action、Dispatch 的簡單解說，你可以參考看看這篇文章。
循環運用資源
使用 Redux 設計模式後，統一了跨平台 app 的資料流向。這意味著所有 API 的需求是一樣的，不需為特定的平台開發專門的 API。工程師處理任一平台後，可以輕鬆整合到其他平台。
進一步發揮團隊力量
自從我們的初始團隊擴展到 10 – 20 名工程師的規模後，我們陸續開發更多更大規模的專案。對於是否擴展公司規模，很常見的一個爭論點是，額外產生的行政程序和工作可能比擴展後所獲得的收益更大；但有了更多的團隊成員，我們就可以承接更多有趣複雜的案子，一起窺見更大型的知識寶庫。套用標準提供了一個在研究問題時可以依據的共同基礎，讓團隊成員可以互相學習。
Redux 的不足之處
當然，Redux 也會有自身的缺陷。比方說，它為了讓開發者之間可以合作，可能會產生大量的樣板程式碼 (boilerplate code)。而且，目前也沒有有關 Redux Store 內數據該如何標準化的建議。舉例來說，一個人的名字可以拆開成多個部分：姓氏、名字、暱稱等等。Redux Store 應該以組成部分還是全名的方式來儲存資料呢？如果以組成部分的方式來儲存，UI 就需要有把各部分重組成全名的能力。而如果以全名的形式來儲存，UI 就不可能在避免數據庫資料冗餘的情況下，只顯示部份名字。最後，Redux 設計模式對於 Singleton 的問題到現在還沒有既定的解決方法。
結論
Oursky 一直致力改善自身的開發流程和最佳標準。作為一家扁平化架構的軟體公司，我們同仁持續努力以不同方式提升程式碼的品質，譬如設立 Kubernetes 叢集協助同事可以更快速地佈署 app、整合 ChatOp 到 Slack 讓佈署變得更便捷，或執行循證式時程規劃 (evidence-based-scheduling) 來鼓勵開發工程師和專案經理更有效地預測開發時間。
過去我們曾試用過其他設計模式，工程師們也可以考慮使用 iOS 的 VIPER、Android 的 Model-View-ViewModel 或 JS 的 MVC。如果你對於設計模式有其他的建議和心得，歡迎留言跟我們討論！
Oursky 致力幫助品牌與企業家實現他們的點子。如果你正在尋找合作夥伴一起建立下一個自家數碼產品，來跟我們聊聊吧！
原文：Why we use Redux design pattern across all platforms
作者：Rick Mak
翻譯者： Queenie So
