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

原則1: 遵守公認(rèn)的好的設(shè)計原則，比如說：

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

原則2: 找出最本源的需求，而不應(yīng)該局限于當(dāng)前的技術(shù)實現(xiàn)和資源

很多時候我們很容易被表面需求所誤導(dǎo)，類似于喬布斯的名言：“如果亨利福特在發(fā)明汽車之前去做市場調(diào)查，他得到的答案一定是大家想要一輛更快的馬車?！保绻覀冊谧鲈O(shè)計和技術(shù)決策的時候，沒有找出用戶的真實需求，很容易就會在錯誤的方向上狂奔，做很多無用功！

要找出本源的需求，還是需要多問為什么，多和干系人溝通，少考慮技術(shù)細節(jié)，少被現(xiàn)有的技術(shù)所誤導(dǎo)或局限。

案例：設(shè)計部門希望設(shè)計系統(tǒng)支持Angular

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

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

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

每一次技術(shù)決策，其實本質(zhì)上就是一次取舍（ Trade-Offs ）

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

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

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

原則4: 選擇某個技術(shù)背后的生態(tài)系統(tǒng)而不是某個技術(shù)

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

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

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

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

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

這樣的案例還很多，所以選擇技術(shù)，它背后的生態(tài)和社區(qū)活躍度很重要。

原則5: 不僅要考慮如何構(gòu)建，還要考慮如何維護

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

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

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

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

最后

上面就是我們現(xiàn)在實踐的五個技術(shù)決策原則：

• 原則 1: 遵守公認(rèn)的好的設(shè)計原則
• 原則 2: 找出最本源的需求，而不應(yīng)該局限于當(dāng)前的技術(shù)實現(xiàn)和資源
• 原則 3: 聚焦于 “收益”、“成本”和“風(fēng)險”三者之間的平衡，而不是技術(shù)本身
• 原則 4: 選擇某個技術(shù)背后的生態(tài)系統(tǒng)而不是某個技術(shù)
• 原則 5: 不僅要考慮如何構(gòu)建，還要考慮如何維護

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