三言兩語說透設計模式的藝術-單例模式
寫在前面單例模式是一種常用的軟件設計模式，它所創建的對象只有一個實例，且該實例易于被外界訪問。單例對象由于只有一個實例，所以它可以方便地被系統中的其他對象共享，從而減少
最近在教一名學生封裝 2D 可視化渲染引擎的時候，無意間了解到了他一個的想法：
我們封裝的這個東西，別人已經有非常成熟的實現了，為什么還要自己重新封裝一遍？如果面試官問這個問題，我都不知道應該怎么回答。
通過進一步聊天我的感受是，他覺得重復造輪子在我們行業里其實是一件不那么光彩的事情，他一直以來聽到的都是不要重復造輪子。
很顯然，確實在我們行業有很多人會旗幟鮮明的反對重復造輪子，這句話影響也是非常大的，我們會發現很多人在面對新需求的時候，常常腦袋里的第一反應就是：有沒有什么庫能直接幫我搞定這個需求。
但是我的觀點卻恰好剛剛相反，我覺得作為程序員，在能力范圍之內，一定要嘗試去造幾個輪子。哪怕剛開始因為能力不足造輪子困難，或者造出來的東西不好用。
說一下我的理由。
其實我們會花大量的時間在找輪子上。
這件事情我比較有體會，因為我以前經常干這個事情。這里面最痛苦的事情是當你找到一個輪子之后，到底好用不好用其實你自己也不知道，然后用了一半之后發現不完全是自己想要的，有的功能實現不了。
然后你就只能重新找。
有可能要反復幾次之后才能找到完全符合當前需求的東西。但是也有可能找不到，最后只能妥協需求，實現一個大概差不多的東西。
雖然最終也交差了，但畢竟給同事留下了一個不好的形象。甚至會直接影響自己的升職加薪和年終績效。
最近有幸能有機會參與到 openInula 技術方案的探討會議中去，在幾位華為、騰訊大佬的討論過程中我也學習到了很多東西。
在設計一個東西的過程中，我能很明顯感受到的一個現象就是，每個人都有自己的技術偏好。哪怕是在設計一個小小的語法上，大家也會有不一樣的喜好。
就拿我自己來說，我并不喜歡 React 語法里 useState 用數組來解構，每次看到幾個的數組解構堆在一起我就覺得渾身不舒服。
const [loading, setLoading] = useState(true)const [param, setParam] = useState('')const [list, setList] = useState([])const [error, setError] = useState('')所以我在使用 React 的過程中，做得最多的事情就是想辦法把這些 state 藏起來，用自定義 hook 重新封裝，并一定要改成對象解構的語法來使用。
const { loading, setParam, list = [], error} = useFetch(searchApi)又比如有的人覺得 solid.js 非常驚艷，是他理想中的樣子。但是我還是覺得 solid.js 的語法比 React 更讓我無法接受。
const [count, setCount] = createSignal(0);一方面是因為沿用了 React 的數組解構，另外一方面是因為返回的 count，他不是一個值，而是一個獲取值的方法。
因此我們使用的時候必須這樣用。
<div>count()</div>但同時，他又可以是一個值，例如我們這樣用的時候。
setCount(count => count + 1)這違背了我一直嚴格遵守的語義化和單一性，所以我主觀上不接受這樣的語法設計。
包括 solid.js 在 props 的處理上，為了確保修改之后的 props 具備響應性，不得不新增了兩個語法，mergeProps splitProps，這也是我不愿意接受的語法設計。
這種偏好其實非常主觀，但是確實是每個人都會或多或少有這樣的怪癖，會覺得別人的語法寫起來不舒服。
有的時候一個優秀的輪子你對他贊不絕口，然后用了半年之后，突然來了個需求，它滿足不了。賊難受。
于是很多程序員這個時候又不知道咋跟產品經理溝通，他會犯一個經典的職場錯誤：直截了當的告訴產品這個事情他做不了，甚至有的人會更夸張，還會解釋說這個需求我用的組件庫不支持所以我做不了。
這種溝通方式最大的問題，就是在跟同事暴露你技術能力不行。你可以用別的任何理由去拒絕這個需求，但理由一定不能是我實現不了這個需求。
如果一年中，你有 2 次出現這種情況，你就會發現你的年終績效會受到很大的影響。一年兩次這樣的頻率其實非常低，真實情況可能遠不止兩次。但是即使只是兩次，別人也會覺得你能力有問題。
所以別人的輪子往往會限制我們，哪怕他滿足了你 99% 的需求，如果突然來了一個需求滿足不了，就會讓你很難受，直接面臨職場危機。
有很多輪子是不得不用別人的。然后就經常遇到的一個問題就是，如果在特定場景之下遇到一個 bug，輪子作者也不會馬上幫你把這個 bug 給修復了。
你提的 issue 可能輪子作者隔了半年才反應過來可能會修復你這個問題。
有的時候修復這個 bug 也非常不容易。因為你特定場景的 bug，作者要復現可能比較困難，甚至會因為溝通問題，比如你提供的信息、版本、環境不充分，而導致作者根本就復現不了，導致最終也改不了你這個問題。
這個時候是最難受的。
所以我以前經常 fork 別人的輪子，然后去把他的源碼給改了，改個名字重新上傳到 npm 上，當成自己的輪子用。這樣雖然勉強解決了問題，但其實也并不是一個好的方案，因為后續的版本就開始完全分道揚鑣了，后續所有的改動都要你自己動手操作了。慢慢的也走上了造輪子的道路。
有的時候我們會發現別人的輪子跟我想要的場景不太匹配。
例如我需要一個圖表庫，我希望他能在網頁上跑，又希望他能在小程序上跑，還希望在 React Native 上也能跑。這樣對我來說，項目的維護成本是最低的。
實際上如果是我自己寫的輪子的話，我要做的兼容成本非常低。但是這種特定的需求可能別的輪子就不會專門幫你做這個事情。
于是我們就不得不在不同的平臺使用不同的輪子。難受的是，如果遇到定制化 UI，有的輪子支持得就不那么好，就會出現一個詭異的現象，明明能在 web 上做得非常好的功能，在 RN 上就搞得缺點意思，給人一種很古怪的感覺。
成熟的開源項目往往會考慮更多的因素，因此你常常會發現許多開源項目的源碼讀起來非常痛苦，各種條件判斷特別多。原因就是成熟的開源項目他需要兼顧更多的場景和需求。
但是在你的項目中，有可能不需要考慮那么多。
這樣我們自己造的輪子其實是可以更輕量，更簡單。例如我自己封裝的一個狀態管理器 mozz，只有 10 多行代碼，在特定的場景下結合我自己的項目架構思路，用了 5 年了也沒出什么問題，非常舒適。
所以我一直以來，對別的 React 生態中的狀態管理并不是很關注，因為他們內部到底是怎么實現的，具體的優缺點是什么，是否是我的項目所必要的我大概心里也有數。
在我公眾號文章里，前面介紹了幾種封裝狀態管理器的思路「半成品」，其實就覆蓋了好幾種狀態管理的實現原理，例如基于 reducer 和 useSyncExternalStore 的 zustand，基于 Atom 的 Jotai，只是在最終實現上，語法設計上會有所不同。
最最主要的原因是，造輪子能提高我們的個人技術能力。能造輪子的人，技術能力肯定是要比不能造輪子的人更強。
實際上很多人會覺得造輪子可能比較浪費時間。其實恰恰相反，這東西是可以不斷累積的。工作時間長了之后，你就會發現你需要親自造的輪子會越來越少。
然后到了后期，很多時候都是出了一個新框架，新平臺，你需要自己動手去做遷移和重寫。就比如這次鴻蒙開發起來了之后，我們的交流群里面就有幾個大佬在著手把以前自己寫的輪子重新在 arkUI 上寫一篇，花的時間也不是很多。
當然前期受限于技術能力和工作時間，造輪子會比較困難，甚至有的人會覺得無從下手。
那么我們有幾個方式可以走，首先就是先從簡單的輪子開始，例如在我職業生涯的早期，我自己寫了一個專門操作 cookie 的庫。
或者搞一個更簡單的，寫一個專門用來創建 css3 動畫的 JS 庫。
然后慢慢的逐漸深入，寫一個拖拽庫，或者寫一個動畫庫，寫一個輪播圖庫。
這些都是比較簡單就能做到，不需要太高昂的學習成本。只是很多人內心深處覺得這些事情根本沒必要，完全是在浪費時間而已。
打個小廣告：你也可以直接付費找我學習從零開始基于 canvas 打造一個 2D 可視化渲染引擎，費用 2000 元，助你快速提高技術能力，在面試時手握利器，不用為項目亮點而擔心。
有人不知道年終總結怎么寫，自己一年下來都在寫頁面，好像對團隊也沒什么特別的貢獻，想漲工資又不好意思找老板提。
想要晉升也不知道用什么去談。
我其實都沒怎么遇到過這種煩惱，因為每年都有產出和貢獻。這就是經常自己造輪子的一個非常大的好處。
因為實際上團隊內部有自己的技術沉淀這件事情本身就是非常重要的。因此你總會發現一些好的團隊總是非常熱衷于自己造輪子，然后你還會發現很多人會嘲諷這種現象。
對于這種嘲諷我們完全不需要理會，一方面是他們并不理解團隊技術沉淀的重要性，別人的技術終究是別人的，不管是從團隊角度或者從個人角度出發，盡可能少的受限于他人，本身就是我們應該追求的目標之一。
另外一方面是因為你拿到手上的是真金白銀，那些嘲諷的人又不會給你發錢。
總之在能力范圍之內，嘗試自己造輪子是我比較推崇的觀點。他的好處我有切身的體會。你也有機會認識更多的大佬，能更輕松的找到工作等等。
但是一定要操作得當，不要因為造輪子而導致任務總是 delay，一個好的方式就是把造輪子的事情上升到公司層面的需求，而不是自己私下悄悄搞，這樣的話就不用擔心任務 delay 這個事情了，你也有充足的時間和正當的理由來做這個事情。
當然這樣做也有壞處，就是以后你造的輪子就是屬于公司了，所以我當年這樣做雖然可以大量利用上班時間來通過造輪子提高自己的技術能力，但也導致了很多東西不能開源出來，屬于是有利有弊吧，自己權衡就好。
本文鏈接：http://www.tebozhan.com/showinfo-26-88351-0.html程序員為什么一定要去造幾個輪子
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號