米其林大廚做飯，大米不是自己種的，牛不是自己養的，酒不是自己釀的，做出來的飯是不是顯得沒有技術能力，只會用別人的東西。

你可能會說，大廚的廚藝就是他的技術能力，食材怎麼處理、對火候的掌握、對材料用量的拿捏都是大廚的技術能力；

那你怎麼就看不到程式設計師分析問題的能力、抽象和邏輯能力、架構和設計能力了呢？

使用輪子 VS 造輪子

我不否認，能夠自己造輪子的話，還是非常牛的，如果你有能力的話，可以開發維護你自己的“輪子”，如果輪子造的好，對你的跳槽、升職、加薪都會有幫助的。

但是在我們日常的開發中，“快速滿足業務需求”是第一要務的，為什麼要快速？很多時候系統開發的快，業務展開的就快，就能領先對手搶佔市場，說白了就是公司能掙到錢；這時候你選擇放棄使用 Redis，自己動手開發一個快取系統的話，先不說你的程式碼質量如何（大機率是比不上 Redis 的），但說時間上，就是不允許的。

使用輪子也不是那麼簡單的

大部分開源框架、中介軟體都是有使用場景的，所以如果在使用開源框架的時候，不考慮使用場景，也不考慮使用這個開源框架可能會帶來的問題，這樣也是很危險的。

比如為了減少資料庫訪問壓力，我們通常會把快取熱點資料，如果資料量不大，使用本地快取就夠了，就沒有必要非得引入 Redis 增加系統的複雜性；如果引入 Redis 的話，又會面臨快取穿透、雪崩、擊穿等問題，所以你還需要在架構和開發中，避免這些問題。

所以能否把“輪子”使用好，也是需要一定能力的。

不能只停留在【使用】這個層面

對於開源框架，很多程式設計師認為只要會用就行了，比如要操作 Redis ，只要知道怎麼使用 RedisTemplate，裡面常用的方法有什麼就夠了，直到這個程度的話，對於程式設計師能力的提高是有限的。

通常我們除了要了解是什麼，怎麼用之外，還需要知道其使用場景，優缺點，如何解決可能帶來的問題；如果是一些比較經典的框架和元件，建議最好能瞭解其中的原理、設計思想，甚至是程式碼細節。

總之，如果沒有能力造輪子的話，就一定要：不僅會用，還要用得好，最好能知其然也知其所以然。

java專案中總是用開源框架是不是顯得自己沒有技術能力，只會用別人的東西？

使用開源框架本身沒有問題，而且這也是公司要求。

開源框架優勢

簡化開發流程

透過開源框架可以簡化開發的過程，提升開發效率。同樣的工作，做一次就可以，沒有必要反覆來做。

更加規範化

由於開源框架的使用都必須按照其規範，例如使用Spring MVC，需要遵守其開發規範，按照其要求使用框架。比自身使用Serverlet開發將會更加規範。

開源框架弊端

開源框架自身的安全漏洞

java 開源框架中，無論是鼎鼎大名的Tomcat 還是Struts 都是出現過重大安全問題。這對於某些重要領域將會產生非常嚴重的後果。後來，京東就放棄了Struts.

開源框架隱藏問題，導致無法準確的定位異常

第三框架經常處理異常時，自定義異常把原生異常直接覆蓋，無法快速定位。

框架增加程式複雜度

有些框架非常龐大且複雜，大部分開發者只是使用階段，對於出現的異常無法處理。

總結

在Java 專案中，一般都是時間緊任務重，為了快速開發都是儘量採用第三方的框架結構。這是很現實的情況，公司沒有時間去培養開發者自己開發一套自身的專案框架。

但作為開發者，在休息時。一定要及時的補充能量。學習一些優秀的開源框架可以迅速幫助開發者成長。

Java 開源框架中，Tomcat與Spring的原始碼是必修課。可以學習這個世界上最優秀的一批人寫的程式碼，從設計模式，程式碼設計甚至包括命名，註釋，最新的Java特性。都可以學習。

使用輪子本身沒有問題，但要有創造輪子的能力。

當下，網際網路時代。IT技術的更新迭代非常迅速，只有一直堅持學習，才能走的更加長遠。

可以這樣回答，你找的就是這樣的活，公司招的就是這樣的人，職位不同乾的活不同，本來讓你過來幹活出活的，沒想到天天研究自己寫架構，當然了招聘一個架構師讓你研究架構的不管你是自己寫還是用零件組合都是架構的事情，那架構師天天crud那就是說不過去了 就是在混日子！

淘寶底層也是用別人的東西，它沒技術含量嗎？

重複造輪子有用嗎，能站在巨人肩膀上才不會重複造輪子。