今天做了一個關于如何做架構設計的分享，其中有個很重要的問題就是如何更好的做技術決策，我針對我們前端團隊整理了5條做技術決策的原則。

原則1: 遵守公認的好的設計原則，比如說：

• DRY - Don't repeat yourself （不要重復自己）
• KISS - Keep it Simple, Silly （讓設計盡可能的簡單）
• YAGNI - You aren't gonna need it （只做剛剛好的設計，不要過度設計）
• … 其他

原則2: 找出最本源的需求，而不應該局限于當前的技術實現和資源

很多時候我們很容易被表面需求所誤導，類似于喬布斯的名言：“如果亨利福特在發明汽車之前去做市場調查，他得到的答案一定是大家想要一輛更快的馬車。”，如果我們在做設計和技術決策的時候，沒有找出用戶的真實需求，很容易就會在錯誤的方向上狂奔，做很多無用功！

要找出本源的需求，還是需要多問為什么，多和干系人溝通，少考慮技術細節，少被現有的技術所誤導或局限。

案例：設計部門希望設計系統支持Angular

我們設計部門最近希望我們的設計系統提供 Angular 版本，因為當前只支持 React 版本。從這個需求來看，表面是是要我們開發 Angular 版本，其實如果仔細追問他們到底為什么需要 Angular 版本，是因為有一個團隊還在用 Angular ，他們希望這個團隊能用我們的設計系統，但是人家表示用不了。其實本源的需求是希望有更多的團隊用設計系統，而不是要支持 Angualr 。

那要滿足這個團隊的這個需求，是不是非要做一個 Angular 版本不可呢？當然不需要，如果我能提供一個類似于 BootStrap 的 HTML 和 CSS 版本，其實他們一樣能用起來，而這么做成本不高，并且別的團隊也可以用。

原則3: 聚焦于 “收益”、“成本”和“風險”三者之間的平衡，而不是技術本身

每一次技術決策，其實本質上就是一次取舍（ Trade-Offs ）

每一次取舍（ Trade-Offs ），本質上就是在“收益”、“成本”和“風險”三者之間的平衡

既然每一個決策都涉及到收益成本風險，那么就不能只看收益而無視成本和風險。就像前一個案例中提到的，設計部門考慮的是 Angular 版本帶來的收益，但是他們卻忽略了打造一套 Angular 版本的設計系統所需要的成本，以及可能帶來的巨大風險。

所以在做技術決策的時候，理性的考慮一下 決策背后的收益、成本和風險的關系是很必要的，而不是僅靠喜好或者直覺來做決策。

原則4: 選擇某個技術背后的生態系統而不是某個技術

這條原則特別適用于前端領域，在前端，各種新技術、框架、工具層出不窮，如果總是追新，或者被某個軟文吸引輕易選擇了某個技術，最終會帶來巨大的成本。

案例：為什么我們從Preact遷移到React

在早些年的時候，我們前端選擇了 Preact 作為UI渲染技術，這有早年 React License 的原因，也有 Preact 更小性能更好的原因。

然而這些年在使用過程中，還是有很多不足的地方，核心原因都是生態不夠好。

比如說 Preact 調試很麻煩，因為它不像 React 有一個強大的 DevTools ；比如說我們遇到過 Preact 在服務端渲染的內存泄漏問題，如果像我們這樣大規模訪問量的用戶多一點，可能早就有人踩過坑了，不需要我們去花很長時間定位并最終去解決這個問題；比如最近我們在集成 Nextjs ， Nextjs 是完全為 React 設計的，對 Preact 兼容性并不好。

這樣的案例還很多，所以選擇技術，它背后的生態和社區活躍度很重要。

原則5: 不僅要考慮如何構建，還要考慮如何維護

這是一個常見的問題，很多人只管搭建新項目的時候爽，而不管后續維護是不是困難，用了一堆自己喜歡的新技術，最后難以維護。下一個人接手了，搞不好會推翻重寫一遍，這樣的循環一次又一次。

這樣的錯誤我也常犯，比如2年前 React Hooks 剛出的時候，我就迫不及待用它來替代 Redux ，結果上線后發現不好維護，有 Bug 也不好定位，不像以前 Redux ，數據流特別清晰，借助工具非常好重現和定位問題，最終上線沒多久就改回去了。

所以現在在做技術決策的時候，我們很注意的一個問題就是將來維護的時候是不是很麻煩。

包括我在代碼審查的時候，有時候看到一些功能能運行的很好 PR，但是代碼寫的比較難懂的，或者沒有遵守最佳實踐的，只要是給未來的維護造成麻煩的，我都會毫不猶豫要求重寫，避免增加未來的維護成本。

最后

上面就是我們現在實踐的五個技術決策原則：

• 原則 1: 遵守公認的好的設計原則
• 原則 2: 找出最本源的需求，而不應該局限于當前的技術實現和資源
• 原則 3: 聚焦于 “收益”、“成本”和“風險”三者之間的平衡，而不是技術本身
• 原則 4: 選擇某個技術背后的生態系統而不是某個技術
• 原則 5: 不僅要考慮如何構建，還要考慮如何維護

這些原則絕大部分時候都可以很好的幫助我們做出正確的決策，避免踩坑。但我也會一直在反思曾經做過的決策，對于做出的不太好的決策，會反過來考慮是否要修訂這些原則，最終通過不斷完善決策原則，幫助我和團隊更好的做出技術決策。