怎麼成技術大牛

Ⅰ 非科班出身，如何學好編程成為技術大牛

首先確定自己的位置： 一、菜鳥 第1 層樓屬於地板層，邁進這層樓的門檻是很低的。基本上懂計算機的基本操作，了解計算 機專業的一些基礎知識，掌握一門基本的編程語言如C/C++，或者Java，或者JavaScript，...， 均可入門邁進這層。 二、大蝦 從...

Ⅱ 怎麼樣成為編程技術大牛

編程技術是指利用計算機實現某種目的或解決技術問題，使用一些編程語言編寫程序代碼，最終得到結果。那麼怎麼樣才能成為變成技術大牛呢？

學習你所說的並不是你需要知道的，不是讀一本書和掌握它。使用數據在構造演算法方面，至少有5 ~ 10本書在這方面;在軟體設計方面，光理解結構設計和方向。設計和設計模式是不夠的，還需要理解軟體架構設計、交互設計、面向方面的設計和方向。設計的設計、數據結構演算法的設計、情感設計等，否則很難進入大牛這一樓層的。

主要還是多接觸，多看書，多編碼，多自己動腦子解決問題，多幫助別人，積累經驗。

Ⅲ 學習java，C++，大數據我們如何成為技術大牛

僅供參考：
0段—非程序員：
初學編程者，遇到問題，完全是懵懵懂懂，不知道該怎麼編程解決問題。也就是說，還是門外漢，還不能稱之為「程序員」。計算機在他面前還是一個神秘的黑匣子。

1段—基礎程序員：
學習過一段時間編程後，接到任務，可以編寫程序完成任務。
編寫出來的代碼，正常情況下是能夠工作的，但在實際運行中，碰到一些特殊條件就會出現各類BUG。也就是說，具備了開發Demo軟體的能力，但開發的軟體真正交付給客戶使用，恐怕會被客戶罵死。
程序員程序是寫好了，但到底為什麼它有時能正常工作，有時又不行，程序員自己也不知道。
運行中遇到了bug，或者需求改變，需要修改代碼或者添加代碼，很快程序就變得結構混亂，代碼膨脹，bug叢生。很快，就連最初的開發者自己也不願意接手維護這個程序了。

2段—數據結構：
經過一段時間的編程實踐後，程序員會認識到「數據結構+演算法=程序」這一古訓的含義。他們會使用演算法來解決問題。進而，他們會認識到，演算法本質上是依附於數據結構的，好的數據結構一旦設計出來，那麼好的演算法也會應運而生。
設計錯誤的數據結構，不可能生長出好的演算法。
記得某一位外國先賢曾經說過：「給我看你的數據結構！」

3段—面向對象：
再之後，程序員就會領略面向對象程序設計的強大威力。大多數現代編程語言都是支持面向對象的。但並不是說，你使用面向對象編程語言編程，你用上了類，甚至繼承了類，你就是在寫面向對象的代碼了。
我曾經見過很多用Java,Python,Ruby寫的面向過程的代碼。
只有你掌握了介面，掌握了多態，掌握了類和類，對象和對象之間的關系，你才真正掌握了面向對象編程技術。
就算你用的是傳統的不支持面向對象的編程語言，只要你心中有「對象」，你依然可以開發出面向對象的程序。
如，我用C語言編程的時候，會有意識的使用面向對象的技巧來編寫和設計程序。用struct來模擬類，把同一類概念的函數放在一起模擬類。如果你懷疑用C語言是否能編寫出面向對象的代碼，你可以看一下Linux內核，它是用C語言編寫的，但你也可以看到它的源代碼字里行間散發出的濃濃的「對象」的味道。

真正掌握面向對象編程技術並不容易。

在我的技術生涯中，有兩個坎讓我最感頭疼。
一個坎是Dos向Windows開發的變遷過程中，框架的概念，很長一段時間我都理解不了。Dos時代，都是對函數庫的調用，你的程序主動調用函數。Windows時代，則換成了框架。就算是你的main程序，其實也是被框架調用的。UI線程會從操作系統獲取消息，然後發送給你的程序來處理。Java程序員熟悉的Spring框架，也是這樣一個反向調用的框架。
現在因為「框架」這個術語顯得很高大上，因此很多「類庫」/「函數庫」都自稱為「框架」。在我看來這都是名稱的濫用。
「類庫」/「函數庫」就是我寫的代碼調用它們。
「框架」就是我注冊回調函數到框架，框架來調用我寫的函數。

另一個坎就是面向對象。很長一段時間我都不知道應該怎麼設計類和類之間的關系，不能很好的設計出類層次結構來。
我記得當時看到一本外國大牛的書，他講了一個很簡單、很實用的面向對象設計技巧：「敘述問題。然後把其中的名詞找出來，用來構建類。把其中的動詞找出來，用來構建類的方法」。雖然這個技巧挺管用的，但也太草根了點，沒有理論依據，也不嚴謹。如果問題敘述的不好，那麼獲得的類系統就會是有問題的。

掌握面向對象思想的途徑應該有很多種，我是從關系資料庫中獲得了靈感來理解和掌握面向對象設計思想的。
在我看來，關系資料庫的表，其實就是一個類，每一行記錄就是一個類的實例，也就是對象。表之間的關系，就是類之間的關系。O-Rmapping技術（如Hibernate），用於從面向對象代碼到資料庫表之間的映射，這也說明了類和表確實是邏輯上等價的。
既然資料庫設計和類設計是等價的，那麼要設計面向對象系統，只需要使用關系資料庫的設計技巧即可。
關系資料庫表結構設計是很簡單的：
1，識別表和表之間的關系，也就是類和類之間的關系。是一對一，一對多，多對一，還是多對多。這就是類之間的關系。
2，識別表的欄位。一個對象當然有無數多的屬性（如，人：身高，體重，性別，年齡，姓名，身份證號，駕駛證號，銀行卡號，護照號，港澳通行證號，工號，病史，婚史etc），我們寫程序需要記錄的只是我們關心的屬性。這些關心的屬性，就是表的欄位，也就是類的屬性。「弱水三千，我取一瓢飲」！

4段—設計模式：
曾經在網上看到這樣一句話：「沒有十萬行代碼量，就不要跟我談什麼設計模式」。深以為然。
記得第一次看Gof的設計模式那本書的時候，發現雖然以前並不知道設計模式，但在實際編程過程中，其實還是自覺使用了一些設計模式。設計模式是編程的客觀規律，不是誰發明的，而是一些早期的資深程序員首先發現的。
不用設計模式，你也可以寫出滿足需求的程序來。但是，一旦後續需求變化，那麼你的程序沒有足夠的柔韌性，將難以為繼。而真實的程序，交付客戶後，一定會有進一步的需求反饋。而後續版本的開發，也一定會增加需求。這是程序員無法迴避的現實。

寫UI程序，不論是Web,Desktop,Mobile,Game，一定要使用MVC設計模式。否則你的程序面對後續變化的UI需求，將無以為繼。

設計模式，最重要的思想就是解耦，通過介面來解耦。這樣，如果將來需求變化，那麼只需要提供一個新的實現類即可。
主要的設計模式，其實都是面向對象的。因此，可以認為設計模式是面向對象的高級階段。只有掌握了設計模式，才能認為是真正徹底掌握了面向對象設計技巧。

我學習一門新語言時（包括非面向對象語言，如函數式編程語言），總是會在了解了其語法後，看一下各類設計模式在這門語言中是如何實現的。這也是學習編程語言的一個竅門。

5段--語言專家：
經過一段時間的編程實踐，程序員對某一種常用的編程語言已經相當精通了。有些人還成了「語言律師」，擅長向其他程序員講解語言的用法和各種坑。
這一階段的程序員，常常是自己所用語言的忠實信徒，常在社區和論壇上和其他語言的使用者爭論哪一種語言是最好的編程語言。他們認為自己所用的語言是世界上最好的編程語言，沒有之一。他們認為，自己所用的編程語言適用於所有場景。他們眼中，只有錘子，因此會把所有任務都當成是釘子。

6段--多語言專家：
這一個階段的程序員，因為工作關系，或者純粹是因為對技術的興趣，已經學習和掌握了好幾種編程語言。已經領略了不同編程語言不同的設計思路，對每種語言的長處和短處有了更多的了解。
他們現在認為，編程語言並不是最重要的，編程語言不過是基本功而已。
他們現在會根據不同的任務需求，或者不同的資源來選擇不同的編程語言來解決問題，不再會因為沒有使用某一種喜愛的編程語言開發而埋怨。

Ⅳ 技術大牛是如何煉成的

• 如果回答對樓主有幫助，給個採納好不，謝謝啦

• 破侖說：不想當將軍的士兵，不是好士兵。無論你在做開發、測試、運維，你都是一個技術人員，而我相信，每個技術人員的心中，都有一個成為技術大牛的目標，這個目標鞭策著每一位有夢想的人，去努力和改進自己。 夢想總是在現實面前有過一度的彷徨，因為你會發現，真正的工作和心中的理想狀態天壤之別，不是一碼事。當你面對的是，天天加班寫業務代碼，每天都有執行不完的測試，扛機器接網線敲shell命令，你也許會懷疑，這是我想要的人生嗎？接下來，就讓我們帶著疑惑，去尋找答案！三大誤區誤區一：拜團隊技術大牛為師，給你開小灶首先，不可否認，大牛的確有能力將你鍛煉培養成另一位大牛，但是，無論是單獨給你開小灶，還是培訓整個團隊，時間成本消耗過大，因此，一般沒有大牛願意這樣做。其次，很多人都認為不懂就問是個好習慣，但是你忽略了很多問題大牛是不屑回答的，比如像「jvm的-Xmn參數如何配置」這種上網能找到答案的問題，只會浪費他人以及自己的時間。最後，大牛是個極具小眾的群體，因此，直接請教和輔導的機會非常少，即使有幸參加過幾次真正大牛的培訓，也不太可能讓你嫣然一變，成為技術大牛的。總而言之一句話，以自己為主，系統且有針對性的進行學習；然後再以請教學習為輔提升自己。誤區二：不斷重復，停滯不前首先，要認清一個事實，寫不好業務代碼和只把業務代碼寫好的程序員，在技術大牛的世界裡，沒有什麼本質的不同。如果光是沉浸在一個基礎技術里積累學習，那麼毫無疑問，這是你的慣性和惰性在束縛著你前進，打破它，不斷向更大的挑戰邁進，最終成為他人眼中的大牛。誤區三：大環境的不公與碎片化時間首先，大多數人都在抱怨中國的環境對於自己可能性的扼殺，並認為很多本來能成為大牛的人才被現實埋沒，不可否認，這個理由具有一定的客觀性，因為環境的確可以改變一類人的發展和命運。但是，如果我們轉過身來自問，是否自己真的已經傾盡全力？我相信，總是存在一些人，借著社會不公的理由，給予自己偷懶的借口；畢竟，大牛還是會有的，萬一就是你呢？其次，如果你抱怨現如今社會的碎片化時間，不能有整段時間提供自己深入學習，那麼，是否先改變自己的一個觀念，那就是碎片化時間也可以深入學習。而未來，利用碎片化時間學習將可能成為一種趨勢。正確的做法1、盡量多的嘗試當你每次都做得更多，隨著時間的發展，將會是這樣，產品討論需求找你、測試有問題也找你、老大對外支撐也找你，於是，你就成了這個系統的「專家」了。要想有機會，那就得與眾不同，努力做到更多。怎麼做得更多呢？可以從以下幾個方面著手：1）熟悉不止你負責的更多業務，熟悉不止你寫的更多代碼。好處：需求分析的時候更加准確，能夠在需求階段就識別風險、影響、難點問題處理的時候更加快速，因為相關的業務和代碼都熟悉，能夠快速地判斷問題可能的原因並進行排查處理方案設計的時候考慮更加周全，由於有對全局業務的理解，能夠設計出更好的方案2）熟悉端到端比如說你負責web後台開發，但實際上用戶發起一個http請求，要經過很多中間步驟才到你的伺服器（例如瀏覽器緩存、DNS、nginx等），伺服器一般又會經過很多處理才到你寫的那部分代碼（路由、許可權等）這整個流程中的很多系統或者步驟，絕大部分人是不可能去參與寫代碼的，但掌握了這些知識對你的綜合水平有很大作用，例如方案設計、線上故障處理這些更加有含金量的技術工作都需要綜合技術水平。3）自學一般在比較成熟的團隊，由於框架或者組件已經進行了大量的封裝，寫業務代碼所用到的技術確實也比較少，但我們要明白「唯一不變的只有變化」，框架有 可能要改進，組件可能要替換，或者你換了一家公司，新公司既沒有組件也沒有框架，要你從頭開始來做。這些都是機會，也是挑戰，而機會和挑戰只會分配給有準備的人。以java為例，大部分業務代碼就是if-else加個資料庫操作，但我們完全可以自己學些更多java的知識，例如垃圾回收，調優，網路編程等，這些可能暫時沒用，但真要用的時候，不是google一下就可以了，這個時候誰已經掌握了相關知識和技能，機會就是誰的。2、盡量做到更好世界上沒有完美的東西，你負責的系統和業務，總有不合理和可以改進的地方，識別這些「不合理」和「可改進」的地方，並且給出解決方案，然後向主管提出，一次不行兩次，多提幾次，機會，就是自己去爭取和把握。例如：重復代碼太多，是否可以引入設計模式？系統性能一般，可否進行優化？目前是單機，如果做成雙機是否更好？版本開發質量不高，是否引入高效的單元測試和集成測試方案？目前的系統太龐大，是否可以通過重構和解耦改為3個系統？阿里中間件有一些系統感覺我們也可以用，是否可以引入 ？3、盡量動手實踐光看不用效果差例如：學習了jvm的垃圾回收，但是線上比較少出現FGC導致的卡頓問題，就算出現了，恢復業務也是第一位的，不太可能線上出現問題然後讓每個同學都去練一下手，那怎麼去實踐這些jvm的知識和技能呢？Netty我也看了，也了解了Reactor的原理，但是我不可能參與Netty開發，怎麼去讓自己真正掌握Reactor非同步模式呢？看了《高性能MySQL》，但是線上的資料庫都是DBA管理的，測試環境的資料庫感覺又是隨便配置的，我怎麼去驗證這些技術呢？框架封裝了DAL層，資料庫的訪問我們都不需要操心，我們怎麼去了解分庫分表實現？怎麼辦？1）系統化的學習這個是第一階段，看書、google、看視頻、看別人的博客都可以，但要注意一點是「系統化」，特別是一些基礎性的東西，例如JVM原理、Java 編程、網路編程，HTTP協議等等，這些基礎技術不能只通過google或者博客學習，一般做法是先完整地看完一本書，有了全面的了解，然後再通過google、視頻、博客去有針對性地查找一些有疑問的地方，或者一些技巧。2）自己動手豐衣足食這個步驟就是解答上文提到的疑惑，也就是自己去嘗試搭建一些模擬環境，自己寫一些測試程序。例如：Jvm垃圾回收：可以自己寫一個簡單的測試程序，分配內存不釋放，然後調整各種jvm啟動參數，再運行的過程中使用jstack、jstat等命令查看jvm的堆內存分布和垃圾回收情況。這樣的程序寫起來很簡單，簡單一點的就幾行，復雜一點的也就幾十行。Reactor原理：自己真正去嘗試寫一個Reactor模式的Demo，不要以為這個很難，最簡單的Reactor模式代碼量（包括注釋）不超過200行（可以參考Doug Lee的PPT）。自己寫完後，再去看看netty怎麼做，一對比理解就更加深刻了。MySQL：既然有線上的配置可以參考，那可以直接讓DBA將線上配置發給我們（注意去掉敏感信息），直接學習；然後自己搭建一個MySQL環境，用線上的配置啟動；要知道很多同學用了很多年MySQL，但是連個簡單的MySQL環境都搭不起來。框架封裝了DAL層：可以自己用JDBC嘗試去寫一個分庫分表的簡單實現，然後與框架的實現進行對比，看看差異在哪裡。用瀏覽器的工具查看HTTP緩存實現，看看不同種類的網站，不同類型的資源，具體是如何控制緩存的；也可以自己用Python寫一個簡單的HTTP伺服器，模擬返回各種HTTP Headers來觀察瀏覽器的反應。3）交流分享，發現自己的不足之處。與人交流分享，既需要我們將一個知識點進行系統化的梳理，並且考慮各種細節，這會促使我們進一步思考和學習。同時，聽的人可以有不同的理解，或者有新的補充，這就令知識技能體系變得更加完善。後記無論結果怎樣，當我們談論過程的艱難與樂趣之時，是否可以不去計較自己是否付出太多？因為一個真正熱愛技術的人，只會勇往直前，不忘初衷，堅持到底！