私下里，經常有一些讀者問我：“作為一名軟件開發者，我應該掌握哪些技能，才能被領導賞識給我呢?”說實話，我心目中很多選項，不少于 20 個，但我斟酌再三，只挑選了其中最能讓你受益的 8 個，不僅能讓領導賞識你，還能讓領導給你升職加薪。

[[319334]]

01、吃透一門編程語言

這個技能看起來似乎沒有必要強調，畢竟程序員不懂一種編程語言也說不過去啊。我之所以再次強調是怕你“貪心”，以為技多不壓身就拼了命的學很多種編程語言。

有個大二的學生就曾經問我：“你好呀，老哥，有個問題想咨詢一下您，我專業學的是 C#，但聽說以后不太好就業，所以就自學了一段時間 Python，但感覺越來越混亂了，您有什么好的建議嗎?”

我只能說不混亂才怪。編程語言雖然有相似的語法，但畢竟是不同的編程語言啊，之間還是有很多差異的。對于初級程序員來說，切勿貪多，先把一門編程語言吃透再說，等你有了融會貫通的本領，再去學新的編程語言也不遲。

我剛剛查了一下(見下圖)，C# 還是挺熱門的編程語言，沒到不太好就業的地步，別隨便聽信別人的話，要學會自己去判斷。Python 是門不錯的編程語言，增長勢頭很猛，但遠沒到那種獨霸天下的地步。

學校有不盡人意的地方，但不至于蠢到讓學生學一門已經被市場淘汰的編程語言。在這一點上，我寧愿站在支持學校的立場上，否則就太糟糕了。

我承認，學霸學什么都快，不僅學的快，還比平常人學得好，學得多，因為他有一套自己的學習方法，但大部分學生并不具備這種條件。如果你對自己沒有這種認知的話，很可能會陷入泥潭。

因此，我給出的建議是，深入并且專注于一種編程語言，當你對使用這種編程語言充滿信心時，再去學其他的編程語言也不遲。

02、整潔的代碼

當你學會一門編程語言之后，接下來要考慮的事情就是讓你編寫的代碼變得更整潔，更易于理解，更富有藝術。關于藝術，我想到了一段話，王小波在他的雜文《用一生來學習藝術》說的：

我念過文科，也念過理科。在課堂上聽老師提到藝術這個詞，還是理科的老師次數更多：化學老師說，做實驗有實驗藝術;計算機老師說，編程序有編程藝術。老師們說，怎么做對是科學，怎么做好則是藝術;前者有判斷真偽的法則，后者則沒有;藝術的真諦就是要叫人感到好，甚至是完美無缺;傳授科學知識就是告訴你這些法則，而藝術的修養是無法傳授的，只能夠潛移默化。

不得不說，偶像就偶像，把藝術的真諦闡述得很清楚。我見過不少臃腫的代碼，它們讓我想起“裹腳布”這三個字;我也見過不少整潔的代碼，它們讓我想起“藝術”這個詞，我想創造出它們的程序員一定富有工匠精神。

Elliot Chance 曾表達過這樣一個觀點，他說：“要分辨兩個程序員的優劣，就是給他們一樣的時間，越好的程序員寫出來的代碼越少(當然是可以運行的)。”

我同意他的觀點。越多的代碼并不一定代表著認真，有可能代表的是懶惰，懶得去思考，才會寫出臃腫的代碼。如果我們程序員沒有這種(寫更少代碼的)追求的話，那我們的編程技藝就只會原地踏步，長此以往的后果就是各種避免重復造輪子的第三方類庫就不會出現。

03、算法與數據結構

說起來慚愧，在很長的一段時間里，我對算法和數據結構存在著很大的偏見，認為它們就好像懸掛在夜空中的月亮，雖然很美，但卻很遙遠。

因為這種偏見，在敲代碼的過程中吃了不少的悶虧，經常遇到一些實際的問題，由于無法充分利用數據結構將數據之間的關系通過合適的算法策略進行有效地存儲轉換，就導致程序的性能很低。

作為一個吃過虧的男人，我必須要負責任地提醒你，趁有大把的時間和精力，多投入一點到數據結構和算法上面去。基礎知識就像是一座大樓的地基，它決定了我們的技術高度。數據結構和算法就是最重要的基礎知識，學習它們的過程就像是在打地基。

舉個例子來說，假如你要在一個列表中對元素進行排序，那么可采用的算法就有下圖中的這 10 種，每種算法所花費的時間，所占用的內存都不盡相同。換句話說，如果你不能夠熟練地掌握算法和數據結構，就很難找出一個優雅的解決方案。

長期來看，大腦思考能力是一個人最重要的核心競爭力，而算法是為數不多的能夠有效訓練大腦思考能力的途徑之一。有了這項能力，很多別的程序員解決起來很困難的編程問題在你這里就會迎刃而解。

04、基本的數據庫知識

雖然軟件開發人員更應該專注于程序設計而非編寫和優化 SQL(應該交給專業的數據庫管理員負責)，但在我們國內，只有優秀的企業才會有數據庫專家。扎心了。如果你想要在軟件開發這條道路上走得更高更遠，懂一些基本的數據庫知識是必須的，比如說：

• 如何將業務中的對象屬性轉化為數據庫字段;
• 如何從數據庫中檢索數據，并將數據集拼接在一起;
• 如何往數據庫中插入、修改、刪除數據;
• 索引的數據結構及原理;
• SQL 語句的優化;
• 等等。

如果再懂一些數據庫分庫分表的中間價，那你可能就會成為團隊的寶貝了，畢竟所有的應用程序都要與數據庫交互，另外，數據庫是系統最先出現性能瓶頸的地方——總有你大展身手的時候。

[[319335]]

05、技術框架

除了要吃透一門編程語言，我強烈建議你再學習一個技術框架。如果你像我一樣是個 Java 后端開發人員的話，Spring 的系列框架(Spring MVC、Spring Boot、Spring Cloud)就不得不學了;如果你是一個 C# 開發人員，.NET Framework 就不得不學了。

技術框架是一組通用類庫的集合，它幫助我們讓編程任務變得更簡單，畢竟輪子替我們造好了。假如說沒有技術框架的話，我們就好像坐著馬車前行，而不是飛機、高鐵和汽車，開發效率就要大大降低了。

06、源代碼管理工具

記得我剛參加工作那會，用的源代碼管理工具叫做 CVS(Concurrent Versions System)，估計有不少讀者沒聽說過，非常非常難用。后來遷移到 SVN(Subversion)后，情況總算是有了很大的改善，它不僅支持 Eclipse，還有專屬的客戶端，除了管理源代碼，還可以管理許許多多的文檔。

每天上班的時候先從服務器獲取新的代碼，然后開始一天的工作，下班走之前切記要提交一次代碼，否則就很容易耽擱團隊其他成員的開發進度。

現在呢，有了 Git，它是一套開源的分布式版本控制系統，可以有效、高速的處理從很小到非常大的項目版本管理。它與 SVN 比較大的不同之處，在于每個開發者的電腦上都會有一個本地倉庫(Local Repository)，即便是沒有網絡也一樣可以提交版本，查看版本，以及比較版本;等到網絡連接上之后，再提交到服務器端。

源代碼管理工具比較大的好處就在于它可以幫助我們保留不同文件更改的歷史記錄，并且允許多個開發人員對同一文件的代碼進行合并。舉個例子來講，小王完成了一項任務，然后提交了代碼;但他覺得有待改進，于是他重新修改了代碼并提交到了版本庫，誰知道，程序上線后出了 bug，這時候源代碼管理工具可以幫助他快速回滾到之前正常的版本。否則的話，小王只能被祭天了。

07、測試

測試真的是太重要了!但并不是所有的開發者都這樣認為，這種感覺在我回到洛陽后尤其強烈。竟然有團隊成員不經測試就把代碼提交到代碼庫，并且是會報錯的那種，我天吶，遇到這種隊友我也是醉了。

在我回來之前，是在一家日企工作，測試是一項非常重要的工作，占用的時間比代碼編寫的時間多多了。從單元測試到集成測試，所有的測試結果都要整理成冊，所有的邊界條件都要測試到，哪怕你覺得完全沒有必要。但正是這種一絲不茍的態度，成就了日企軟件高質量的美譽。

一個優秀的開發人員絕不允許他的代碼在交給別人之前不經測試，我想這是不容置疑的。

08、調試

說句實在話，在我做程序員的這 10 年里，調試代碼的時間比編寫代碼的時間要多得多。因為解決 bug 的難度要比創造 bug 難得多，首先你要先復現問題的場景(真的是難啊)，要復現問題就需要你擁有出神入化的調試技巧，否則只能錘爆鼠標，然后大喊“為什么，為什么，為什么我的代碼無法正常運行呢?”

入門級的調試很簡單，你只需要在發生問題的代碼處打個斷點，然后再跑一跑，就能從堆棧信息和代碼的上下文中發現問題。難度再上升點的話，就需要你創造代碼執行的條件;再難的話，你甚至需要內網穿透，比如說微信公眾號開發;再再難的話，就不是一句半句能說得清楚了。

總之呢，調試就是為了讓你弄清楚代碼不能正常運行的真正原因，如果你的調試技巧不過關的話，甚至有可能會被表象蒙騙，從錯誤的角度去修改 bug，從而引發更多、更大的問題。

09、鳴謝

好了，親愛的讀者朋友，以上就是本文的全部內容了，能看到這里的都是很優秀的程序員，我必須要伸出可愛的大拇指為你點個贊。如果你也覺得自己很棒的話，就無情地轉發和在看吧，我需要你的支持。