都跟你說了不要造輪子了沒用的No.54

小蕉在接觸一些新的技術點的時候，都會抽空自己去寫一寫一些demo，包括之前的 SpringMVC 框架搭建，比如 Java 版本的 MapReduce ，比如Java版本的Pregel 框架，比如代理模式、觀察者模式、責任鏈模式的一些應用實例，以及現在正在寫的基於Google File System 的BigBanana File System。

現在各大開源社區這麼活躍，Spring， Pregel，Google File System，MapReduce，Tensorflow等這些框架都已經有了非常成熟的實現。既然已經有非常成熟的方案，為什麼小蕉還要自己去做這些底層框架的實現？是信不過這些框架，還是真的閑得？還是反正別人寫的我都不想用我就想用我自己的？

確實到了我們這個時代，造輪子已經不是一件值得去讚揚的事情了。為什麼呢？

原因有三個。

1、成熟的庫都是建立在非常多高手的努力下建立的。

2、成熟的庫有非常好的實踐經驗以及特殊情況處理，甚至性能比自己寫的還快。

3、處於能力原因，個人寫的庫，往往只能滿足特定業務場景，漏洞百出。

說實話，我們真的要承認自己的平凡。

我們沒那麼多的精力，沒那麼多的積累，沒那麼多的智商，去獨立造那麼多那麼多的輪子。在這個以開源和分享為主流的時代，還是以別人造好的輪子來快速實現一些業務需求，會比較高效。

但話又說回來，小蕉自己造的輪子最終可能非常少能上生產環境，但小蕉還是樂此不疲，為何？為什麼小蕉會去做這個事情呢？

原因只有一個。就是為了更加深入學習，把這些東西更深層次地理解，而不僅僅是掉各種包調各種參數。

自己搭建一次SpringMVC框架，才知道整個框架的調用棧，才知道SpringMVC為我們實現了 Servlet 封裝 ,DispatcherServlet是幹啥的，HandlerMapping 的映射又是怎麼存儲怎麼映射的。

自己實現一次代理模式，才知道Spring為我們屏蔽了這麼多的細節，作為容器是怎麼實現 AOP 的。

自己實現一次Google File System，才知道原來HDFS為我們做了這麼多的事情。數據分塊，數據校驗，負載均衡，API實現，集群管理，垃圾回收，文件索引。

自己實現一次MapReduce，才知道原來其中的map 和 reduce 的具體實現，怎麼驅動的，數據流文件流是怎麼流向的。

挖大坑開始，後面可能要自己實現一次卷積神經網路。

這也是最近看 Andrew NG 的 deeplearning.ai 教程中，一位大牛說起，"你只有自己去實現一遍卷積神經網路，才知道整個技術棧的流程和細節，才知道Tensorflow 為我們做了哪些事情，這樣在調用開源庫的時候會更加自信，而不是盲目調參"。

紙上得來終覺淺，絕知此事要躬行。

共勉。

喜歡的話點一下訂閱分享留言點贊，都是對我最大的支持。

讚賞一下，開心開心

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！