最近在教一名學(xué)生封裝 2D 可視化渲染引擎的時(shí)候，無意間了解到了他一個(gè)的想法：

我們封裝的這個(gè)東西，別人已經(jīng)有非常成熟的實(shí)現(xiàn)了，為什么還要自己重新封裝一遍？如果面試官問這個(gè)問題，我都不知道應(yīng)該怎么回答。

通過進(jìn)一步聊天我的感受是，他覺得重復(fù)造輪子在我們行業(yè)里其實(shí)是一件不那么光彩的事情，他一直以來聽到的都是不要重復(fù)造輪子。

很顯然，確實(shí)在我們行業(yè)有很多人會(huì)旗幟鮮明的反對(duì)重復(fù)造輪子，這句話影響也是非常大的，我們會(huì)發(fā)現(xiàn)很多人在面對(duì)新需求的時(shí)候，常常腦袋里的第一反應(yīng)就是：有沒有什么庫能直接幫我搞定這個(gè)需求。

但是我的觀點(diǎn)卻恰好剛剛相反，我覺得作為程序員，在能力范圍之內(nèi)，一定要嘗試去造幾個(gè)輪子。哪怕剛開始因?yàn)槟芰Σ蛔阍燧喿永щy，或者造出來的東西不好用。

說一下我的理由。

一、找輪子花費(fèi)的時(shí)間也不少

其實(shí)我們會(huì)花大量的時(shí)間在找輪子上。

這件事情我比較有體會(huì)，因?yàn)槲乙郧敖?jīng)常干這個(gè)事情。這里面最痛苦的事情是當(dāng)你找到一個(gè)輪子之后，到底好用不好用其實(shí)你自己也不知道，然后用了一半之后發(fā)現(xiàn)不完全是自己想要的，有的功能實(shí)現(xiàn)不了。

然后你就只能重新找。

有可能要反復(fù)幾次之后才能找到完全符合當(dāng)前需求的東西。但是也有可能找不到，最后只能妥協(xié)需求，實(shí)現(xiàn)一個(gè)大概差不多的東西。

雖然最終也交差了，但畢竟給同事留下了一個(gè)不好的形象。甚至?xí)苯佑绊懽约旱纳毤有胶湍杲K績(jī)效。

二、別人造的輪子并不完全符合心意

最近有幸能有機(jī)會(huì)參與到 openInula 技術(shù)方案的探討會(huì)議中去，在幾位華為、騰訊大佬的討論過程中我也學(xué)習(xí)到了很多東西。

在設(shè)計(jì)一個(gè)東西的過程中，我能很明顯感受到的一個(gè)現(xiàn)象就是，每個(gè)人都有自己的技術(shù)偏好。哪怕是在設(shè)計(jì)一個(gè)小小的語法上，大家也會(huì)有不一樣的喜好。

就拿我自己來說，我并不喜歡 React 語法里 useState 用數(shù)組來解構(gòu)，每次看到幾個(gè)的數(shù)組解構(gòu)堆在一起我就覺得渾身不舒服。

const [loading, setLoading] = useState(true)
const [param, setParam] = useState('')
const [list, setList] = useState([])
const [error, setError] = useState('')

所以我在使用 React 的過程中，做得最多的事情就是想辦法把這些 state 藏起來，用自定義 hook 重新封裝，并一定要改成對(duì)象解構(gòu)的語法來使用。

const {
  loading, 
  setParam,
  list = [],
  error
} = useFetch(searchApi)

又比如有的人覺得 solid.js 非常驚艷，是他理想中的樣子。但是我還是覺得 solid.js 的語法比 React 更讓我無法接受。

const [count, setCount] = createSignal(0);

一方面是因?yàn)檠赜昧?React 的數(shù)組解構(gòu)，另外一方面是因?yàn)榉祷氐?count，他不是一個(gè)值，而是一個(gè)獲取值的方法。

因此我們使用的時(shí)候必須這樣用。

<div>count()</div>

但同時(shí)，他又可以是一個(gè)值，例如我們這樣用的時(shí)候。

setCount(count => count + 1)

這違背了我一直嚴(yán)格遵守的語義化和單一性，所以我主觀上不接受這樣的語法設(shè)計(jì)。

包括 solid.js 在 props 的處理上，為了確保修改之后的 props 具備響應(yīng)性，不得不新增了兩個(gè)語法，mergeProps splitProps，這也是我不愿意接受的語法設(shè)計(jì)。

這種偏好其實(shí)非常主觀，但是確實(shí)是每個(gè)人都會(huì)或多或少有這樣的怪癖，會(huì)覺得別人的語法寫起來不舒服。

三、不完全符合需求

有的時(shí)候一個(gè)優(yōu)秀的輪子你對(duì)他贊不絕口，然后用了半年之后，突然來了個(gè)需求，它滿足不了。賊難受。

于是很多程序員這個(gè)時(shí)候又不知道咋跟產(chǎn)品經(jīng)理溝通，他會(huì)犯一個(gè)經(jīng)典的職場(chǎng)錯(cuò)誤：直截了當(dāng)?shù)母嬖V產(chǎn)品這個(gè)事情他做不了，甚至有的人會(huì)更夸張，還會(huì)解釋說這個(gè)需求我用的組件庫不支持所以我做不了。

這種溝通方式最大的問題，就是在跟同事暴露你技術(shù)能力不行。你可以用別的任何理由去拒絕這個(gè)需求，但理由一定不能是我實(shí)現(xiàn)不了這個(gè)需求。

如果一年中，你有 2 次出現(xiàn)這種情況，你就會(huì)發(fā)現(xiàn)你的年終績(jī)效會(huì)受到很大的影響。一年兩次這樣的頻率其實(shí)非常低，真實(shí)情況可能遠(yuǎn)不止兩次。但是即使只是兩次，別人也會(huì)覺得你能力有問題。

所以別人的輪子往往會(huì)限制我們，哪怕他滿足了你 99% 的需求，如果突然來了一個(gè)需求滿足不了，就會(huì)讓你很難受，直接面臨職場(chǎng)危機(jī)。

四、遇到 BUG 難以修復(fù)

有很多輪子是不得不用別人的。然后就經(jīng)常遇到的一個(gè)問題就是，如果在特定場(chǎng)景之下遇到一個(gè) bug，輪子作者也不會(huì)馬上幫你把這個(gè) bug 給修復(fù)了。

你提的 issue 可能輪子作者隔了半年才反應(yīng)過來可能會(huì)修復(fù)你這個(gè)問題。

有的時(shí)候修復(fù)這個(gè) bug 也非常不容易。因?yàn)槟闾囟▓?chǎng)景的 bug，作者要復(fù)現(xiàn)可能比較困難，甚至?xí)驗(yàn)闇贤▎栴}，比如你提供的信息、版本、環(huán)境不充分，而導(dǎo)致作者根本就復(fù)現(xiàn)不了，導(dǎo)致最終也改不了你這個(gè)問題。

這個(gè)時(shí)候是最難受的。

所以我以前經(jīng)常 fork 別人的輪子，然后去把他的源碼給改了，改個(gè)名字重新上傳到 npm 上，當(dāng)成自己的輪子用。這樣雖然勉強(qiáng)解決了問題，但其實(shí)也并不是一個(gè)好的方案，因?yàn)楹罄m(xù)的版本就開始完全分道揚(yáng)鑣了，后續(xù)所有的改動(dòng)都要你自己動(dòng)手操作了。慢慢的也走上了造輪子的道路。

五、場(chǎng)景不匹配

有的時(shí)候我們會(huì)發(fā)現(xiàn)別人的輪子跟我想要的場(chǎng)景不太匹配。

例如我需要一個(gè)圖表庫，我希望他能在網(wǎng)頁上跑，又希望他能在小程序上跑，還希望在 React Native 上也能跑。這樣對(duì)我來說，項(xiàng)目的維護(hù)成本是最低的。

實(shí)際上如果是我自己寫的輪子的話，我要做的兼容成本非常低。但是這種特定的需求可能別的輪子就不會(huì)專門幫你做這個(gè)事情。

于是我們就不得不在不同的平臺(tái)使用不同的輪子。難受的是，如果遇到定制化 UI，有的輪子支持得就不那么好，就會(huì)出現(xiàn)一個(gè)詭異的現(xiàn)象，明明能在 web 上做得非常好的功能，在 RN 上就搞得缺點(diǎn)意思，給人一種很古怪的感覺。

六、自己造的輪子，可以更輕量

成熟的開源項(xiàng)目往往會(huì)考慮更多的因素，因此你常常會(huì)發(fā)現(xiàn)許多開源項(xiàng)目的源碼讀起來非常痛苦，各種條件判斷特別多。原因就是成熟的開源項(xiàng)目他需要兼顧更多的場(chǎng)景和需求。

但是在你的項(xiàng)目中，有可能不需要考慮那么多。

這樣我們自己造的輪子其實(shí)是可以更輕量，更簡(jiǎn)單。例如我自己封裝的一個(gè)狀態(tài)管理器 mozz，只有 10 多行代碼，在特定的場(chǎng)景下結(jié)合我自己的項(xiàng)目架構(gòu)思路，用了 5 年了也沒出什么問題，非常舒適。

所以我一直以來，對(duì)別的 React 生態(tài)中的狀態(tài)管理并不是很關(guān)注，因?yàn)樗麄儍?nèi)部到底是怎么實(shí)現(xiàn)的，具體的優(yōu)缺點(diǎn)是什么，是否是我的項(xiàng)目所必要的我大概心里也有數(shù)。

在我公眾號(hào)文章里，前面介紹了幾種封裝狀態(tài)管理器的思路「半成品」，其實(shí)就覆蓋了好幾種狀態(tài)管理的實(shí)現(xiàn)原理，例如基于 reducer 和 useSyncExternalStore 的 zustand，基于 Atom 的 Jotai，只是在最終實(shí)現(xiàn)上，語法設(shè)計(jì)上會(huì)有所不同。

七、提高技術(shù)競(jìng)爭(zhēng)力

最最主要的原因是，造輪子能提高我們的個(gè)人技術(shù)能力。能造輪子的人，技術(shù)能力肯定是要比不能造輪子的人更強(qiáng)。

實(shí)際上很多人會(huì)覺得造輪子可能比較浪費(fèi)時(shí)間。其實(shí)恰恰相反，這東西是可以不斷累積的。工作時(shí)間長(zhǎng)了之后，你就會(huì)發(fā)現(xiàn)你需要親自造的輪子會(huì)越來越少。

然后到了后期，很多時(shí)候都是出了一個(gè)新框架，新平臺(tái)，你需要自己動(dòng)手去做遷移和重寫。就比如這次鴻蒙開發(fā)起來了之后，我們的交流群里面就有幾個(gè)大佬在著手把以前自己寫的輪子重新在 arkUI 上寫一篇，花的時(shí)間也不是很多。

當(dāng)然前期受限于技術(shù)能力和工作時(shí)間，造輪子會(huì)比較困難，甚至有的人會(huì)覺得無從下手。

那么我們有幾個(gè)方式可以走，首先就是先從簡(jiǎn)單的輪子開始，例如在我職業(yè)生涯的早期，我自己寫了一個(gè)專門操作 cookie 的庫。

或者搞一個(gè)更簡(jiǎn)單的，寫一個(gè)專門用來創(chuàng)建 css3 動(dòng)畫的 JS 庫。

然后慢慢的逐漸深入，寫一個(gè)拖拽庫，或者寫一個(gè)動(dòng)畫庫，寫一個(gè)輪播圖庫。

這些都是比較簡(jiǎn)單就能做到，不需要太高昂的學(xué)習(xí)成本。只是很多人內(nèi)心深處覺得這些事情根本沒必要，完全是在浪費(fèi)時(shí)間而已。

打個(gè)小廣告：你也可以直接付費(fèi)找我學(xué)習(xí)從零開始基于 canvas 打造一個(gè) 2D 可視化渲染引擎，費(fèi)用 2000 元，助你快速提高技術(shù)能力，在面試時(shí)手握利器，不用為項(xiàng)目亮點(diǎn)而擔(dān)心。

八、直接和薪資，績(jī)效掛鉤

有人不知道年終總結(jié)怎么寫，自己一年下來都在寫頁面，好像對(duì)團(tuán)隊(duì)也沒什么特別的貢獻(xiàn)，想漲工資又不好意思找老板提。

想要晉升也不知道用什么去談。

我其實(shí)都沒怎么遇到過這種煩惱，因?yàn)槊磕甓加挟a(chǎn)出和貢獻(xiàn)。這就是經(jīng)常自己造輪子的一個(gè)非常大的好處。

因?yàn)閷?shí)際上團(tuán)隊(duì)內(nèi)部有自己的技術(shù)沉淀這件事情本身就是非常重要的。因此你總會(huì)發(fā)現(xiàn)一些好的團(tuán)隊(duì)總是非常熱衷于自己造輪子，然后你還會(huì)發(fā)現(xiàn)很多人會(huì)嘲諷這種現(xiàn)象。

對(duì)于這種嘲諷我們完全不需要理會(huì)，一方面是他們并不理解團(tuán)隊(duì)技術(shù)沉淀的重要性，別人的技術(shù)終究是別人的，不管是從團(tuán)隊(duì)角度或者從個(gè)人角度出發(fā)，盡可能少的受限于他人，本身就是我們應(yīng)該追求的目標(biāo)之一。

另外一方面是因?yàn)槟隳玫绞稚系氖钦娼鸢足y，那些嘲諷的人又不會(huì)給你發(fā)錢。

九、總結(jié)

總之在能力范圍之內(nèi)，嘗試自己造輪子是我比較推崇的觀點(diǎn)。他的好處我有切身的體會(huì)。你也有機(jī)會(huì)認(rèn)識(shí)更多的大佬，能更輕松的找到工作等等。

但是一定要操作得當(dāng)，不要因?yàn)樵燧喿佣鴮?dǎo)致任務(wù)總是 delay，一個(gè)好的方式就是把造輪子的事情上升到公司層面的需求，而不是自己私下悄悄搞，這樣的話就不用擔(dān)心任務(wù) delay 這個(gè)事情了，你也有充足的時(shí)間和正當(dāng)?shù)睦碛蓙碜鲞@個(gè)事情。

當(dāng)然這樣做也有壞處，就是以后你造的輪子就是屬于公司了，所以我當(dāng)年這樣做雖然可以大量利用上班時(shí)間來通過造輪子提高自己的技術(shù)能力，但也導(dǎo)致了很多東西不能開源出來，屬于是有利有弊吧，自己權(quán)衡就好。