米其林大廚做飯，大米不是自己種的，牛不是自己養的，酒不是自己釀的，做出來的飯是不是顯得沒有技術能力，只會用別人的東西。
你可能會說，大廚的廚藝就是他的技術能力，食材怎么處理、對火候的掌握、對材料用量的拿捏都是大廚的技術能力；
那你怎么就看不到程序員分析問題的能力、抽象和邏輯能力、架構和設計能力了呢？
使用輪子VS造輪子
我不否認，能夠自己造輪子的話，還是非常牛的，如果你有能力的話，可以開發維護你自己的“輪子”，如果輪子造的好，對你的跳槽、升職、加薪都會有幫助的。
但是在我們日常的開發中，“快速滿足業務需求”是第一要務的，為什么要快速？很多時候系統開發的快，業務展開的就快，就能領先對手搶占市場，說白了就是公司能掙到錢；這時候你選擇放棄使用Redis，自己動手開發一個緩存系統的話，先不說你的代碼質量如何（大概率是比不上Redis的），但說時間上，就是不允許的。
使用輪子也不是那么簡單的
大部分開源框架、中間件都是有使用場景的，所以如果在使用開源框架的時候，不考慮使用場景，也不考慮使用這個開源框架可能會帶來的問題，這樣也是很危險的。
比如為了減少數據庫訪問壓力，我們通常會把緩存熱點數據，如果數據量不大，使用本地緩存就夠了，就沒有必要非得引入Redis增加系統的復雜性；如果引入Redis的話，又會面臨緩存穿透、雪崩、擊穿等問題，所以你還需要在架構和開發中，避免這些問題。
所以能否把“輪子”使用好，也是需要一定能力的。
不能只停留在【使用】這個層面
對于開源框架，很多程序員認為只要會用就行了，比如要操作Redis，只要知道怎么使用RedisTemplate，里面常用的方法有什么就夠了，直到這個程度的話，對于程序員能力的提高是有限的。
通常我們除了要了解是什么，怎么用之外，還需要知道其使用場景，優缺點，如何解決可能帶來的問題；如果是一些比較經典的框架和組件，建議最好能了解其中的原理、設計思想，甚至是代碼細節。