邊學邊在專案中使用，半年已經足夠了。不實際使用，可能十年也就瞭解的程度，所以，能動手就別bb，跑一跑什麼知識都瞭解了。生產上出了問題，部門老總在你背後看著解決，幾次你就成專家了。

時間長短在於自身對基礎知識的掌握程度，以及軟體、框架的架構及背後實現的邏輯，具體還是需要應用到實際的專案中，多實踐，多應用。

根據通常的1萬小時定律，一般要成為某個行業裡的專家，需要在這行業裡工作1萬個小時。但是軟體行業不一樣，他是一個迭代更新非常快的行業。特別是系統架構。要是你研究一個系統框架1萬個小時，那麼這個框架說不定已經過時了。

學習某一個技術框架，成為這個框架的專家水平。我覺得因人而異。有些技術基礎紮實的人，或者本身就是其他技術架構的專家，那麼他學習一個新框架，估計1,2個月就差不多了。如果是一個有潛力的小白，那麼我個人認為要成為該領域的專家，至少需要2-3年的潛心研究。還要透過專案的實踐才能成為技術專家水平。當然如果你只是拿著框架在使用，不潛心研讀他的底層程式碼，那麼你至多能成為一個熟練的老手，很難成為專家。這是個人的淺見，歡迎批評指正

任何一門技術，框架，有需要從瞭解，熟悉，能用，再到會用等過程。要達到專家級別水平，沒有個三年五載很難達到。

這個問題，我想起一個博士的話，一門模式的程式語言，一個月我就入完門了。現在只談我自己的情況，應該就一個月左右的時間，說不上達到專家級，超越70%人應該是可以的，夠用了。如果我想學新知識，先買書，再看入門部落格知識點，動手實驗實驗，找人交流交流。作為程式設計師，寫的程式碼要符合設計模式，程式寫給CPU看，更重要的是寫給未來的自己、同行看，大家的技術才能一起上一層樓。

框架就是別人給你制定的條條框框，學會了就像工廠的流水線上的操作工一樣會幹活了，不過換一個流水線你還得掌握另一些條條框框，專家、架構師就是給你制定條條框框的人。很多程式設計師以掌握某個架構然後自稱架構師然後指點江山，指責其他不會某個架構的人，心中充滿了偉大感，是不是很可笑；如同一個生產線上的操作工自稱掌握了這條生產線。

IT行業技術更新很快，各種新框架新技術層出不窮。就拿本人從事的大資料領域來說，從第一代大資料框架hadoop，到現在的記憶體計算spark，以及現在火熱的flink，都需要與時俱進的進行學習和了解。其實當你進行技術沉澱時，會有一種技術萬變不離其中的感覺，歸根到底這些技術底層的核心原理是共同的，把核心的基礎打好，再學這些高層抽象的框架會有事半功倍的效果。至於時間的話看個人的技術積累程度了

因人而異，如果有基礎，資料結構+演算法基礎好，學習框架很快，1-3個月即可熟練運用，而如果缺乏基礎可能得半年、一年。從我自身來講學習某一框架需要學習1個月到1年不等，再實踐3年，才可以說是非常熟悉，瞭然於胸了。

當然也看框架和軟體本身的複雜度，越複雜自然學起來越難，同時框架跟某特定業務有關，如果你從事這個方向自然就容易熟悉。比如做Web要熟悉Spring全家桶、Nginx，做大資料熟悉Hadoop系列，做ai熟悉PyTorch或TensorFlow等。框架或軟體是分領域的，如果所從事的非這個方向，往往學起來很費勁。但如果是同一方向，是手到擒來，輕鬆無比。

你說的專家不知是個什麼概念，如果只是能夠做到熟練運用，那不是太難，一個能力尚可的程式設計師一般都能一通百通，學習和精通一門語言、框架從幾個月到二三年不等，但這絕對算不上專家，也就普通軟體工程師水平。

要達到計算機領域的專家絕非易事，而且也不是精通某一框架或軟體這麼簡單，至少得要在某一領域取得一定的技術成果，我覺得一般擁有正高職稱的稱之為專家應該不心虛，副高職稱的免強也算。

絕大多數程式設計師有生之年都達不到專家水平，不是能力問題，而是為了生計不得已在技術層面停留太久，沒機會鑽研更深層次的東西。相反有些科研機構鑽研某一技術時間長了能夠成為這一領域的專家。

只學習很難達到專家的水平，有了基礎，學習一個框架很容易，但是不實踐，出不來真正的專家，不經歷風雨出怎麼算專家。

本人從事手機遊戲研發，行業經驗5年，除開渲染以外，客戶端的其他面都能獨擋。技術更新比較快。剛要熟練一種框架或者設計的時候，新的框架技術又更新出來。我覺得思維和學習能力更重要，要選擇合適當前技術和平臺最快的解決問題。

如果是已經有程式設計經驗的話，學習能框架，特別快！！

看你每天花多少時間！

比如每天你花三個小時到四個小時左右，你大概一個月，就能掌握一門比較成熟的框架！

假如說你每天花半個小時到一個小時，你可能得2到3個月，甚至四個月，才能熟練的掌握一門框架，並利用它來開發！

如果是有有3到5年工作經驗的朋友，他學習一門新的語言，或者新的框架可能1到2個星期，基本上就能應用了！

我在做開發的頭三年的目標，是讓自己成為垂直業務方面的開發熟手。

4-5 年，我讓自己成為了專家，人家有問題了常常來問我，業務和架構上我也有自己的見底與把握。

6-8 年，梳理業務、做架構、帶團隊，總結和提煉技術能力與思想。

從開發生涯伊始，學習方法論、各種思想、最佳實踐（包括看原始碼），嘗試一些新東西，這個階段漫長而有彈性，不斷實踐與總結，行事方式固化為習慣，最大的收穫就是開始做某一項事情時，心裡有底，有思路有方向有方法，不會抓瞎，少走彎路。

學習程式碼的人和編寫程式碼的人如果不在一個理解層面，閱讀並不能幫到你什麼，更不能說通過了解了程式碼的實現就成為了這個領域的專家。瞭解程式碼實現頂多只能應付面試問題，當別人問題為什麼的時候，答案並不在程式碼實現當中。

閱讀程式碼的精髓在於你完全瞭解了作者在領域中面臨的問題，並在紛繁複雜的程式碼邏輯中抓出了作者解決這個問題的關鍵。自稱熟讀過的人，其實少有人能做到

這個收穫很難用量化來衡量，但就像蓄水池，越蓄越多的感覺。

所以題主你提的三個“明白”，不是說不重要，但太死板，天天坐在那裡看原始碼看書是看不出什麼來的，必須定好眼下要達標也可操作的 Flag，結合業務去追求跟實現，不斷實踐與總結。

天天看框架原始碼，即使你寫出一個框架來，在業務實現方面你可能仍是 newbie；你就算花再多時間在編譯器知識上，但是業務跟編譯器毫無關聯，你的編譯器知識也不可能提升。

總之先考慮好第一步——定好眼下要達標也可操作的 Flag，結合業務去追求跟實現，不斷實踐與總結。想太多會提升焦慮感，虛無還沒好處，目標定得太完美就是失敗。

研究框架是程式設計師到達專家水平無法逾越的一到難題，一般來說研究到程式專家最少需要3到5個月。首先要學習框架語言，瞭解語言的邏輯原理，其次瞭解各個引數的運用。還要經常和同行業的在職人員保持良好的溝通。

每個人對專家都有不同的定義，我眼中的專家則偏向於能夠看清楚當前領域方向，能引導未來設計的，這種才可以稱為專家，專注點是可以設計和行業未來的人，甚至是根據paper設計出行業領先系統的人

大多數人的水平我感覺都不足以達到這個水平，大多數人的程度就是能夠看懂原始碼和關鍵核心就可以成為大多數人眼中的小專家了，比如訊息佇列，你可以看懂kafka原始碼裡面的關鍵設計比如怎麼設計磁碟儲存？利用作業系統特性？怎麼設計高效能、高可用架構？怎麼提高系統的吞吐？如何應對故障處理？這些其實就可以滿足大家工作中80%的場景了

達到這個水平應該並不需要幾年的時間，首先看下官方文件的核心特性介紹與使用，然後在自己的專案中去實踐，最後去讀一下核心流程的原始碼， 這個過程其實也並不是那麼漫長，但是有一個問題，就是你到底能讀懂多少？

從計算機底層開始說起(別說微機電路與CPU硬體那些)，最下層可能就是作業系統了，作業系統如何提供記憶體、IO、CPU、網路等資源的抽象，這裡面有那些特性是我們可以借鑑的？然後就是linux核心的一些設計，再網上層就是各種資料結構和演算法，然後就是各種模式，併發模式、設計模式、架構模式？再接著如果是分散式系統還有各種分散式、網路、共享等問題，最後特定領域往往還有專門的設計，這些基礎你掌握的多少，直接回決定你讀原始碼能夠讀懂多少，路漫漫何其遠兮，但是你會發現這方面其實外面的機構基本不會講，其實這些才是真正的核心，但是很少有人會修煉，祝你好運

從事軟體開發十幾年了，對於程式設計師的工作有一點自我的見解，首先程式設計師的工作屬於一個技術活，技術類的工種需要時間的積累，但要達到某個領域的技術專家，首先是時間層面的積累，但僅僅是積累是不夠的，不是達到多少年一定成為技術的專家，成為某個領域的佼佼者，時間只是其中一個因素。

牢固的基本功。要達到某種境界沒有牢固的基本功做鋪墊幾乎是不可能的事情，程式設計師要說到基本功其實是一種很籠統的說法，基本功不僅僅是程式語言的語法，還包括常見的一些程式設計技巧，還包括一些基本的演算法基礎，不同的人對於基礎的理解也不相同。對於初學者理解基礎就是程式語言的語法，從心理上覺得程式語言的語法搞定了，但在真正意義上的程式設計的時候，只是掌握基本的語法是實際的程式設計經驗需要在專案中提煉。

如果放在技術專家的要求來定義基本功又會是另外的一個境界，從心理上要認識無論哪個層次的程式設計師都要重視基本功的積累，在平時工作之餘要拿出時間來溫習基本功，按照一個標準的程式設計師的要求看認識基本功，常見的專案有程式語言的語法，專案操作過程中遇到的一個困難的總結匯總，資料結構基礎演算法，常見的程式設計場景處理能力，這些都屬於程式設計基本範疇。

程式設計框架能力。這點就足夠拉開了和普通程式設計師的區別，之所以能夠在一個行業內成為頭部的玩家，就需要具備一定的高層設計能力，這種能力不僅僅是簡單的模組設計能力，還需要具備整個系統的設計開發能力，有些程式設計師做一輩子都未必真正設計搭建過一個框架，所以不能簡單的認為能夠設計好一個模組的框架就能把事情做得非常利索了，不能簡單的認為。

其實框架能力在行業內講就是造輪子的能力，當然不是每個人在自己的技術生涯中都有設計框架的機會，如果能夠趕上一次也是不錯的機會。

堅韌不拔的意志。這點主要是在精神層面的，不是每個人都能在一個領域長期堅持不懈的待下去的，能夠數十年如一日堅持做好一件事都是對人毅力最大考驗，能夠一直堅持做這件事人數已經不多了，如果在加上做的出色的數量將會變得更少了，所以講工匠精神不是每個人都能堅持做到最後的。

從這個問題的描述來看，顯然是有一個前提的——程式設計師。

那麼針對“程式設計師”這個稱號，顯然還應該再從兩個方面來將問題分解。

一、初級程式設計師

作為一個剛剛入行不久的初級程式設計師，他自身可能對某一個程式語言的程式設計語法和 API 比較熟悉，但是對基於這門語言實現一些實際的專案和應用，可能還停留在瞎子摸象或者井底青蛙的層面（這裡沒有貶義，只是做一個比喻）。那麼這種情況下，要研究某一個框架、軟體，他就會缺少很多其他層面的知識、技能、經驗的儲備。比如你只是一個初級的前端開發者，剛剛熟練編寫 HTML/CSS/JavaScirpt前端 Web，那麼要研究 nginx、Node.js、Vue.js、Angular 4+、Flask 等等，可能前期就會顯得比較吃力。因為這些軟體、平臺、框架裡，包含了關於負載均衡排程、request/response、依賴注入、Component、Python裝飾器、路由、重定向等基礎知識。

那麼要達到該領域的技術專家的水平，因為這位程式設計師可能平時還要上班，所以在保持勤奮的前提下，大約需要 3 個月左右的業餘時間完整的學習有關的知識。

但是僅有這些還不夠，還不能形成你的能力。另外還需要 2~3 個月的時間，好好利用新的框架去開發實現若干個專案，而且這些專案還不能太簡單，必須要有一定的複雜度。

只有這樣，你的開發經歷才能更全面的覆蓋到這個框架的更多的方面，才能稱之為技術專家。

二、中高階程式設計師

這類人群已經在程式設計師領域有了一定的工作年限，也有了一定的開發經驗。他們已經掌握了一些框架和軟體等技術。那麼他們面對新的框架和軟體，會根據自己以往的經驗和技術邏輯去領會新框架的原理。古語中對於一項技能有“道”與“術”的區別。那麼這些中高階程式設計師對新框架的“道”的方面已經瞭然入心，因為這些新的框架其實與他們以前掌握的那些在邏輯架構和執行原理方面都是很相似的，他們需要學習的僅僅是原理上的不同，還有在程式設計語法、實現方式上的不同而已，那麼這就是“術”的層面，而“術”是很容易掌握的，就好比是從模仿到掌握的過程。

從來不覺得技術專家是研究哪個框架，那種設計語言就可以。①你需要多接觸大專案，你才有可能理解什麼叫“”業務需求不是你的技術需求”。②獨立思維能力，能從複雜的業務場景中梳理出一定的邏輯順序，預見一些別人想不到的業務場景，之後提交不同領域去討論，這個過程中，你會體會什麼叫“說人話”。③分水嶺。如果你執著技術，你會發現，想做專家，你需要重新學習你大本時候最討厭的一門課程，“高等數學”。如果你轉向業務實現，你會發現，想做專家，你可能要不斷深入現實中的業務場景，甚至掃垃圾這種最低階的工作，你都應該有切身的體驗才可以。

我是不太敢稱自己為專家，對於一些軟體、框架的掌握，我甚至都不敢說自己“精通”，最多也就是熟練掌握，倒不是因為我謙虛，一方面確實認為想要在一個領域達到專家的水平是非常有難度的，自認為達不到這個程度，另外一方面，就是覺得如果是軟體、框架這個層次，不一定非要做到專家水平，設定可以說沒必要做到專家的程度。

具體給一個時間長度沒有意義，因為難易程度不同、每個人的基礎不同、學習的背景和出發點不同：

我認為最快掌握一個框架，就是“被逼無奈”、“走投無路”的時候，為了解決專案上的某個棘手的問題，學習一個作為解決方案的框架或軟體，這個過程是最快的；我曾經開發一個新專案，時間週期特別的緊，專案中需要使用 Kafka，從搭建、整合、使用，再到略加深入的研究，前後大概花了兩週的時間；當然，也只能算作“熟練掌握”罷了；

在學習 Kafka 的過程中，因為之前我對 RabbitMQ 有一定的瞭解，所以學習起來會比較快，很多的時候我是在比較兩者的不同，而如果對訊息佇列沒有一點了解的程式設計師學習 Kafka，可能會花費更長的時間；

如果工作中沒有特殊的要求，我學習一門框架的時間可能就長短不一了，可能幾天、幾周，甚至是幾個月，而更多的時候，因為沒有碰到過實際的問題，所以你很可能不會把每一個框架都做深入的研究。

跟其他的行業相比，軟體行業的變化很快，技術更新的頻率極高，比如醫生可以始終在某一個非常小的領域進行研究，我就研究眼科，或者就一直做牙醫，做一輩子，成為眼科的專家，但是程式設計師不行，你說我一輩子就研究 Spring 吧，將自己的技術積累押寶在當前某一個流行的軟體或框架上，這個風險非常大；短期內可能會有成效，但是我們的職業壽命要四十年甚至更長。

有些程式設計師在某些大公司混的風生水起，非常熟悉公司的技術棧，但是當他換一個公司、換一個平臺的時候，可能就會遇到發展的瓶頸；這是因為作為的“某一領域的專家”，只是依賴於當前公司這個平臺，但不一定可以匹配市場的需求，錯把平臺資源當成自己的能力。

我十幾年前剛成為 Java 程式設計師的時候，最流行的就要數 SSH 了，也就是 Spring 、Struts 和 Hibernate，現在再看看，Struts 幾乎絕跡，Hibernate 半死不活，Spring 雖然很火，也是因為版本迭代的很快；

所以十年前我要是選擇了一直研究 Spring 還好，要是選擇押寶了 Struts ......

軟體、框架的更新時很快的，我們不能把主要的精力放在它們身上。

在學習 Spring Cloud 、Dubbo 的時候，也要學習架構設計和演變；

在學習程式語言的時候，也要學習設計模式；

在學習通訊框架的時候，也要把網路模型學習好；

學習 Angular、React、Vue 一堆框架，不如先把精力放在 HTML/CSS 上...

總之，基礎打得牢，框架學的快，不要把百分百的精力都放在這些不斷變化的框架上。

有個一萬小時定律，意思是在某領域投入一萬小時就會成為專家，計算機領域基本也符合這個規律。