-
1 # 趣事情
-
2 # 嗝屁鏟屎官
一、模型抽象能力
模型決定一個系統的可用性、穩定性、易用性、可維護性、可擴充套件性!
這個模型不是UML建模,而是軟體的核心。就是你設計一個軟體時,為其所抽象出來的原理性的描述。模型決定一個軟體的質量、易用性和擴充套件性。凡是優秀的軟體,都有一個共同特點,就是其模型構建的非常漂亮,當然也有不怎麼優秀的軟體,模型也很漂亮。微軟MEF,我個人覺得其模型構建非常的漂亮和優雅,有興趣同學可以看看《體驗Managed Extensibility Framework精妙的設計》這篇文章。MEF的核心就是組合基元,如下圖所示,它簡單的定義了動態組合的支援基礎,然後一層一層的進行擴充套件。
當然了,因為文章是我寫的,我也得得瑟的顯擺一下OSGi.NET的設計。可以說,OSGi.NET的設計。OSGi.NET的設計也是類似於MEF,核心很簡單,只是為了實現三大功能:動態外掛化、面向服務、擴充套件。不過,我們卻可以從簡單的OSGi.NET來支撐WinForm、ASP.NET、ASP.NET MVC等任意應用,從簡單控制檯擴充套件到iOpenWorks這樣的自動化部署與軟體生產線平臺。它的擴充套件方式是:
WinForm等桌面外掛應用 = OSGi.NET + 應用外掛
ASP.NET應用 = OSGi.NET + WebExtension + Web外掛
MVC應用 = OSGi.NET + WebExtension + MvcWebExtension + Web外掛
自動部署 = OSGi.NET應用 + iOpenWorksBundleRepository + iOpenWorksBootstrap + 自動升級外掛
遠端服務 = OSGi.NET應用 + 遠端服務宿主外掛
負載均衡 = OSGi.NET應用 + 遠端服務宿主外掛 + 負載均衡客戶端外掛
在OSGi.NET之上的任何應用,都是基於組合和擴充套件的方式,並沒有去不斷變更OSGi.NET核心本身的程式碼。此外,OSGi.NET核心能夠支援.NET Framework、Mono、.NET Compact Framework,因為它設計的模型非常小,沒有用過多的類庫支援。
二、謙虛隨和
我們的客戶都是一些大的企業,接觸了很多各種型別的技術人員。你可以發現一個非常有趣的現象,那些懂得尊重別人、比較謙虛的人經過深入接觸後,會發現他們的技術往往都很了不起;而那些說話刻薄無禮,覺得這個技術也不怎樣,那個技術沒什麼了不起的,這個技術沒有什麼用,我自己的東西已經挺好的,這樣的人水平、經驗和見識一般都不怎樣。軟體的問題,並不是簡簡單單解決一個技術問題,從技術的角度上看,只要學會了使用技術,那麼我們就已經掌握了技術,因此,單純的技術是很簡單的。相反的是,軟體的協作開發、管理,軟體的易用性,軟體是否美觀,這些東西才是最麻煩的,也往往是技術水平一般、經驗短缺的程式設計師意識不到的東西。我曾經接觸過不少一般的程式設計師,大體都是這一類,他們覺得軟體太簡單了,沒有什麼了不起的。對於什麼思想,也不屑一顧,他們已經覺得自己掌握了很多真正的技術。
三、異常處理與穩定健壯
透過異常處理可以看出一個程式設計師程式設計的嚴謹與紮實的基礎知識。對於Java開發人員而言,會發現每一個方法都有可能需要強制的處理異常和宣告這個函式需要處理的異常,這中強制的約束,會強迫開發人員來習慣性的考慮和思考它。不過,對於大部分人來說,它處理異常的方式就是簡單的使用try { … } catch(Exception anyException) { // 忽略異常 },用這種方式來捕捉所有的異常資訊。這樣做的好處就是快,傻,缺點就是一旦出現問題,就不知道問題在哪發生,怎麼回事,如果有靠譜的QA還好一些,比如外企,他們都有規範的測試方法和測試流程,一旦發現問題,就會將重現捕捉完整的描述出來給開發者看。不過,在國內沒有嚴格的測試是很正常的,那麼出現問題時,就傻了。客戶是絕對不可能把出現問題的方式給你完整的Repro的,一旦出現問題,客戶會幹的就是急眼,那接下來怎麼辦?你就老老實實加班,老老實實的去猜去找問題。當“try { … } catch(Exception anyException) { // 忽略異常 }”這樣的程式碼充斥整個軟體系統時,你就可以想象有多可怕,這個軟體能穩定就怪了!
-
3 # 三碗不八卦
高手的程式碼或者架構用兩句話總結就是:簡單易懂效率高,穩定可靠Bug少。
簡單:意味著清晰,明白想要什麼不想要什麼。
易懂:意味著可維護性高,出現問題的時候,不管自己還是同事都可以方便的找到答案。
效率高: 意味著邏輯清晰,不繞彎子。
穩定: 意味著考慮到了長時間多併發的需求,不會因為這些而出現錯誤。
可靠: 意味著考慮到了生產環境的複雜情況,對特殊事件有足夠的處理機制。
Bug少:不用說了吧。
-
4 # 智慧元素反應
菜鳥寫程式碼:
1、首先想的是別人會怎麼實現?有沒有可以直接拿來抄的,改的越少越好。為了完成一個專案而完成。
2、完了也不總結,可以轉動就行,不會考慮效能最佳化,高併發和注入漏洞等等問題。
3、沒有介面文件,後期專案交接,下一個環節全靠自己摸索。
高手寫程式碼:
1、這個專案我之前有些過一個框架,可以直接拿來用。
2、用之前再次最佳化自己的框架
3、最佳化框架的時候發現開發這門語言的人有一個漏洞
4、寫一篇文章發到開源社群,提供底層最佳化的解決方案。
綜上所述,菜鳥和高手之前寫程式碼的最重要區別是:
一個不帶腦子寫程式碼,有一個用自己的靈魂來創作。
久而久之,高手有自己的獨到見解和解決方案,菜鳥還是拿來主義者。
所以:
高手和菜鳥之前的差別,不在於工作年限,而在對程式碼的態度和專研
-
5 # 天天淨瞎搞
1,最主要的差距就是處理問題的方法。新手很容易鑽到死衚衕,而且越走越遠。老手會在發現行不通的情況下另闢蹊徑,這也需要老手有足夠豐富的經驗做支撐。2,新手為完成需求去寫程式碼。老手更多的會為以後得擴充套件 重用 效能上去考慮。3,老手舉一反三的能力需要新手骨積累更多的經驗去掌握。
-
6 # 遇上小人物
程式設計師高手比較穩重,開發質量及工作態度較高,半吊子程式設計師自以為是,開發質量暫且不說,工作態度也比較浮躁,這是我與程式設計師打交道這麼多年來的總結,有些片面,但應該還算中肯。
-
7 # 愛捉貓的老鼠520
作為一個還在匍匐前進的程式猿。當看到這個問題的時候還是忍不住去深思,曾經的自己也是一個菜鳥,看到大神也會仰慕。虛心的去請教了一下大神如何成為他那樣的人。本來以為會有什麼高談闊論,但是大神的回答讓我很吃驚。我也明白菜鳥和大神到底差了哪裡。他只是掌握了我們平常所忽略的一些細節,只要我們也掌握了這些你也會成為大神
1、養成寫文件的良好習慣
良好的文件是正規研發流程中非常重要的環節,作為程式碼程式設計師,30%的工作時間寫技術文件是很正常的,而作為高階程式設計師和系統分析員,這個比例還要高很多。缺乏文件,一個軟體系統就缺乏生命力,在未來的查錯,升級以及模組的複用時就都會遇到極大的麻煩。
2、養成編寫規範化的程式碼習慣
像阿里巴巴這樣的大公司,程式碼內註釋格式,巢狀中行縮排的長度和函式間的空行數字都是有明確規定,良好的編寫習慣,不但有助於程式碼的移植和糾錯,也有助於不同技術人員之間的協作
3、徹底理解需求
很多程式設計師拿到需求的時候不是進行系統分析,而是直接粗略過目,然後就用程式碼來實現功能,這樣做不僅浪費時間,還可能因為你自己的原因讓整個專案延期
4、要寫可以複用和模組化的程式碼
經常可以聽到一些程式設計師有這樣的抱怨,寫了幾年程式,變成了熟練工,每天都是重複寫一些沒有任何新意的程式碼,這其實是中國軟體人才最大浪費的地方,一些重複性工作變成了熟練程式設計師的主要工作,而這些,其實是完全可以避免的。複用性設計,模組化思維就是要程式設計師在完成任何一個功能模組或函式的時候,要多想一些,不要侷限在完成當前任務的簡單思路上,想想看該模組是否可以脫離這個系統存在,是否可以透過簡單的修改引數的方式在其他系統和應用環境下直接引用,這樣就能極大避免重複性的開發工作,如果一個軟體研發單位和工作組能夠在每一次研發過程中都考慮到這些問題,那麼程式設計師就不會在重複性的工作中耽誤太多時間,就會有更多時間和精力投入到創新的程式碼工作中去。
5、保證程式的正確性
軟體研發作為一項工程而言,一個很重要的特點就是問題發現的越早,解決的代價就越低,我們在每段程式碼,每個子模組完成後進行認真的測試,就可以儘量將一些潛在的問題最早的發現和解決,這樣對整體系統建設的效率和可靠性就有了最大的保證。
6、有自我學習和總結的能力
新技術更新迭代很快,只有不斷學習才不會被淘汰。善於學習,對於任何職業而言,都是前進所必需的動力,對於程式設計師,這種要求就更加高了。學習內容在精而不在多,掌握一門技術,其它自然而通,熟話說一招吃遍天下,就是這個道理。
善於總結,也是學習能力的一種體現,每次完 成一個研發任務,完成一段程式碼,都應當有目的的跟蹤該程式的應用狀況和使用者反饋,隨時總結,找到自己的不足,這樣逐步提高,一個程式設計師才可能成長起來。
如果一個程式設計師連以上幾點都做不到的話,那真的就不用耽誤時間在這方面了,該幹嘛就幹嘛去。這不是教科書而且對自身的認識。希望廣大猿發表自己的見解
-
8 # 深入淺出話圍棋
作為一枚工作3年的菜鳥,談談我的感悟吧。
我列了八點區別:
bug數量高手的程式,bug很少。自帶測試屬性,別人需要用刁鑽的角度才能發現問題。
菜鳥的程式,bug滿天飛。並且還可能有不少block流程或者丟失資料的嚴重bug
開發時間高手能夠準確評估自己的時間,並能按時保質完成任務。
菜鳥總是高估自己,要麼嚴重delay,要麼為了趕工,bug一堆。
程式碼可讀性高手的程式碼讀起來賞心悅目,不需要多少註釋就能讀懂含義。層次分明,邏輯清晰。
菜鳥的程式碼超過一個月自己都看不懂。
程式碼健壯性高手的程式碼像一個堅固的堡壘,任何的惡意攻擊和異常情況都無法破壞系統。
菜鳥的程式碼如同紙糊,到處是未捕獲的異常。
程式碼擴充套件性高手能預知產品經理的需求,並不會懼怕需求變更。
菜鳥一聽到需求變更就要找產品經理幹架。
解決問題的能力高手遇到問題不慌張,冷靜分析,排查疑點,快速解決問題。
菜鳥只會重啟,要麼就是跑到百度知道找答案。
學習態度高手對技術充滿熱情,保持不斷的學習。
程式設計多年依然菜鳥的那群人,通常都把業餘時間給了遊戲和追劇。
專案管理高手能管理好自己的時間,任務拆解到位。謀定而後動,一動就一氣呵成。
菜鳥通常一頓操作猛如虎,然後就是各種重構重寫。
程式設計師不容易,大家勉乎哉!
大家平時工作中還遇到怎樣的高手和菜鳥呢?
-
9 # 簡單粗暴程式設計
簡而言之,入門級程式設計師只能實現功能,初級程式設計師能夠考慮到效能,中級程式設計師能夠考慮到安全性,高階程式設計師兼顧效能、安全和程式碼重用,頂級程式設計師就是把以上做到最好。
-
10 # 會點程式碼的大叔
程式設計師高手和菜鳥,不僅僅是技術上的差距,還體現在習慣、經驗、看問題的角度等各個方面。
程式碼規範
程式碼寫的不好,其實一眼就能看出來;比如程式碼裡面的各種命名(包、類、方法、變數等等)。
在最初寫程式的時候,很多人都會起沒有含義的變數命名,比如 String str;
其實我們完全可以把變數名稱起成帶業務含義的,比如String username;
慢慢地,我們發現可以寫的更好一些,比如String userName;
大家可以搜尋一下《阿里巴巴Java開發手冊》,可以以此為標準。
經驗
軟體開發,經驗還是很重要的。
一是技術上的積累,高手技術的廣度和深度都會比較強一些;當遇到一個問題,高手會想到N種解決方案,然後再選擇出一條最適合的,而菜鳥可能就一條路走到底了。
二是業務知識的積累,對專案的理解程度會更深;接到一個需求,高手可以快速的想到到需要修改哪些地方,而菜鳥還需要重新處理一遍程式吧。
善用工具
很多時候,我們會依靠一些輔助的軟體去幫助我們完成一些“體力勞動”。
高手程式設計師對IDE更熟悉,熟悉每一個快捷鍵,進而開發效率會更高。
高手程式設計師有更完善的程式碼庫,有時候開發一個功能,直接從程式碼庫裡面Copy出來就好了。
高手程式設計師有更多順手的輔助軟體,比如對比兩個資料夾內所有檔案的不同之處,我們只要用beyond compare一對比,就能得到答案。
心態
不和需求/產品經理吵架,是一個高手的必須課;
不和測試吵架,是一個高手的必修課...
高手不是一日養成的,菜鳥也不會一輩子都是菜鳥。
與各位共勉,共同進步。
-
11 # 慕課網
很多小白程式設計師,剛剛踏入社會還是個職場菜鳥,在這條路上走過很多彎路。這條路,或許迷茫過,也放棄過,但最後還是找到了一條屬於自己的路。
一、主要問題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工程師。任何技術,特別是程式設計相關的,他們最終的本源都是一樣的,都是程式碼。所以無論學習資料庫,學習快取,學習容器,為的都是增加大家的知識廣度。只有閱盡千帆的人,才能像大海一樣睿智。
願大家都能在程式設計這條路,越走越遠。
-
12 # 旺仔和AD
作為一個菜鳥來回答一下這個問題。
上學的時候就有很大的區別:高手就是學霸,渣渣就是逃課,上課玩別的,作業抄襲或者不做,反正就是不學習不努力就變成了一隻菜鳥。
學霸期末的時候都可以編出遊戲給女朋友玩了,學渣還在焦慮開學第一課第一個短程式怎麼理解,最後還是算了,背下來就好了,考試的時候,也不管問題是什麼,把模板寫上去,老師雖然知道牛頭不對馬嘴,但是也不是一無所知,給一點可憐分。
步入職場之後,就可以稱之為程式設計師了。
菜鳥是沒法生存下去的。
當老闆無比信任的將我分配到開發部的時候,我連我的任務都搞不明白,一會是二線啥子,一會是前端啥子,一會讓我做個登入註冊的介面,我照著網站教程勉強做出來後,老闆很吃驚,覺得真是沒有白信任我的時候,讓我講一遍,我真的是不懂啊,每天都很煎熬,比上學的時候難多了,或許上學的時候好好實踐了,可能現在的理解力也會好很多。
最後公司竟然要跟我籤合同,我思來想去,要拿那麼高的工資,就要創造那麼更大的收益,實在是亞歷山大。我退縮了,我以菜鳥的身份告別了這一行業,以及大學四年的快樂時光,而沒有勵志的成為一個程式設計師高手,而我也並不後悔,當時我就很焦慮,那些脫髮的老師,那些脫髮的同事,我並不在意髮型,但很不習慣思考。
那些學霸同學,有的讀研了,而這時候也快畢業了。
有的進了我們都很熟悉的大企業,想必年薪也是會讓人羨慕,但是一定是勞有所得。
還有的結婚生子……
無論是菜鳥還是高手,都要幸福哦~
-
13 # Java技術架構
肉眼分辨:
哈哈,抖個機靈
從工作的方面來說,普通程式設計師和高階程式設計師一般有下面幾個區別:
普通程式設計師
1、知識體系零散,沒有系統性的思維,在寫程式碼、改bug的時候沒有工程素養,往往是拆了東牆補西牆。
其實在面對一個未知的問題時,如何定位複雜條件下的核心問題、如何抽絲剝繭地分析問題的潛在原因、如何排除干擾還原一個最小的可驗證場景、如何抓住關鍵資料驗證自己的猜測與實驗,都是體現程式設計師思考力的最好場景。
2、對某種語言的依賴性太強,知識無法很好的遷移,一旦換了語言,或者領域不同就會不知所措。
程式設計師是一個非常殘忍的職業。你所學所用的語言、框架、模式,很可能在數年內就成昨日黃花了;你現在嘲笑的另一群程式設計師,可能馬上就能轉身來嘲笑你了。
3、經驗不足卻自認為自己經驗豐富,只對自己做過的比較順手,但是碰到未知的問題,就束手無策。
4、毫無必要的拖延,這是很多程式設計師的通病。
5、心猿意馬。
見過太多心猿意馬的程式設計師,不得不把“專注眼下”專門提出來。
他們往往有各式各樣的小夢想,比如做個小茶農、做個小鵝販、做產品、做銷售、做投資,卻被程式設計師的高薪或是沒有轉行的魄力“耽誤”了,而因為不專注,他們不在意做好自己的本分,不在意錘鍊自己的技能,不在意學習新興的技術。
高階程式設計師
1、知識體系完整,有系統性的思維,即使沒有到架構師的級別,在寫程式碼和改bug的時候也能從整體上去思考和把握。
2、學習能力強有了自己的心智模型,知識可以自由遷移,並可以高效地切入不同的領域和語言。
3、擁有真正的經驗,不只是做夠那些專案,而是面向未知的解決問題的能力。
而高階程式設計師更擅長抓住問題的本質,將看似複雜的需求化繁為簡為一系列簡單邏輯的堆疊,寫程式碼步步為營,邏輯簡單清晰,所有條件分支都被仔細覆蓋,磨刀不誤砍柴工。
如何從普通程式設計師進階到高階程式設計師?
1、提高程式碼最佳化的能力
打鐵還需自身硬,“程式碼可執行”對一個優秀的程式設計師來說絕不是結束,而是開始。優秀的程式設計師一定熟知各種演算法和資料結構,會靈活運用,致力於寫出更簡單、效率更高的程式。
2、先考慮、多思考
程式設計思路,是系統的計劃和設想,是程式設計師寫程式時的條理和線索,可以思考但不要長時間延時性的思考。
3、突破程式設計師思維只有突破程式設計師思維,才不會淪為碼農!
4、時間管理,很多人都沒有時間管理意識,覺得時間最不值錢。
這就像是你到了一個十字路口,也不管自己想去哪裡,抬腳就努力地奔跑,一路上被自己的努力所感動,但你跑的方向是北邊,而你內心真實想去的方向是南邊,方向跑偏了,始終到不了目的地,能不迷茫嗎?
5、拓展知識的深度和廣度
大家可以多看看 BAT 的招聘要求,看看自己還有哪些方面根本沒接觸過。建議大家多關注熱點和優秀的開源專案、找到自己的興趣點就多花點時間去學習研究,知識的廣度很大程度上會影響開發人員的職業發展。
-
14 # mikechen的網際網路架構
程式設計師菜鳥與程式設計師高手的區別主要體現在技術能力、溝通能力、解決問題能力等幾個方面,簡單羅列為如下八點:
1、解決問題能力
普通程式設計師:用複雜的程式碼解決簡單的問題;
高階程式設計師:把複雜的問題簡單化並用簡潔的程式碼去實現。
2、文件寫作能力
普通程式設計師:文件有嘛用,我習慣寫程式碼;
高階程式設計師:不僅能寫好程式碼,還能寫出淺顯易懂的文件。
3、bug修復效率
普通程式設計師:利用搜索引擎(百度)尋找答案,經常找不到好的解決辦法,然後不斷更換技術方案;
高階程式設計師:利用搜索引擎(Google)尋找答案,一般bug都順利解決(與前期框架選擇的關係大)。
4、溝通表達能力
普通程式設計師:我只管寫程式碼。
高階程式設計師:良好的溝通能力,能快速理解產品設計思路,更能展現個人所長。
5、優雅和美觀的抽象能力
普通程式設計師:好用,從實現的角度進行堆砌;
高階程式設計師:好用+好看。經常思考使用者操作這個功能時,還會做什麼事情。
6、對開源社群的關注度
普通程式設計師:極少混跡開源社群,導致對新技術發展關注度偏低。
高階程式設計師:擁抱開源社群,認識技術牛人,分享、學習新技術。
7、面對功能點
普通程式設計師:立馬開始構思自己如何實現腦海裡出來一個方案。
高階程式設計師:發現功能點很普通,git有非常多的解決方案,根據業務選擇一個最適合最優的方案。
8、各種程式設計規範
普通程式設計師:隨性,不考慮後續工作開展順暢與否;
高階程式設計師:有規律可循,要求嚴謹,執行流暢,後續有問題處理也更容易。
-
15 # 一個存在感小透明
如果你加入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可能是空值等等情況。
綜上,除了樓上各位提到的程式碼規範,註釋規範等基本素質。保持學習狀態,從而有足夠的輸出,以及擁有全域性思維,都是做一個優秀的程式設計師非常重要的特質。
-
16 # 碼農視界
高手和菜鳥的區別,很多時候不是可觀的從某一方面去衡量的,很多時候高手看待事情和處理事情的態度,工作時候的高效率和思考自學能力都是不同的。
菜鳥和高手的區別,菜鳥看書1年的書,高手看10分鐘。
高手寫程式碼的速度和菜鳥肯定也不是一個級別的。
所以,趕緊提升自己的技能,不斷的學習才能把自己從菜鳥變高手!
-
17 # 千鋒武漢
說起程式設計師人們的第一印象就是工資高、加班兇、話少錢多頭髮少。再加上現在科技網際網路公司太吃香,BAT、華為、小米等公司程式設計師加班情況被廣泛傳播,程式設計師用生命在敲程式碼的印象刻在了很多人的心裡。
與其它行業一樣,凡事都有高階和普通,雖然都是敲程式碼但也有大牛和普通之分,大牛程式設計師,一個人比一個團隊做專案都做得快,最為出名的當屬十幾年前求伯君在做wps時,一個人完成了微軟二十人團隊沒有完成的專案需求,也讓wps在與微軟的競爭中站穩了腳跟。程式設計師的能力差距真的比貧富的差距還要大,除了能力當然還有一些其他的影響因素。
從工作的方面來說,普通程式設計師和高階程式設計師一般有下面幾個區別:
一、普通程式設計師
1、知識體系零散,沒有系統性的思維,在寫程式碼、改bug的時候沒有工程素養,往往是拆了東牆補西牆。
其實在面對一個未知的問題時,如何定位複雜條件下的問題、如何抽絲剝繭地分析問題的潛在原因、如何排除干擾還原一個最小的可驗證場景、如何抓住關鍵資料驗證自己的猜測與實驗,都是體現程式設計師思考力的最好場景。
2、對某種語言的依賴性太強,知識無法很好的遷移,一旦換了語言,或者領域不同就會不知所措。
程式設計師是一個非常殘忍的職業。你所學所用的語言、框架、模式,很可能在數年內就成昨日黃花了;你現在嘲笑的另一群程式設計師,可能馬上就能轉身來嘲笑你了。
3、經驗不足卻自認為自己經驗豐富,只對自己做過的比較順手,但是碰到未知的問題,就束手無策。
4、毫無必要的拖延,這是很多程式設計師的通病。
見過一些程式設計師,每天工作前一定要先玩半個小時的遊戲,起身吃點東西,再看一會劇,突然有點困了先休息一下,還有好幾個小時呢一定能完成,不如再玩會...
每次工作拖到深夜,第二天要睡到中午才起床,精神狀態也不好,心情也很糟糕。把時間浪費在毫無價值的事情上,留給自己的時間就少了,很快就會被淘汰。
5、心猿意馬。
見過太多心猿意馬的程式設計師,不得不把“專注眼下”專門提出來。
他們往往有各式各樣的小夢想,比如做個小茶農、做個小鵝販、做產品、做銷售、做投資,卻被程式設計師的高薪或是沒有轉行的魄力“耽誤”了,而因為不專注,他們不在意做好自己的本分,不在意錘鍊自己的技能,不在意學習新興的技術。
不可否認,這世界上存在著偉大的產品(像喬老爺)、偉大的銷售(像埃裡森)、偉大的投資客(像彼得菲),而他們毫無例外都是程式設計師出身。可你聽說過巴菲特評價蓋茨的話麼,比爾蓋茨如果轉行去賣狗,那他一定是全世界最大的狗販,因為他足夠的專注。
二、高階程式設計師
1、知識體系完整,有系統性的思維,及時沒有到架構師的級別,在寫程式碼和改bug的時候也能從整體上去思考和把握。
2、學習能力強有了自己的心智模型,知識可以自由遷移,並可以高效地切入不同的領域和語言。
3、擁有真正的經驗,不只是做夠那些專案,而是面向未知的解決問題的能力。
能力不缺的前提下,主要的區別就是抓不到問題的本質,普通程式設計師多半是直線型思維,見招拆招,乾的多,想得少,接到一個專案就開始噼裡啪啦敲程式碼,不想就在電腦上敲上include ,一天敲個幾千行。
而高階程式設計師更擅長抓住問題的本質,將看似複雜的需求化繁為簡為一系列簡單邏輯的堆疊,寫程式碼步步為營,邏輯簡單清晰,所有條件分支都被仔細覆蓋,磨刀不誤砍柴工。
簡單的來說,同樣是一個專案需求,普通程式設計師可能要天天加班忙上一個月,而高階程式設計師可以每天按時下班,幾天就搞定。這也是為什麼會出現“月薪五千的程式設計師天天加班到夜裡,月薪五萬的程式設計師5點下班”的尷尬情況。公司追求的是利潤而不是努力,誰創造的多當然拿到的就多。
三、如何從普通程式設計師進階到高階程式設計師?
1、提高程式碼最佳化的能力
打鐵還需自身硬,“程式碼可執行”對一個優秀的程式設計師來說絕不是結束,而是開始。優秀的程式設計師一定熟知各種演算法和資料結構,會靈活運用,致力於寫出更簡單、效率更高的程式。
程式設計師必須首先具備專業技能,才能在這個殘酷的領域裡存活下來,不要沒幹兩年就想著去管理,拋棄專業知識。翻一翻網際網路招聘職位列表就知道了,一百條裡面99條是各種各樣的工程師,好容易有一條是管理性質的,一看是總經理,您能勝任嗎?
2、先考慮、多思考
程式設計思路,是系統的計劃和設想,是程式設計師寫程式時的條理和線索,可以思考但不要長時間延時性的思考。
或許做著做著,希望就來了。
3、突破程式設計師思維只有突破程式設計師思維,才不會淪為碼農!
過去我曾一直認為程式設計師是依靠他們的技術在程式設計,也是因為技術使得程式設計師的水平有高低之分,但隨著我寫程式碼的時間越來越長,也接觸到更多的程式設計師,我漸漸發現程式設計師們其實是依靠他們所特有的程式設計師思維在進行程式設計的,而他們中的佼佼者正是那些有著更高思維成熟度的優秀程式設計師們。
從程式設計師的發展角度來說,當你從一名程式設計師轉變為高階程式設計師、架構師、系統分析師、專案經理、產品經理的時候,需要你突破程式設計師思維,而從更人性化的角度去識別和解決問題。
4、時間管理
很多人都沒有時間管理意識,覺得時間最不值錢。
這就像是你到了一個十字路口,也不管自己想去哪裡,抬腳就努力地奔跑,一路上被自己的努力所感動,但你跑的方向是北邊,而你內心真實想去的方向是南邊,方向跑偏了,始終到不了目的地,能不迷茫嗎?
在很多人的意識裡,時間太不值錢了。所以大把的時間可以浪費在路上,浪費在毫無效率的溝通中,浪費在沒有計劃的行為上。
可人這一生,最多才有多長時間。一旦你把額度浪費在毫無價值的事情上,留給自己的時間就少了。
5、學而不思則惘
總結對於任何人都是很重要的,功能交付、上線成功,對於工作來說是結束了,但是對於開發者本身並不意味著結束,可能此次開發只是改動一個小的功能,並且開發時間很緊張,開發過程中沒有從整體上審視整個專案。
那麼在上線成功後找時間在回過頭來繼續審視一下整個專案就顯得尤為重要,業務流程,整體架構,技術實現細節,專案龐大,一次可能時間不夠不能完全消化,那麼多幾次研究總結無論對以後開發時間的評估,或是對專案提出建設性的意見,都會有很大幫助。
6、拓展知識的深度和廣度
新技術層出不窮,程式設計師如逆水行舟,不進則退,而且就算進的慢了也是後退。
大家可以多看看 BAT 的招聘要求,看看自己還有哪些方面根本沒接觸過。建議大家多關注熱點和優秀的開源專案、找到自己的興趣點就多花點時間去學習研究,知識的廣度很大程度上會影響開發人員的職業發展。
寄語
IT領域的人員分佈是金字塔形的,越往上的人,技術越好,競爭的壓力也相對就會小,所以好的程式設計師一定是深究技術原理、多看原始碼的程式設計師,萬變不離其宗,知道使用的技術是如何實現的用起來自然得心應手!
回覆列表
程式碼的展現,網路的應用.菜鳥”程式設計師的程式碼是什麼樣子,自己想一下。“菜鳥”程式設計師的程式碼往往會會寫的比較冗餘,而且這些程式碼不是從書上找來的就是從網上找來的還有可能就是自己會這一部分程式碼(僅存記憶的提取,真正的原理似懂非懂,好像霧裡看花.真正的原因是:“菜鳥”程式設計師沒有將自己的思維融入程式碼,程式碼是程式設計師思維智慧的結晶。
為什麼會出現這樣的現象,同樣一個小的功能,放在不同的手裡就產生不同的結果。這個難道不值得我們去探究原因嗎?
真正的原因是:“菜鳥”程式設計師沒有將自己的思維融入程式碼,程式碼是程式設計師思維智慧的結晶。當我們拿到這一個小功能的時候,我們首先一看,這方面的知識自己準備不足,於是就上網找去了。假如我們去想一下如何去解決,我們解決的方法一般會有兩種,第一種是自己會從網上或者是書中找到類似的程式碼,第二種就是請教別人指點,這種方法感覺不太可能,因為在工作中,大家都很忙,相互討論幫忙很少的。上網搜的時候我們會經常出現這樣的現象:看到這個要編寫的程式,感覺自己沒什麼思路,自己從網上找,找了半天我們收穫不大,看了很多實現的方法,但是我們花很長的時間去理解,這樣雖然把問題搞出來了,然後就去玩去了。有些時候運氣好,想找的問題正好有這類問題的解決方法,那我們就直接把程式碼搬過來,搞定!所以我們就一直這樣迴圈下去,到最後我們什麼也沒有留下,下面一幅圖就顯示我們”菜鳥”程式設計師的現狀.
“大神”程式設計師首先拿到這個程式,自己做的第一件事情,就是思考!自己先思考如何實現這個問題,與原來相關知識可以借鑑,列出解決問題的可能性,考慮解決問題的最難點,所以上網搜的時候,直接搜問題的解決問題點,將其轉換成自己的思想,用自己的思維寫出自己想要的程式碼來,這就是程式碼是思維的結晶的精華。