1. 程式人生 > >大牛程式設計師經驗:什麼才是程式設計師的核心競爭力?

大牛程式設計師經驗:什麼才是程式設計師的核心競爭力?

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

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

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

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

大概就這些

最後重述一遍

什麼是能力?

遇到問題的態度

處理問題的思路和方法

這就是能力