怎樣才算得上合格的程式設計師

程式碼灣發表於2017-12-18

最近同一部門另一個專案組的一位程式設計師被“主動離職”了,雖然我未曾與這個程式設計師共事過,但是聽過一兩次他的內部分享,感覺技術還是挺厲害的。後來與一個訊息靈通的同事聊天,才知道真正的原因是老大覺得A難以溝通,搞得其他程式、QA都怨聲載道。工作這些年,身邊的好多同事來了又走了,主動或被動,這不禁讓我思考什麼樣的程式設計師算得上合格的程式設計師。

雖然大家都自稱“碼農”、“IT民工”,但我相信,這僅僅是自嘲或者自黑,大多數程式設計師應該還是認可自己的這個職業的,當然,我算不上一個優秀的程式設計師,因為我都不曾在開源社群貢獻過程式碼、也不精通白板演算法、對技術也不狂熱、不geek。我的目標是做一個合格的程式設計師:把本職工作做好,對得起自己的薪水,在生活與工作平衡,996什麼的我是難以接受的。

對於程式設計師而言,技術過關當然是非常重要的,這是硬實力。然而只會技術也是不行的,畢竟大多數的程式設計師還是要與人打交道,軟實力也是不可或缺的。怎樣才能算合格,我認為有以下幾點:

紮實的基礎

計算機領域是一個快速更新換代的領域,每隔一段時間都會有新的語言、框架、思想產生,追隨每一個新技術很累。但仔細想想,事實上並沒有那麼多新東西。很多新東西只不過是已有技術的封裝、或者借鑑的其他領域的技術。比如快取資料庫redis、memcached,其基本思想不就是作業系統中的快取嗎;分散式儲存中的分片與複製集,不就是檔案系統中RAID的擴充套件嗎;還有Google的MapReduce框架,不就是來源於函數語言程式設計語言的map reduce嗎。掌握好計算機基礎知識,能夠更本質的看待新技術。

善用工具

磨刀不誤砍柴工,打造好自己的工具集非常重要。

開發中會用到大量的工具,不管是編輯器、除錯工具還是監控工具。大家都喜歡爭論哪個IDE更好,然而這並沒有多大意義,關鍵在於能夠熟練的使用自己喜歡的工具,掌握各種快捷鍵,高度自定義,這樣能夠大大提高工作效率。而且對於日常中重複的操作,最好指令碼自動化,這裡推薦以下python,寫小工具還是很快的。

另外,強調程式設計師必備的兩個工具,那就是瀏覽器和VPN。後者大家都懂的,不多說,主要是有了後者才能發揮瀏覽器的威力。瀏覽器大家天天都在用,但是如何高效的使用,比如在指定網站搜尋、通過標題、url過濾、選擇合適的關鍵字 還是值得研究一下,對於程式設計師,要使用好瀏覽器,那還得具備下一個能力:英語

過得去的英語

不得不承認,在軟體創新領域,國內還是落後於國外的,新的技術、一手的資料都是英文的。當新技術被廣泛應用之前,我們在百度搜到翻譯要麼是machine translated,要麼錯誤百出。看翻譯的最大問題取決於翻譯者本身的水平,即使翻譯水平都很高,但同一個單次往往有不同的翻譯,導致看文章的時候會有困惑,最好還是直接看英文原文。大多數原文,除去專業詞彙、還是比較好理解的,而且,我發現很多牛逼的專案,都有非常通俗易懂的文件。

良好的編碼習慣

程式碼是寫給機器執行的,同時也是給人閱讀與維護的。維護者可能是別人、也可能是幾個月後的樣子。良好的程式碼規範,必要的、清晰的註釋可以讓自己少被問候祖宗十八代。

對於程式碼風格,網上爭議也很多,最重要的是保持專案內的統一。做為技術負責人,一定要在專案開啟之初就頂號規範,當大量程式碼被堆出來之後就很難統一了,然後做好新人的review。

保持學習

程式設計師這個職業,相比其他職業,可能還是要年輕許多。特別是在國內,最老的一批程式設計師好多都轉管理了,再過10年20年,我們會怎麼樣呢,沒人知道。前段時間華為35歲程式設計師被離職的事情,給我們敲響了警鐘,悲哀之餘,只有盡力學習了,拼不過體力就拼能力與經驗吧

學習這個事情說起來就複雜了,我覺得兩點很重要:基礎、學以致用。

獨立思考

合格的程式設計師解決的是問題,而不是實現某個解決方案。產品經理(特別是知道一點技術的產品經理)的某個需求可能只是某個問題的解決方案,他認為這個方法可以解決他的問題,於是把解決方案當成了需求,而不是真正的問題。程式設計師應該主動溝通,多問幾個為什麼,瞭解真正的問題,也許能有更好的解決方案。

之前就有這麼個例子,給到的需求:為每一個使用者(使用者有唯一的id標示)生成一個唯一的邀請碼,同時也要為未來一段時間可能增加的使用者預生成邀請碼,儲存到資料庫。而真正的需求是老使用者分享自己的邀請碼,如果新使用者使用了該邀請碼,則老使用者獲得相應獎勵。而我提出的方案很簡單,直接使用者的唯一id生成可逆的邀請碼,這樣就根本無無需資料庫儲存。

圖0:怎樣才算得上合格的程式設計師

產品經理經常改需求這是程式設計師最頭疼的事情,作為程式設計師應該也站在PM的角度思考,幫助PM分析出本質的需求,這也許可以減少需求的變更。當然,前提是得幹一行愛一行,需要對業務有一定的瞭解。

先思考後行動

寫程式碼的時候先想清楚了再下筆,而不是先寫出一堆程式碼,然後在開始修bug。

休bug的時候,多看看上下文,搞明白為什麼出bug,修改這個bug可能帶來的影響,然後再修改。反面教材有兩種:第一種隨便改改就把程式碼改好了,但自己心裡並不清楚為什麼這樣修改就修好了,撞運氣,也許還有其他同樣的bug也發現不了。另一種就是,頭痛醫頭腳痛醫腳,不仔細評估修改的影響,這樣往往會引入新的問題。

程式設計師成長的一個辦法就是修bug,修別人用不了的bug,但前提是搞清楚bug的緣由,這樣才能避免類似的錯誤,有所收穫。

順暢溝通

不是巧如舌簧、也不是忽悠達人。需要的只是耐心傾聽,然後清晰表達自己的意見。

現在的軟體開發,已經不再是單打獨鬥的年代,大多數的軟體、產品都需要多人、多部門的協作。而交流、溝通是非常耗時耗力的。溝通之前,先想好目標,組織好語言,儘量不要發散、不要跑題,對事不對人。對於重要的事情,保留溝通記錄,最好有郵件,免得說不清。

溝通是門複雜的藝術,最基本是聽明白、說清楚。

管理好自己的暴脾氣

圖1:怎樣才算得上合格的程式設計師

作為 一個程式設計師,要被PM懟、要被互動懟、要被QA懟,再變態的需求都可能有,QA給你提的BUG可能也不屬於你。而且,還有豬一樣的隊友(自己在別人眼裡何嘗不是這樣呢)和下屬。不管誰是誰非,發脾氣、吵架都一點用沒有,吵完還是得解決問題。calm down,有怒火也得等個幾秒再發作,也許這幾秒理智思考一下,就能解決問題。

負責任

能力(技術能力)與責任心誰更重要呢,都重要。如果一個新人有培養的潛力,那麼責任心就更重要。兩個人,第一個技術能力很強,但責任心很差,對專案的事情也不上心;第二個能力差些,但責任心強,是自己的問題一定負責到底,即使自己不能解決也能主動詢求幫助。我覺得前者對專案的危害更大,特別是專案緊要時期,因為能力強的人一般負責的是比較複雜、困難的功能,別人上手也需要時間,這個時候如果摞擔子,bug也不修,那麼就很為難了。

不負責任的典型表現就是扯皮、甩鍋:這不是我的bug、不關我的事。有協作的地方更容易出現問題,比如前端與後端、各個部門之間。如果不清楚到時是誰的問題,不妨主動一點,幫助排查。

不要總是說不會

作為程式設計師,總有一些工作是以前沒有做過的,也許來自產品人員的需求,也許來自專案自發的優化。我見過一些程式設計師,在面臨未知的問題、挑戰時,總是習慣於說:不會、沒辦法、不可能,這樣的程式設計師就算不上合格的程式設計師。事實上,這樣的程式設計師是給自己過早地留好退路,事實上問題可能並沒有想象得那麼困難,也許經過一番探索就能解決。如果習慣於對未知說不,那麼在別人看來就是能力不行,影響個人形象與聲譽,而且總是待在自己的舒適區也不利於自我成長。

當然,也不是說要盲目自信,急於拍胸脯保證一定能解決,這樣往往是坑自己。

所以,面對新的需求,謹慎對待,既不輕易否決也不隨意承諾,而是再理清需要先去研究一下,評估是否能完成,需要的資源與時間。

暫時就想到這麼多,當然我也還不達標,比如容易控制不住自己的怒火,與君共勉吧

相關文章