什麼才是程式設計師的核心競爭力？

學習能力，尤其是自學能力，你啥時看到那些有名的程式高手在論壇上問“學習 XX 該看什麼書，如何快速學習 XXX，學習 XXX 有什麼程式碼推薦”之類的問題，他們想學什麼很快就能自己找到相關資料。這個行業發展太快，技術淘汰的速度也很快，3 年不學新東西就可能落伍了。

動手能力，都是看書看資料，當別人還在糾結看什麼書，還在糾結書裡的字句是什麼意思的時候，有些人的幾百上千行程式碼都已經能執行了。

耐心和毅力，做程式設計師興趣固然重要，寫自己喜歡的程式碼那是相當愉快的事情，但是程式開發中無論如何還有大量乏味無趣的事情，要能堅持，咬牙把這些做完。

表達能力，能在大庭廣眾下，把自己的想法邏輯清晰流暢地講出來，讓人聽懂。

那麼技術呢？技術不重要，有了以上幾種能力，市場上需要什麼技術，很快就能掌握了。

最後再說說工資的事，記住兩句話：

工資不是老闆對你過去貢獻的回報而是對你未來貢獻的預期。

現任老闆不可能給出讓你滿意的工資，下一任老闆才會。

曹政，資料控/歷史控/考證控

姚冬回答的非常好，我狗尾續貂的說幾句。

我們都知道學習能力很重要，那麼學習能力從何而來，除了去看書上課這種，如何在實踐工作中學習成長？

我之前微博說了一個籠統的概念，什麼是能力？ 對待問題的態度，以及處理問題的思路和方法。

先說態度

你伺服器偶爾出 501 錯誤，也許比例不高（知乎也出現過很多次），很多程式設計師，沒錯，是很多，假裝看不見，不在乎，或者歸咎於人品問題。 這就是態度問題。

再往後，負載高了或者其他什麼原因，突然頻繁出現 501 錯誤，不去追尋深入的原因，而是找各種藉口， 什麼 IDC 服務商不好，伺服器品牌不好，作業系統不好，資料庫不好，CDN 不好，網路狀況不好，web server 不好，甚至，直接對 Boss 說我們被 DDOS 啦！（遇到過，幫他 Boss 找過多個安全專家會診，最後發現根本不是 DDOS，是程式設計師太爛。）

這就是態度，觸目驚心，如果能對問題有敏感性，能知道對任何小的，輕微的問題有足夠的敏銳度，你就有了一個快速成長的基礎。對問題的敏銳度是非常重要的。很多效能或程式邏輯上非致命的 bug，在不夠敏銳的時候是發現不了的，但是一旦進入特殊場景就會驟然爆發，你多一點敏銳度，就會減少這種危機的風險。

第二個態度是解決問題的態度，有人對自己的解決方案信心滿滿，認為萬無一失，但有的人就會多留一條後路；就好比你說我伺服器要不要做安全加固，肯定要做對不對，要做到儘可能嚴謹和周全，但是你資料庫儲存密碼的時候是不是還要加密?而且要隨機 salt，不就是防止萬一依然有漏洞被人拿庫怎麼辦麼。程式也一樣，以前寫的一些服務端守護程式，有 bug，會莫名其妙的終止，這個 bug 當然要定位，要修復，但是同時，寫一個 cron 檢查這個守護程式狀態，一旦遇到終止給予自動恢復，這就是第二手準備，即便你多麼不希望他執行，這個準備還是要做的。對問題 做兩手甚至三手準備，也是優秀程式設計師，架構師的關鍵素質。

第三個態度是基於溝通與理解的態度，產品或運營提了一個不靠譜需求，一句話打回去當然很爽很威風，但是有沒有仔細溝通分析過，這個需求基於怎樣的實際訴求，這個實際訴求有沒有更合理的實現途徑，一句話“這個沒法做，這個實現成本太高”，不是正確的溝通態度，而且，最優秀的產品，往往是實現了那些原本人們認為無法實現的訴求。

這樣的態度，才有了一個持續進步的基礎，下面說思路和方法。

優秀 的程式設計師和平庸的程式設計師，如果只看敲打程式碼的速度，我覺得是分不出來的，也許每人都可以一天寫很多行程式碼，但是遇到問題後，平庸的程式設計師的解決效率，和優秀程式設計師相比就會有天壤之別。 所謂解決效率，不外乎對 bug 的分析、定位，以及 思考。

最基本的一條，看執行日誌，看各種日誌，web server 的日誌，資料庫 的日誌，慢查詢日誌，binlog 日誌，php 的錯誤日誌，等等等等，線上出問題瞎猜連日誌都不看的大有人在。看日誌不仔細不完整的也大有人在，你能去認真研究日誌已經超越很多人了。

第二條，模組測試和斷點分析，程式設計師一個壞習慣就是上來就寫很大一坨程式碼然後再執行，不知道一個模組一個模組來寫來測試，執行出了問題不知道設定斷點，縮小範圍逐步分析。斷點分析非常簡單，將整個程式碼中插幾個中間輸出，觀察哪個環節出了問題，或者觀察每個環節的系統開銷，對調錯和效能優化都非常重要，高手們大概認為這是 ABC 的東西，但是就這玩意我看到的大部分程式設計師都沒有這個習慣。

第三條，錯誤資訊 的理解和搜尋，搜尋引擎上有各種豐富的技術資料和技術問答，你所遇到的錯誤資訊和錯誤提示，通常都能在網上搜尋到，當然，搜尋到後要結合你的場景認真思考，並理解透徹，而不是照貓畫虎的去處理，否則可能這次運氣好就蒙對了，下次運氣不好又不知道怎麼回事了。

第四條，不斷總結歸納，對一個問題，一類問題，以及不同型別的問題，善於歸納整理，不斷反思自己的問題，即便是不出 bug 的程式碼，你經過一段時間去回頭看，也有很多思考不正確不合理的地方，有很多優化點，如果你覺得自己的程式碼一向牛逼，毫無破綻，那你一定是原地踏步，毫無進展。

關於 歸納總結，我說個案例

以前我們有個系統，請求量非常大，負載非常高，有個不錯的技術經理來處理，他列了幾個升級計劃，都很靠譜，去執行了，效果非常好，然後我們跟進彙報的時候他來講，做了幾項升級，整體效果如何，然後我就批評了他。

我批評了什麼呢？他是一起做的升級，然後一起觀測的效果，那麼這幾個方案裡，具體每個方案的實際效果怎樣，對提升的幫助多大，他沒有任何資料。所以對具體每個升級方案的價值和重要性，他沒有任何概念。你正確的解決了問題，卻沒有認真的去歸納整理，你的收穫是有限的。一起做升級不能說是錯的，但是效果評估需要單獨去做，而這個資料是非常有價值的，知識積累，不是你處理過的就一定有積累，而是整理過的。

大概就這些

最後重述一遍

什麼是能力？

遇到問題的態度

處理問題的思路和方法

這就是能力