今天來寫一篇雞湯帖。
1. 重複造輪子有意義嗎？
重複造輪子，大部分一聽感覺浪費時間和經歷去搞一個別人已經開源的東西，花了時間可能還沒搞的別人效果好，何不直接拿別人的過來直接用了，確實非常有道理。
而且工作任務完成過程中，有時候工期緊，要求功能又多，很多都需要建立在別人的基礎上完成，輕鬆又快，快速完成交付，老闆又賞識，簡直完美。
以上觀點我非常贊成，我也經常這樣在工作做，節省的自己的時間。
但是還有另外一個角度，拋開工作工期，有交付壓力的情況下，個人覺得有想法的情況下有必要去造輪子，經常從網上或身邊聽到某某面試，問他簡歷上的東西，比如部署過某某產品，面試官問怎麼部署的，面試者回答拿公司現成的工具部署的啊。顯示這不是面試官想要的答案，但站在面試者的角度上確實說的是實話，的確幹過這個專案，也確實都是公司現有的工具，尤其在大公司，這種現象可能多一點，因為流程工具都非常完善，只需關心業務就好了，但可能業務寫多了就變成CV（複製貼上）大神。
就像是學知識一樣，只有把別人變成自己的，然後再去實踐才是真正的懂了。網際網路技術個人感覺寫出來和會用是完全兩回事。只有真正去寫的時候才知道坑在哪裡，是不是哪裡執行緒不安全啊，高併發的情況如何保證資料一致性啊等等。
所以從個人成長的角度出發，重複造輪子還是有必要的，當然得拋開工作交付壓力的情況下，強調這個是因為實際工作專案中，用別人更好的且已經完善的東西，顯然對專案本身來說是非常好，拿公司錢就得把事情做好。在業務沒有交付壓力的情況下，個人建議多嘗試先想自己如何實現，就算之後用的別人的東西，你看看原始碼，知道人家如何實現，也就不會出現上面說的面試中遇到懵逼的問題了，簡歷上自己的專案如果都回答不好，會給面試官不太好的印象。
2. 談談我從造輪子裡的收穫
簡單談談我造輪子中的收穫吧，比如寫技術部落格，很多知識點網上很多已經寫過了，如果這樣是不是覺得沒必要寫了，直接看就好了，個人實踐發現寫的過程中還是有些知識點寫的時候才發現原來之前都理解錯了，同時更加能加深對知識點記憶。比如我寫了上一篇MySQL索引原理，現在對B-Tree資料結構和磁碟原理理解比較清晰點，以前就覺得這種高階資料結構離我很遠。
去年我重新造輪子封裝了一個非常輕量的ORM，緣起也是因為業務中用別人的有點不爽，就想自己看看能不能封裝一個，平時也沒有時間去寫，就國慶在家擼了7天。寫完之後，遇到很多坑，再去看牛人寫的ORM，才知道程式碼還可以這麼寫，對MySQL的語法和ORM的常規實現都有了一定的理解。之前也還造過類似elasticdump的指令碼，費了很大神，執行一段時間才知道有elasticdump的存在，果斷換了elasticdump，雖然結果上最終用了elasticdump，但是過程還是蠻多收穫，同時也會激起你去看原始碼的衝動。
最近在接觸專案裡有接觸到RPC，我就有想法去了解原理，重新造輪子，但你可能會問時間和精力問題。工作時間內去造這種輪子，是不太現實的，確實。只有犧牲自己的業餘時間，去寫這種對自己能力提升有幫助的輪子，這是值得的。之前看動漫，主角修仙者都是閉關多久出來才成了厲害角色，角色只是讓我們看到了結果，但是想想閉關期間，吃飯睡覺都在修煉，所以要想成為大牛。
哈哈，雞湯帖結束，希望大家事業上都能修道成仙，來分享你的故事。
更多精彩文章，歡迎關注公眾號： 「天澄技術雜談」
