程序員高手和程序員菜鳥的區別是什麼?

Z-jane


畢業兩年買房買車,BAT裡拼殺年薪百萬。這些大神級的傳說想必大家都有耳聞。

而渴望成為人生贏家的程序員們也懷揣著這樣夢想,紛紛踏入互聯網的大門。

假以時日,這些人的差距愈發明顯。最直觀的就是薪資水平上,有人拿著5K的基本工資萬年沒有長進,有人畢業一兩年就已月入5W,上升的勢頭還有增無減。

仔細分析後我們會發現,數字上的差異,從根本上體現的是在思維模式和行為習慣上的差別。例如——


  1. 代碼與註釋

普通的程序員寫的代碼邏輯性不強,細看起來有種“想到哪兒寫到哪兒”的既視感。後期調試的時候,你以為改完這個bug就OK了,結果——

另外,他們還懶得寫註釋,認為“自己寫的代碼自己還能看不懂麼?”,結果過兩天真的看不懂了······

而高級程序員的代碼命名及邏輯分離都恰到好處,寫的人清清楚楚,看的人也明明白白。代碼細節也儘量多的考慮邊界情況、性能,後期維護工作也不會太過繁瑣。


2.框架與擴展

你或許會說“程序員就是做開發的,架構師才去想框架”。有這樣的想法,其實你已經輸在起跑線上了。

架構師都是從程序員中來的。在項目,中把自己置於架構師的高度去思考這套系統應該怎麼設計,如何給未來預留足夠的擴展接口,而不是隻顧解決眼前問題,做代碼搬運工。


3. 組織與溝通

這是常被程序員們所“不屑”的能力——做架構、敲代碼厲害就足夠了,要其它“花哨”的能力有什麼用呢?

可大家要知道,最厲害的程序員,後來都成為了優秀的組織者和領導者國外有比爾·蓋茨,國內有雷軍、李彥宏。溝通與組織能力,是在技術之外讓你“開掛”的法寶。

普通程序員與開掛程序員

5k和5w的距離,就是“碼農”和“程序員”的距離。

前者做的多是體力活兒,後者做的多是腦力活兒。

是你嗎,碼農?

你或許會說“我每天也會讀很多文章呀”。朋友圈的文章、論壇的技術帖確實能讓你學會一些技巧,但這些不成體系的碎片知識往往過於淺表,無法塑造出一個統覽全局的內核。唯有沉下心來,閱讀經典,方能在時代的洪流中立於不倒之地。

最後說一句,別太在意“菜鳥”或“高手”的區別。縱使沒人在意的你,終會有一日,讓天地星辰嘆息!


AI研究所


如果你加入BAT之後就會發現,有的人升職速度很快,3年就升了2級;而有的人每天加班到11點,3年卻勉強才升了一級。

明明是同時畢業,同時入職的同事,按理說面試時表現差不多,怎麼3年後的差距就這麼大了呢?

所以說,就算加入了BAT,程序員之間也有優劣高下之分。

那麼,如何才能成為把別人甩在身後的高手程序員呢?

保持學習狀態

高手程序員總是善於用最新最前沿的科技來解決眼前的問題。這就意味著,在工作之餘,要保證自己在當前領域的輸入。只有瞭解行業的最新動態,才能在需要的時候隨手拈來合適的技術,應用與服務。

舉個例子,當你使用MySQL,一段時間後,由於持久化數據表格太大,查詢速度遇到瓶頸了,除了增加索引,分表之外,你還能想到什麼?經常瞭解行業動態的高手也許會想到使用Elastic Search,輕量級持久化應用,但是面對海量數據的時候,其查詢速度一點也不會受到影響。

一個只知道死磕Mysql,久久不見效果的A,以及引入了新技術使用ElasticSearch,效果立竿見影的B,作為旁觀者的你,覺得哪個程序員更能被稱為高手呢?

全局思維

做程序員最忌諱的是硬編碼,何為硬編碼。

想計算加法,1+1的值,

於是A寫了如下代碼:

public int Sum(){

return 1+1;

}

而B寫了是這樣的:

public int Sum(Integer a, Integer b){

if(a == null || b ==null){

return 0;

}

return a+b;

}

從結果上看,A和B的代碼都滿足了需求,A的代碼甚至更簡潔。但是實際真是如此嗎?

如果A是我的面試者,那麼我基本上就象徵性的再問幾個問題,就可以讓他離開了。

為什麼?

A的代碼雖然簡潔,但是完全沒有考慮其他情況,毫無異常處理,可擴展性,可移植性可言。

一個好的程序員會提前預想到未來的一些場景,並在當下的代碼中做好處理。

如果提的需求是1+1,那麼好的程序員會考慮到未來可能會計算M+N的,M或N可能是空值等等情況。


綜上,除了樓上各位提到的代碼規範,註釋規範等基本素質。保持學習狀態,從而有足夠的輸出,以及擁有全局思維,都是做一個優秀的程序員非常重要的特質。


我是蘇蘇思量,來自BAT的java開發工程師,頭像是本人,經常分享科技類見聞,歡迎關注我,與我討論問題。


蘇蘇思量


程序員高手和菜鳥,不僅僅是技術上的差距,還體現在習慣、經驗、看問題的角度等各個方面。

代碼規範

代碼寫的不好,其實一眼就能看出來;比如代碼裡面的各種命名(包、類、方法、變量等等)。

在最初寫程序的時候,很多人都會起沒有含義的變量命名,比如 String str;

其實我們完全可以把變量名稱起成帶業務含義的,比如String username;

慢慢地,我們發現可以寫的更好一些,比如String userName;

大家可以搜索一下《阿里巴巴Java開發手冊》,可以以此為標準。

經驗

軟件開發,經驗還是很重要的。

一是技術上的積累,高手技術的廣度和深度都會比較強一些;當遇到一個問題,高手會想到N種解決方案,然後再選擇出一條最適合的,而菜鳥可能就一條路走到底了。

二是業務知識的積累,對項目的理解程度會更深;接到一個需求,高手可以快速的想到到需要修改哪些地方,而菜鳥還需要重新處理一遍程序吧。


善用工具

很多時候,我們會依靠一些輔助的軟件去幫助我們完成一些“體力勞動”。

高手程序員對IDE更熟悉,熟悉每一個快捷鍵,進而開發效率會更高。

高手程序員有更完善的代碼庫,有時候開發一個功能,直接從代碼庫裡面Copy出來就好了。

高手程序員有更多順手的輔助軟件,比如對比兩個文件夾內所有文件的不同之處,我們只要用beyond compare一對比,就能得到答案。


心態

不和需求/產品經理吵架,是一個高手的必須課;

不和測試吵架,是一個高手的必修課...


高手不是一日養成的,菜鳥也不會一輩子都是菜鳥。

與各位共勉,共同進步。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解,希望能得到你的關注。


會點代碼的大叔


程序員菜鳥與程序員高手的區別主要體現在技術能力、溝通能力、解決問題能力等幾個方面,簡單羅列為如下八點:

1、解決問題能力

普通程序員:用複雜的代碼解決簡單的問題;

高級程序員:把複雜的問題簡單化並用簡潔的代碼去實現。

2、文檔寫作能力

普通程序員:文檔有嘛用,我習慣寫代碼;

高級程序員:不僅能寫好代碼,還能寫出淺顯易懂的文檔。

3、bug修復效率

普通程序員:利用搜索引擎(百度)尋找答案,經常找不到好的解決辦法,然後不斷更換技術方案;

高級程序員:利用搜索引擎(Google)尋找答案,一般bug都順利解決(與前期框架選擇的關係大)。

4、溝通表達能力

普通程序員:我只管寫代碼。

高級程序員:良好的溝通能力,能快速理解產品設計思路,更能展現個人所長。

5、優雅和美觀的抽象能力

普通程序員:好用,從實現的角度進行堆砌;

高級程序員:好用+好看。經常思考用戶操作這個功能時,還會做什麼事情。

6、對開源社區的關注度

普通程序員:極少混跡開源社區,導致對新技術發展關注度偏低。

高級程序員:擁抱開源社區,認識技術牛人,分享、學習新技術。

7、面對功能點

普通程序員:立馬開始構思自己如何實現腦海裡出來一個方案。

高級程序員:發現功能點很普通,git有非常多的解決方案,根據業務選擇一個最適合最優的方案。

8、各種編程規範

普通程序員:隨性,不考慮後續工作開展順暢與否;

高級程序員:有規律可循,要求嚴謹,運行流暢,後續有問題處理也更容易。

有不同見解,歡迎前往評論區補充~


優知學院


很多小白程序員,剛剛踏入社會還是個職場菜鳥,在這條路上走過很多彎路。這條路,或許迷茫過,也放棄過,但最後還是找到了一條屬於自己的路。

一、主要問題

1、沒有編程思想

或許很多人覺得很扯,但確實是這樣的。高級程序員在看到一個需求的時候,總是能夠快速在大腦裡生成這個需求在現實生活中的映射。每當產品經理提一個需求的時候,高級程序員首先想到的就是,這個需求需要哪些數據庫上的改動,對現有的邏輯有什麼影響,需要提供多少接口,存在哪些可能的風險,以及需要多久的開發週期。普通程序員拿到需求以後,首先表現的是一臉懵逼,因為往往產品經理的文檔寫的非常長,有時還難以理解,普通程序員難以提取裡面的關鍵點。所以這時就需要項目經理這種角色,提取需求,然後告訴他,提供什麼接口,對數據庫做什麼修改。

聰明的人在項目經理說完以後,總會自己去對著需求文檔去思考項目經理為什麼要這麼做,還有一部分人悶著頭就去開發了。很多工作四五年的程序員,工作經驗一大堆,讓他真的說出些什麼,他卻說不出來。不懂得在工作中思考,工作十年也只是一個普通程序員。

2、沒有學習路線

普通程序員在學完基本的知識以後,後續就不知道該學什麼了,沒有一條屬於自己的進階路線。高級程序員不同,他們在學完基本工作知識以後,會思考下一步自己該如何提升,他們會擁有自己的選擇。知識是永無止境的,學完基礎以後,還有自動化部署,還有微服務,大數據,以及各種架構。制定一條屬於自己的學習路線,是非常有必要的。

3、不會用Git

高級程序員的代碼都是通過Git一類的版本控制工具維護的很好,針對不同的功能他們會建立不同的分支,以及測試分支,灰度環境分支,正式環境分支,有的還會建出發佈分支。普通程序員總是喜歡在主分支上面做修改,一旦同時有多人並行開發,或者需要回退分支到某一個功能點的時候,對於他們來說往往都是災難性的存在。普通程序員提交Git還總喜歡用 123 這種提交日誌,高級程序員總會在提交日誌中詳細寫出自己做了哪些修改,方便以後遇到問題的時候查找原因。

4、命名不規範

這是一個很大的問題,普通程序員很喜歡使用拼音或者是拼音加英文的方式來命名。高級程序員哪怕自己英語很差,也懂得使用百度翻譯或者谷歌翻譯來把對應的中文翻譯成英文。這樣做最大的好處就是,別人看到你這個類,或者看到你這個方法和變量的時候,第一時間能夠知道這個東西是幹嘛的。

5、結構不規範

無論是什麼編程語言,無論是面向對象還是面向過程,甚至不分前端和後端。任何一個語言在開發的時候,代碼結構都應該清晰。相同功能,相同模塊的文件應該放在一起,針對不同的處理邏輯建出不同的文件夾或包。重複使用超過三次以上的代碼應該考慮把它寫進一個公共的方法裡,大家都調用這個公共的方法,避免維護太多的重複代碼。這樣當項目發展的很大以後,開發起來也不至於很亂。

6、不知道如何解決BUG

普通程序員看到程序報錯以後,第一時間是懵逼狀態,他們會很慌亂,不知道該如何是好。有的還知道看一下控制檯打印的錯誤信息,來百度一下,但往往這種方式能不能解決問題都看運氣。高級程序員如果做的是一個web程序,報錯以後他們會首先看瀏覽器的控制檯是否發送了對應的請求,如果發送了請求會看瀏覽器的錯誤碼是什麼,是請求超時還是發生了500或者是404的錯誤。然後再針對不同的錯誤碼做出不同的調試方案,如果500的錯誤,報錯日誌明顯就直接找到對應的地點修改,如果報錯信息不明顯就通過開發工具來進行斷點調試,一步一步找到問題。

7、不會用搜索引擎

遇到問題去百度一下是很明智的,但是如果不看報錯的信息盲目的去百度,搜索的結果也只是浪費自己的時間。如果盲目去嘗試搜索到的解決方案,只會讓瞎子變成瘸子。針對這個,大家可以報錯以後看報錯日誌的最後一行,往往報錯最後一行就是錯誤的原因。一般都是英文的,但是並不複雜,往往都是幾個單詞來說明問題,然後指向一個錯誤產生的代碼位置。先看報錯原因,自己思考以後大概明白是什麼原因,不要上來就去拿著最後一行百度。

如果擁有科學上網的能力,可以使用谷歌來進行搜索,效率更高,答案更準確。

還可以有更多選擇:

以上是普通程序員在工作中最容易產生的問題。

二、提升建議

1、培養編程思想

編程思想這個東西,不是說工作的久了就能有的,而是在學習和工作中要去思考。思想思想,肯定要先思而後想,這樣才能擁有思想。建議是大家可以針對項目中一些簡單的功能去思考,如果讓你來從頭開發這個功能,你需要對數據庫進行哪些操作,需要提供什麼接口,需要什麼類型的數據,數據需要進行哪些必要的驗證,數據庫的字段類型以及長度。用筆在紙上把內容都列舉出來,寫完以後再看幾遍,有沒有哪些可以做的更好的地方。然後去看項目裡原來的設計,是不是跟你的類似,如果不如你設計的可以在後面的優化中改進它,如果比你的好,那就去思考別人為什麼要這麼做。久而久之,遇到複雜的需求也能快速拆分成一個個的小需求,那個時候你離項目經理就不遠了。

2、制定學習路線

因為大家的方向不同,有的人是前端,有的人是後端,學習的語言也不同。在這裡就針對前端和服務端提一些建議。

前端

前端最重要的其實還是基礎的js,只有把js學好了,才能輕易的理解高級框架的原理。如果現在能夠完成公司的開發任務,建議可以好好學習一下js的基礎課程,弄懂它。然後去看看jquery是如何實現的,jquery只有一個文件,而且代碼並不複雜,當弄懂jquery是如何實現的以後,再看vue這些複雜的框架,也不覺得難以理解了。一個前端程序員初期工資有多高,是看他掌握多少框架。但未來能夠走多遠,是看他內功修煉的是否紮實。

後端

一般無論是大公司還是小公司,服務端的主要工作就是使用一個或多個框架來開發一些接口。所以很多技術大佬總喜歡自嘲自己是一個 CRUD工程師 (增刪改查工程師)。那麼如何讓增刪改查變得更優秀呢,同樣都是增刪改查為什麼有人8K有人30K。建議是在熟練掌握自己所使用的框架以後,不妨去學習一些項目性能優化方面的知識。比如緩存,比如數據庫性能優化。有人可能會說,緩存有什麼好學的,不就是redis插入一個key,查詢一個key嗎?redis一樣存在很多高級的用法,也同樣存在許多的坑,如果應用不好,輕則數據丟失,重則整個服務器癱瘓。掌握基本的性能優化以後,就可以去研究如何把項目通過容器技術來分離成一個個的小項目。這時就需要學習docker這種技術,隨著docker數量的增多,docker的啟動停止,狀態監測就成了一個比較繁瑣的事情。又需要學習docker的自動化技術。學完這些以後就初步掌握了微服務開發的一些思想,實際上微服務就是在這樣的一個過程中不斷演進而來的。當擁有了自己的知識廣度以後,再去深研框架和語言的底層。

有些東西,並非是運維或者是DBA才能做的,而是每個程序員都必須要掌握的,如果什麼事情都依靠運維和DBA,那麼十年以後依然還是CRUD工程師。任何技術,特別是編程相關的,他們最終的本源都是一樣的,都是代碼。所以無論學習數據庫,學習緩存,學習容器,為的都是增加大家的知識廣度。只有閱盡千帆的人,才能像大海一樣睿智。

願大家都能在編程這條路,越走越遠。


程序員學習交流請添加慕課網官方客服微信:mukewang666回覆暗號“前端面試”可進前端交流群回覆暗號“Java”可進Java交流群回覆暗號“專欄”可進程序員交流群

慕課網


作為一個還在匍匐前進的程序猿。當看到這個問題的時候還是忍不住去深思,曾經的自己也是一個菜鳥,看到大神也會仰慕。虛心的去請教了一下大神如何成為他那樣的人。本來以為會有什麼高談闊論,但是大神的回答讓我很吃驚。我也明白菜鳥和大神到底差了哪裡。他只是掌握了我們平常所忽略的一些細節,只要我們也掌握了這些你也會成為大神

1、養成寫文檔的良好習慣

良好的文檔是正規研發流程中非常重要的環節,作為代碼程序員,30%的工作時間寫技術文檔是很正常的,而作為高級程序員和系統分析員,這個比例還要高很多。缺乏文檔,一個軟件系統就缺乏生命力,在未來的查錯,升級以及模塊的複用時就都會遇到極大的麻煩。


2、養成編寫規範化的代碼習慣

像阿里巴巴這樣的大公司,代碼內註釋格式,嵌套中行縮進的長度和函數間的空行數字都是有明確規定,良好的編寫習慣,不但有助於代碼的移植和糾錯,也有助於不同技術人員之間的協作



3、徹底理解需求

很多程序員拿到需求的時候不是進行系統分析,而是直接粗略過目,然後就用代碼來實現功能,這樣做不僅浪費時間,還可能因為你自己的原因讓整個項目延期

4、要寫可以複用和模塊化的代碼

經常可以聽到一些程序員有這樣的抱怨,寫了幾年程序,變成了熟練工,每天都是重複寫一些沒有任何新意的代碼,這其實是中國軟件人才最大浪費的地方,一些重複性工作變成了熟練程序員的主要工作,而這些,其實是完全可以避免的。複用性設計,模塊化思維就是要程序員在完成任何一個功能模塊或函數的時候,要多想一些,不要侷限在完成當前任務的簡單思路上,想想看該模塊是否可以脫離這個系統存在,是否可以通過簡單的修改參數的方式在其他系統和應用環境下直接引用,這樣就能極大避免重複性的開發工作,如果一個軟件研發單位和工作組能夠在每一次研發過程中都考慮到這些問題,那麼程序員就不會在重複性的工作中耽誤太多時間,就會有更多時間和精力投入到創新的代碼工作中去。

5、保證程序的正確性

軟件研發作為一項工程而言,一個很重要的特點就是問題發現的越早,解決的代價就越低,我們在每段代碼,每個子模塊完成後進行認真的測試,就可以儘量將一些潛在的問題最早的發現和解決,這樣對整體系統建設的效率和可靠性就有了最大的保證。

6、有自我學習和總結的能力

新技術更新迭代很快,只有不斷學習才不會被淘汰。善於學習,對於任何職業而言,都是前進所必需的動力,對於程序員,這種要求就更加高了。學習內容在精而不在多,掌握一門技術,其它自然而通,熟話說一招吃遍天下,就是這個道理。

善於總結,也是學習能力的一種體現,每次完 成一個研發任務,完成一段代碼,都應當有目的的跟蹤該程序的應用狀況和用戶反饋,隨時總結,找到自己的不足,這樣逐步提高,一個程序員才可能成長起來。



如果一個程序員連以上幾點都做不到的話,那真的就不用耽誤時間在這方面了,該幹嘛就幹嘛去。這不是教科書而且對自身的認識。希望廣大猿發表自己的見解


愛捉貓的老鼠520


作為一名程序員,我來談談我的看法。

很多人可能以為只要能把這個功能實現了就算是高手,實現的功能和需求越多就證明你越厲害,其實這個是錯誤的想法。現在的需求基本上都是一些常規普通的需求,一般依靠著搜索引擎都能夠寫出來。那麼高手和菜鳥的區別到底在哪裡呢?我可以從以下幾個方面來談談。


代碼的規範

高手和菜鳥的第一個區別就是在於代碼編寫的規範。高手寫代碼可以說是行雲流水,有一種寫詩一般的感覺。同樣的一個功能,高手可以用最優最少複雜度來實現,而菜鳥一般是拖泥帶水,運行起來對電腦或者手機的性能消耗十分大。這樣也就導致了菜鳥寫的代碼運行起來非常的慢或者卡頓,有時候還會內存洩露,而高手寫的代碼運行起來可以說是十分的流暢。

Bug數量

高手和菜鳥的第二個區別在於代碼的bug數量。我們知道bug是不可能避免的,但是高手寫的代碼可以說有足夠的容錯空間,遇到錯誤要麼會給出提示,要麼會做一些別的處理。舉個簡單的例子,假設一段代碼運行在手機上,遇到了一個未知的錯誤,菜鳥寫的代碼完全就沒有對未知情況做任何處理,程序直接奔潰,但是高手可以說對一些突發狀況做了預備處理,導致出現了這些未知情況的時候程序仍然能夠有一些應急代碼可以運行,程序不至於出現奔潰的問題。


代碼的擴展性和封裝性強

高手寫的代碼對於同樣的功能一般都會做好很好的封裝處理,這樣在很多地方使用同樣功能代碼的時候不用再重複去寫一樣的代碼了,而修改這個功能也只需要修改一處即可,省時省力效果還好。而菜鳥的話同樣的代碼反覆寫,導致很多項目代碼臃腫,重複的地方到處都是,後期修改起來十分不方便。而高手寫的代碼對於後期進行迭代更新有很好的延展性,代碼的耦合度很低,可以隨時在上面加東西,並且不影響前面的功能。而菜鳥在這方面就顯的很弱,往往修改了一個地方的錯誤,另外一個地方又出現問題,耦合度太高,關聯性太強了,導致往往是牽一髮而動全身,後期代碼十分臃腫根本難以維護擴展。


學習的態度

真正牛逼的人物永遠不會趾高氣昂,他們的架子往往會放的很低,樂於分享自己的技術,經常將自己的項目或者一些好用的功能開源分享給別人去用,而且永遠保持著一顆謙虛學習的心去學習。而菜鳥往往是會寫一點功能就趾高氣昂,一副吊炸天的樣子,結果太難的功能又不會,簡單的又看不上,最後只能靠裝逼混日子。


如果覺得我的回答能夠幫助到你,請隨手點贊,有什麼想說的想問的也隨時在下面留言或者私信,我看到會及時回覆。


大斌聊科技


作為一個菜鳥來回答一下這個問題。

上學的時候就有很大的區別:高手就是學霸,渣渣就是逃課,上課玩別的,作業抄襲或者不做,反正就是不學習不努力就變成了一隻菜鳥。

學霸期末的時候都可以編出遊戲給女朋友玩了,學渣還在焦慮開學第一課第一個短程序怎麼理解,最後還是算了,背下來就好了,考試的時候,也不管問題是什麼,把模板寫上去,老師雖然知道牛頭不對馬嘴,但是也不是一無所知,給一點可憐分。

步入職場之後,就可以稱之為程序員了。

菜鳥是沒法生存下去的。

當老闆無比信任的將我分配到開發部的時候,我連我的任務都搞不明白,一會是二線啥子,一會是前端啥子,一會讓我做個登錄註冊的界面,我照著網站教程勉強做出來後,老闆很吃驚,覺得真是沒有白信任我的時候,讓我講一遍,我真的是不懂啊,每天都很煎熬,比上學的時候難多了,或許上學的時候好好實踐了,可能現在的理解力也會好很多。

最後公司竟然要跟我籤合同,我思來想去,要拿那麼高的工資,就要創造那麼更大的收益,實在是亞歷山大。我退縮了,我以菜鳥的身份告別了這一行業,以及大學四年的快樂時光,而沒有勵志的成為一個程序員高手,而我也並不後悔,當時我就很焦慮,那些脫髮的老師,那些脫髮的同事,我並不在意髮型,但很不習慣思考。

那些學霸同學,有的讀研了,而這時候也快畢業了。

有的進了我們都很熟悉的大企業,想必年薪也是會讓人羨慕,但是一定是勞有所得。

還有的結婚生子……

無論是菜鳥還是高手,都要幸福哦~


旺仔和AD


作為一枚工作3年的菜鳥,談談我的感悟吧。

我列了八點區別:

bug數量

高手的程序,bug很少。自帶測試屬性,別人需要用刁鑽的角度才能發現問題。

菜鳥的程序,bug滿天飛。並且還可能有不少block流程或者丟失數據的嚴重bug

開發時間

高手能夠準確評估自己的時間,並能按時保質完成任務。

菜鳥總是高估自己,要麼嚴重delay,要麼為了趕工,bug一堆。

代碼可讀性

高手的代碼讀起來賞心悅目,不需要多少註釋就能讀懂含義。層次分明,邏輯清晰。

菜鳥的代碼超過一個月自己都看不懂。

代碼健壯性

高手的代碼像一個堅固的堡壘,任何的惡意攻擊和異常情況都無法破壞系統。

菜鳥的代碼如同紙糊,到處是未捕獲的異常。

代碼擴展性

高手能預知產品經理的需求,並不會懼怕需求變更。

菜鳥一聽到需求變更就要找產品經理幹架。

解決問題的能力

高手遇到問題不慌張,冷靜分析,排查疑點,快速解決問題。

菜鳥只會重啟,要麼就是跑到百度知道找答案。

學習態度

高手對技術充滿熱情,保持不斷的學習。

編程多年依然菜鳥的那群人,通常都把業餘時間給了遊戲和追劇。

項目管理

高手能管理好自己的時間,任務拆解到位。謀定而後動,一動就一氣呵成。

菜鳥通常一頓操作猛如虎,然後就是各種重構重寫。

程序員不容易,大家勉乎哉!

大家平時工作中還遇到怎樣的高手和菜鳥呢?


戰神猴哥


列出我認為重要的兩點:

  • 正確的架構選型和折衷的能力

選對好的設計方案和折衷,使團隊少走很多彎路,和不必要的加班,促使項目落地實施。

  • 解決問題的思路和指導問題的能力,對系統有預判性

遇到bug能有清晰的指導或者解決能力。對系統有前瞻性和預判性,能夠枚舉所有儘可能多的可能性和解決方案


分享到:


相關文章: