君子以泽,完美世界辰东

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案

前端架構(gòu)設(shè)計(jì)中如何做好技術(shù)決策？

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

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

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

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

為企業(yè)提供成都網(wǎng)站建設(shè)、做網(wǎng)站、網(wǎng)站優(yōu)化、成都營(yíng)銷網(wǎng)站建設(shè)、競(jìng)價(jià)托管、品牌運(yùn)營(yíng)等營(yíng)銷獲客服務(wù)。創(chuàng)新互聯(lián)公司擁有網(wǎng)絡(luò)營(yíng)銷運(yùn)營(yíng)團(tuán)隊(duì)，以豐富的互聯(lián)網(wǎng)營(yíng)銷經(jīng)驗(yàn)助力企業(yè)精準(zhǔn)獲客，真正落地解決中小企業(yè)營(yíng)銷獲客難題，做到“讓獲客更簡(jiǎn)單”。自創(chuàng)立至今，成功用技術(shù)實(shí)力解決了企業(yè)“網(wǎng)站建設(shè)、網(wǎng)絡(luò)品牌塑造、網(wǎng)絡(luò)營(yíng)銷”三大難題，同時(shí)降低了營(yíng)銷成本，提高了有效客戶轉(zhuǎn)化率，獲得了眾多企業(yè)客戶的高度認(rèn)可！

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

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

我們?cè)O(shè)計(jì)部門最近希望我們的設(shè)計(jì)系統(tǒng)提供 Angular 版本，因?yàn)楫?dāng)前只支持 React 版本。從這個(gè)需求來(lái)看，表面是是要我們開發(fā) Angular 版本，其實(shí)如果仔細(xì)追問(wèn)他們到底為什么需要 Angular 版本，是因?yàn)橛幸粋€(gè)團(tuán)隊(duì)還在用 Angular ，他們希望這個(gè)團(tuán)隊(duì)能用我們的設(shè)計(jì)系統(tǒng)，但是人家表示用不了。其實(shí)本源的需求是希望有更多的團(tuán)隊(duì)用設(shè)計(jì)系統(tǒng)，而不是要支持 Angualr 。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最后

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

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

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

分享題目：前端架構(gòu)設(shè)計(jì)中如何做好技術(shù)決策？
當(dāng)前地址：http://fisionsoft.com.cn/article/dpcgcsd.html