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

zhihu - 姚冬發表於2014-12-26

學習能力,尤其是自學能力,你啥時看到那些有名的程式高手在論壇上問“學習 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 的程式碼,你經過一段時間去回頭看,也有很多思考不正確不合理的地方,有很多優化點,如果你覺得自己的程式碼一向牛逼,毫無破綻,那你一定是原地踏步,毫無進展。

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

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

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

大概就這些

最後重述一遍

什麼是能力?

遇到問題的態度

處理問題的思路和方法

這就是能力

相關文章