{eval=Array;=+count(Array);}
從事軟件開發十幾年了,對于程序員的工作有一點自我的見解,首先程序員的工作屬于一個技術活,技術類的工種需要時間的積累,但要達到某個領域的技術專家,首先是時間層面的積累,但僅僅是積累是不夠的,不是達到多少年一定成為技術的專家,成為某個領域的佼佼者,時間只是其中一個因素。
牢固的基本功。要達到某種境界沒有牢固的基本功做鋪墊幾乎是不可能的事情,程序員要說到基本功其實是一種很籠統的說法,基本功不僅僅是編程語言的語法,還包括常見的一些編程技巧,還包括一些基本的算法基礎,不同的人對于基礎的理解也不相同。對于初學者理解基礎就是編程語言的語法,從心理上覺得編程語言的語法搞定了,但在真正意義上的編程的時候,只是掌握基本的語法是實際的編程經驗需要在項目中提煉。
如果放在技術專家的要求來定義基本功又會是另外的一個境界,從心理上要認識無論哪個層次的程序員都要重視基本功的積累,在平時工作之余要拿出時間來溫習基本功,按照一個標準的程序員的要求看認識基本功,常見的項目有編程語言的語法,項目操作過程中遇到的一個困難的總結匯總,數據結構基礎算法,常見的編程場景處理能力,這些都屬于編程基本范疇。
編程框架能力。這點就足夠拉開了和普通程序員的區別,之所以能夠在一個行業內成為頭部的玩家,就需要具備一定的高層設計能力,這種能力不僅僅是簡單的模塊設計能力,還需要具備整個系統的設計開發能力,有些程序員做一輩子都未必真正設計搭建過一個框架,所以不能簡單的認為能夠設計好一個模塊的框架就能把事情做得非常利索了,不能簡單的認為。
其實框架能力在行業內講就是造輪子的能力,當然不是每個人在自己的技術生涯中都有設計框架的機會,如果能夠趕上一次也是不錯的機會。
堅韌不拔的意志。這點主要是在精神層面的,不是每個人都能在一個領域長期堅持不懈的待下去的,能夠數十年如一日堅持做好一件事都是對人毅力最大考驗,能夠一直堅持做這件事人數已經不多了,如果在加上做的出色的數量將會變得更少了,所以講工匠精神不是每個人都能堅持做到最后的。
要想成為程序員里面某個領域的專家,不是僅僅靠時間來積累出來的,但時間的積累達到的一個典型的基礎,不要覺得入行的時候自己的基礎不好,但時間長了堅持的長了,常見的編程模式或者套路也都能掌握清楚了,不是誰天生就是某個項目的專家,什么事情就怕一個堅持的勁頭,一股不服輸的精神,堅持的時間長了在理論上還能縮減成為專家的次數,希望能幫到你。
我是不太敢稱自己為專家,對于一些軟件、框架的掌握,我甚至都不敢說自己“精通”,最多也就是熟練掌握,倒不是因為我謙虛,一方面確實認為想要在一個領域達到專家的水平是非常有難度的,自認為達不到這個程度,另外一方面,就是覺得如果是軟件、框架這個層次,不一定非要做到專家水平,設置可以說沒必要做到專家的程度。
具體給一個時間長度沒有意義,因為難易程度不同、每個人的基礎不同、學習的背景和出發點不同:
我認為最快掌握一個框架,就是“被逼無奈”、“走投無路”的時候,為了解決項目上的某個棘手的問題,學習一個作為解決方案的框架或軟件,這個過程是最快的;我曾經開發一個新項目,時間周期特別的緊,項目中需要使用 Kafka,從搭建、集成、使用,再到略加深入的研究,前后大概花了兩周的時間;當然,也只能算作“熟練掌握”罷了;
在學習 Kafka 的過程中,因為之前我對 RabbitMQ 有一定的了解,所以學習起來會比較快,很多的時候我是在比較兩者的不同,而如果對消息隊列沒有一點了解的程序員學習 Kafka,可能會花費更長的時間;
如果工作中沒有特殊的要求,我學習一門框架的時間可能就長短不一了,可能幾天、幾周,甚至是幾個月,而更多的時候,因為沒有碰到過實際的問題,所以你很可能不會把每一個框架都做深入的研究。
跟其他的行業相比,軟件行業的變化很快,技術更新的頻率極高,比如醫生可以始終在某一個非常小的領域進行研究,我就研究眼科,或者就一直做牙醫,做一輩子,成為眼科的專家,但是程序員不行,你說我一輩子就研究 Spring 吧,將自己的技術積累押寶在當前某一個流行的軟件或框架上,這個風險非常大;短期內可能會有成效,但是我們的職業壽命要四十年甚至更長。
有些程序員在某些大公司混的風生水起,非常熟悉公司的技術棧,但是當他換一個公司、換一個平臺的時候,可能就會遇到發展的瓶頸;這是因為作為的“某一領域的專家”,只是依賴于當前公司這個平臺,但不一定可以匹配市場的需求,錯把平臺資源當成自己的能力。
我十幾年前剛成為 Java 程序員的時候,最流行的就要數 SSH 了,也就是 Spring 、Struts 和 Hibernate,現在再看看,Struts 幾乎絕跡,Hibernate 半死不活,Spring 雖然很火,也是因為版本迭代的很快;
所以十年前我要是選擇了一直研究 Spring 還好,要是選擇押寶了 Struts ......
軟件、框架的更新時很快的,我們不能把主要的精力放在它們身上。
在學習 Spring Cloud 、Dubbo 的時候,也要學習架構設計和演變;
在學習編程語言的時候,也要學習設計模式;
在學習通信框架的時候,也要把網絡模型學習好;
學習 Angular、React、Vue 一堆框架,不如先把精力放在 HTML/CSS 上...
總之,基礎打得牢,框架學的快,不要把百分百的精力都放在這些不斷變化的框架上。
邊學邊在項目中使用,半年已經足夠了。不實際使用,可能十年也就了解的程度,所以,能動手就別bb,跑一跑什么知識都了解了。生產上出了問題,部門老總在你背后看著解決,幾次你就成專家了。
因人而異,如果有基礎,數據結構+算法基礎好,學習框架很快,1-3個月即可熟練運用,而如果缺乏基礎可能得半年、一年。從我自身來講學習某一框架需要學習1個月到1年不等,再實踐3年,才可以說是非常熟悉,了然于胸了。
當然也看框架和軟件本身的復雜度,越復雜自然學起來越難,同時框架跟某特定業務有關,如果你從事這個方向自然就容易熟悉。比如做Web要熟悉Spring全家桶、Nginx,做大數據熟悉Hadoop系列,做ai熟悉PyTorch或TensorFlow等。框架或軟件是分領域的,如果所從事的非這個方向,往往學起來很費勁。但如果是同一方向,是手到擒來,輕松無比。
每個人對專家都有不同的定義,我眼中的專家則偏向于能夠看清楚當前領域方向,能引導未來設計的,這種才可以稱為專家,專注點是可以設計和行業未來的人,甚至是根據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 個月的時間,好好利用新的框架去開發實現若干個項目,而且這些項目還不能太簡單,必須要有一定的復雜度。
只有這樣,你的開發經歷才能更全面的覆蓋到這個框架的更多的方面,才能稱之為技術專家。
二、中高級程序員
這類人群已經在程序員領域有了一定的工作年限,也有了一定的開發經驗。他們已經掌握了一些框架和軟件等技術。那么他們面對新的框架和軟件,會根據自己以往的經驗和技術邏輯去領會新框架的原理。古語中對于一項技能有“道”與“術”的區別。那么這些中高級程序員對新框架的“道”的方面已經了然入心,因為這些新的框架其實與他們以前掌握的那些在邏輯架構和運行原理方面都是很相似的,他們需要學習的僅僅是原理上的不同,還有在編程語法、實現方式上的不同而已,那么這就是“術”的層面,而“術”是很容易掌握的,就好比是從模仿到掌握的過程。
我在做開發的頭三年的目標,是讓自己成為垂直業務方面的開發熟手。
4-5 年,我讓自己成為了專家,人家有問題了常常來問我,業務和架構上我也有自己的見底與把握。
6-8 年,梳理業務、做架構、帶團隊,總結和提煉技術能力與思想。
從開發生涯伊始,學習方法論、各種思想、最佳實踐(包括看源代碼),嘗試一些新東西,這個階段漫長而有彈性,不斷實踐與總結,行事方式固化為習慣,最大的收獲就是開始做某一項事情時,心里有底,有思路有方向有方法,不會抓瞎,少走彎路。
學習代碼的人和編寫代碼的人如果不在一個理解層面,閱讀并不能幫到你什么,更不能說通過了解了代碼的實現就成為了這個領域的專家。了解代碼實現頂多只能應付面試問題,當別人問題為什么的時候,答案并不在代碼實現當中。
閱讀代碼的精髓在于你完全了解了作者在領域中面臨的問題,并在紛繁復雜的代碼邏輯中抓出了作者解決這個問題的關鍵。自稱熟讀過的人,其實少有人能做到
這個收獲很難用量化來衡量,但就像蓄水池,越蓄越多的感覺。
所以題主你提的三個“明白”,不是說不重要,但太死板,天天坐在那里看源代碼看書是看不出什么來的,必須定好眼下要達標也可操作的 Flag,結合業務去追求跟實現,不斷實踐與總結。
天天看框架源碼,即使你寫出一個框架來,在業務實現方面你可能仍是 newbie;你就算花再多時間在編譯器知識上,但是業務跟編譯器毫無關聯,你的編譯器知識也不可能提升。
總之先考慮好第一步——定好眼下要達標也可操作的 Flag,結合業務去追求跟實現,不斷實踐與總結。想太多會提升焦慮感,虛無還沒好處,目標定得太完美就是失敗。
框架就是別人給你制定的條條框框,學會了就像工廠的流水線上的操作工一樣會干活了,不過換一個流水線你還得掌握另一些條條框框,專家、架構師就是給你制定條條框框的人。很多程序員以掌握某個架構然后自稱架構師然后指點江山,指責其他不會某個架構的人,心中充滿了偉大感,是不是很可笑;如同一個生產線上的操作工自稱掌握了這條生產線。
從來不覺得技術專家是研究哪個框架,那種設計語言就可以。①你需要多接觸大項目,你才有可能理解什么叫“”業務需求不是你的技術需求”。②獨立思維能力,能從復雜的業務場景中梳理出一定的邏輯順序,預見一些別人想不到的業務場景,之后提交不同領域去討論,這個過程中,你會體會什么叫“說人話”。③分水嶺。如果你執著技術,你會發現,想做專家,你需要重新學習你大本時候最討厭的一門課程,“高等數學”。如果你轉向業務實現,你會發現,想做專家,你可能要不斷深入現實中的業務場景,甚至掃垃圾這種最低級的工作,你都應該有切身的體驗才可以。
你說的專家不知是個什么概念,如果只是能夠做到熟練運用,那不是太難,一個能力尚可的程序員一般都能一通百通,學習和精通一門語言、框架從幾個月到二三年不等,但這絕對算不上專家,也就普通軟件工程師水平。
要達到計算機領域的專家絕非易事,而且也不是精通某一框架或軟件這么簡單,至少得要在某一領域取得一定的技術成果,我覺得一般擁有正高職稱的稱之為專家應該不心虛,副高職稱的免強也算。
絕大多數程序員有生之年都達不到專家水平,不是能力問題,而是為了生計不得已在技術層面停留太久,沒機會鉆研更深層次的東西。相反有些科研機構鉆研某一技術時間長了能夠成為這一領域的專家。
最后,真正的專家是沒功夫長篇大論在我們上寫問答的,寫問答的都是閑著沒事裝B的。
10
回答0
回答0
回答0
回答0
回答0
回答1
回答0
回答10
回答3
回答