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

從程序代碼的命名，咱們就能夠看出一我的的水平。最差的命名就是使用中文、拼音、拼音縮寫、中英混搭，接下來要麼是模仿式命名，要麼乾脆就隨意命名。

 

模仿式命名典型的就是「××DAL」，說實話，我以爲相似於「UserDAL」這樣的名字，我以爲太不美觀了，通常這我就知道這是典型分層架構的模仿者，說明他是有些經驗的人了。

 

隨意命名，就是寫代碼的時候，名字壓根就沒有意義，好比var list = new List<User>，其實徹底能夠寫成var users = new List<User>的。想要命名的更有意義，你只須要將每個類、每個方法、每個單詞的名字都用你開發時的意思直接描述出來就好了。

 

2

模型抽象能力

 

模型決定一個系統的可用性、穩定性、易用性、可維護性、可擴展性！

 

這個模型不是UML建模，而是軟件的核心。就是你設計一個軟件時，爲其所抽象出來的原理性的描述。模型決定一個軟件的質量、易用性和擴展性。

 

凡是優秀的軟件，都有一個共同特色，就是其模型構建的很是漂亮，固然也有不怎麼優秀的軟件，模型也很漂亮。好比微軟MEF，其模型構建很是的漂亮和優雅。MEF的核心就是組合基元，以下圖所示，它簡單的定義了動態組合的支持基礎，而後一層一層的進行擴展。

 

3

謙虛隨和

 

有一個很是有趣的現象，那些懂得尊重別人、比較謙虛的人通過深刻接觸後，會發現他們的技術每每都很了不得；而那些說話刻薄無禮，以爲這個技術不怎樣，那個技術也沒什麼了不得的，我本身的東西已經挺好的，這樣的人水平、經驗和見識通常都不怎樣。

 

軟件的問題，並非簡簡單單解決一個技術問題，從技術的角度上看，只要學會了使用技術，那麼咱們就已經掌握了技術，所以，單純的技術是很簡單的。

 

 

相反的是，軟件的協做開發、管理，軟件的易用性，軟件是否美觀，這些東西纔是最麻煩的，也每每是技術水平通常、經驗短缺的程序員意識不到的東西。有很多通常的程序員，大致都是這一類，他們以爲軟件太簡單了，沒有什麼了不得的。對於什麼思想，也不屑一顧，他們已經以爲本身掌握了不少真正的技術。

 

 

4

異常處理

 

經過異常處理能夠看出一個程序員程序設計的嚴謹與紮實的基礎知識。拿Java開發人員舉例，要發現每個方法都有可能須要強制的處理異常和聲明這個函數須要處理的異常，這種強制的約束，會強迫開發人員來習慣性的考慮和思考它。

 

不過，對於大部分人來講，它處理異常的方式就是簡單的使用try { … } catch(Exception anyException) { // 忽略異常 }，用這種方式來捕捉全部的異常信息。

 

 

這樣作的好處就是快，傻。缺點就是一旦出現問題，就不知道問題在哪發生，怎麼回事，若是有靠譜的QA還好一些，好比外企，他們都有規範的測試方法和測試流程，一旦發現問題，就會將重現捕捉完整的描述出來給開發者看。

 

不過，在國內沒有嚴格的測試是很正常的，那麼出現問題時，就傻了。客戶是絕對不可能把出現問題的方式給你完整的Repro的，一旦出現問題，客戶會幹的就是急眼，那接下來怎麼辦？你就老老實實加班，老老實實的去猜去找問題。

 

當「try { … } catch(Exception anyException) { // 忽略異常 }」這樣的代碼充斥整個軟件系統時，你就能夠想象有多可怕，這個軟件能穩定就怪了！

關於異常處理，另外一面，就是菜鳥程序員在寫代碼或者實現功能的時候，通常不考慮反面狀況，一個軟件按照正常步驟可能能走通，可是一旦出點意外，就麻煩了。如下就是一個典型的代碼。

 

If(*****)

{

// ….do something…

}

 

這個代碼處理了if，可是萬一出現else的狀況呢？可想而知，系統將會出現沒法意料的狀況。所以，這也是菜鳥程序員作的系統通常都很是不穩定的一個根源，作程序通常只考慮功能實現，忽略掉意外狀況。

 

 

5

優雅與美觀

 

菜鳥程序員並非缺少審美，缺少的是優雅和美觀的抽象能力。一個好的系統，要作到兩點，好用，好看！所以，這絕對不是單單功能上的堆砌。

 

不少國產軟件都深深的烙上了技術人員設計的印子，一看就知道這個軟件是出自一個技術人員的設計和實現，一看就知道這個軟件的實現過程，這簡直是慘不忍睹，不過，小夥伴們，這就是大家的機遇啊。

 

 

菜鳥技術人員開發功能的時候，通常都是從實現的角度進行堆砌，怎麼簡單，怎麼來。不會去仔細分析，用戶在操做這個功能的時候，到底還會作什麼事情，各個功能之間怎麼進行有機結合來完整的進行結合。相反，一些技術比較好的程序員每每都要直面客戶，常常被客戶罵，罵着罵着，也有點覺悟了。

 

固然，也有一些程序員由於自尊，直接不幹了。不過，我以爲厲害的程序員基本都有用戶意識，也但願本身的軟件能有很好的評價，甚至可以影響社會。好用，好看，是軟件可以被廣泛採用的前提，所以，咱們須要學會抽象優雅。

 

 

6

基礎紮實

 

技術知識決定一我的能作的技術的層次。基礎的知識有計算機組成原理、計算機操做系統、網絡原理、數據庫原理、計算機圖形學、編譯原理、數據結構、離散數學、人工智能等等很高深的理論知識。

 

在這些基礎知識之上，就是軟件開發語言、類庫、框架，面向過程、面向對象、面向服務等編程思想，架構思想等等。

 

 

這些知識不必定會影響你如今的工做，但必定會影響到你的格局，那格局確定也會影響到你自身的發展。我碰到過有些理論不好的人，但技術在公司內也是有些影響力的，所以，他們對技術原理就很不屑，甚至爲本身不懂太多理論而擅長實戰而沾沾自喜。

 

這些人會對那些懂理論，但動手能力通常的人顯示出由內而外的鄙夷，可是他們殊不知道那些既有基礎知識，也有動手能力的高手作出的東西是怎樣的。就像不少人都想不通，那些技術天才是如何開發出一個數據庫、操做系統這樣的軟件。

 

所以，若是你已經發覺本身基礎不夠紮實，那麼仍是有空就修煉修煉本身的內功吧！

 

 

7

文檔與表達能力

 

不少技術人員都寫不了文檔。不過，坦白的講，若是要得到更好的報酬，文檔是絕對關鍵的因素。沒有文檔就沒有溝通，就沒有交易。有人提了，「文檔是第一輩子產力」，這是很是有道理的。

 

文檔的類型有不少，針對的對象也各不相同。不一樣的人，對文檔的理解能力也是徹底不同的。所以，你的文檔必須適應於你的目標。這個對於搞技術的人太難，他以爲還不如寫代碼來得快。

 

表達能力決定了你所作的技術的影響範圍，決定了你的影響力，決定你的威信。所以，也絕對的影響到你的報酬。由於這個能力而影響到你的報酬，你可能會內心以爲虧，但沒有辦法，這是硬傷。

 

 

這可不只僅是我只是不擅長寫文檔，但我擅長於搞技術這麼簡單。若是哪一天，有一個擅長忽悠，技術不如你的人，爬到你的上面而且領導你，那也是該的。千萬不要去怪別人擅長忽悠，而是要想辦法來彌補本身的硬傷。

 

 

8

積極的心態

 

技術好的人，通常人都壞不到哪去。很簡單的一句話，想要技術好，就要投入時間，有時間投入到技術，那麼就沒有時間投入到其它方面，特別是消極的坑蒙拐騙，所以，技術人員通常也都比較靠譜。

 

積極的心態，不只僅對於技術，對於生活也是如此。一旦有了積極的心態，那麼菜鳥到高手的過程，僅僅是時間的問題！

 

 

9

以爲軟件不值錢

 

程序員都特別煩的就是作一個軟件和一些水平不怎麼高的技術人員談費用的問題。只要是想要作好，沒有哪個事情是簡單的。凡是靠良心和能力謀生的，都是依靠自身的實力來獲取合適的報酬，咱們每個人都須要有收入。

 

可是，咱們很難改變一些技術人員認爲軟件不值錢的想法，他們的理論是，這個功能放我身上，我一天就搞定了，憑什麼你要那麼多錢？

 

但是，我們的作法同樣嗎？一個功能的實現方法有不少種，就像我說的數據採集。若是你的數據採集實現沒有如下「一、二、3」這些輔助的功能，後臺的實現要簡單的多。

 

 

若是沒有指令重試，沒有多線程，沒有異步刷新，沒有7×24小時穩定運行，沒有采集數據丟失，沒有指令優先級排列，沒有多線程和分佈式集羣採集，沒有支持1天1GB數據採集等等這些非功能性的需求。

 

那麼這個軟件會更簡單，我也見過有人用一個控制檯，用一個單線程，顯示的信息都是徹底看不懂的二進制數字，運行一會CPU就100%，內存不斷升高的採集軟件。這個也算得上是採集軟件。

 

不過，菜鳥程序員通常都會按照本身的作事方法來對軟件進行評估，若是沒有好的經驗，通常都會認爲軟件很不值錢。事實上，作好看的、好用的軟件很是難，作好看、好用、還要好維護以擴展的軟件那就是難上加難。

 

軟件是一個充滿智慧結晶的勞動成果，若是說的高尚一點，有些軟件時無價的。