正文

最近同一部門另一個(gè)項(xiàng)目組的一位程序員被“主動(dòng)離職”了，雖然我未曾與這個(gè)程序員共事過，但是聽過一兩次他的內(nèi)部分享，感覺技術(shù)還是挺厲害的。后來與一個(gè)消息靈通的同事聊天，才知道真正的原因是老大覺得A難以溝通，搞得其他程序、QA都怨聲載道。工作這些年，身邊的好多同事來了又走了，主動(dòng)或被動(dòng)，這不禁讓我思考什么樣的程序員算得上合格的程序員。

雖然大家都自稱“碼農(nóng)”、“IT民工”，但我相信，這僅僅是自嘲或者自黑，大多數(shù)程序員應(yīng)該還是認(rèn)可自己的這個(gè)職業(yè)的，當(dāng)然，我算不上一個(gè)優(yōu)秀的程序員，因?yàn)槲叶疾辉陂_源社區(qū)貢獻(xiàn)過代碼、也不精通白板算法、對(duì)技術(shù)也不狂熱、不geek。我的目標(biāo)是做一個(gè)合格的程序員：把本職工作做好，對(duì)得起自己的薪水，在生活與工作平衡，996什么的我是難以接受的。

對(duì)于程序員而言，技術(shù)過關(guān)當(dāng)然是非常重要的，這是硬實(shí)力。然而只會(huì)技術(shù)也是不行的，畢竟大多數(shù)的程序員還是要與人打交道，軟實(shí)力也是不可或缺的。怎樣才能算合格，我認(rèn)為有以下幾點(diǎn)：

扎實(shí)的基礎(chǔ)

計(jì)算機(jī)領(lǐng)域是一個(gè)快速更新?lián)Q代的領(lǐng)域，每隔一段時(shí)間都會(huì)有新的語言、框架、思想產(chǎn)生，追隨每一個(gè)新技術(shù)很累。但仔細(xì)想想，事實(shí)上并沒有那么多新東西。很多新東西只不過是已有技術(shù)的封裝、或者借鑒的其他領(lǐng)域的技術(shù)。比如緩存數(shù)據(jù)庫(kù)redis、memcached，其基本思想不就是操作系統(tǒng)中的緩存嗎；分布式存儲(chǔ)中的分片與復(fù)制集，不就是文件系統(tǒng)中RAID的擴(kuò)展嗎；還有Google的MapReduce框架，不就是來源于函數(shù)式編程語言的map reduce嗎。掌握好計(jì)算機(jī)基礎(chǔ)知識(shí)，能夠更本質(zhì)的看待新技術(shù)。

善用工具

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

開發(fā)中會(huì)用到大量的工具，不管是編輯器、調(diào)試工具還是監(jiān)控工具。大家都喜歡爭(zhēng)論哪個(gè)IDE更好，然而這并沒有多大意義，關(guān)鍵在于能夠熟練的使用自己喜歡的工具，掌握各種快捷鍵，高度自定義，這樣能夠大大提高工作效率。而且對(duì)于日常中重復(fù)的操作，最好腳本自動(dòng)化，這里推薦以下python，寫小工具還是很快的。

另外，強(qiáng)調(diào)程序員必備的兩個(gè)工具，那就是瀏覽器和VPN。后者大家都懂的，不多說，主要是有了后者才能發(fā)揮瀏覽器的威力。瀏覽器大家天天都在用，但是如何高效的使用，比如在指定網(wǎng)站搜索、通過標(biāo)題、url過濾、選擇合適的關(guān)鍵字 還是值得研究一下，對(duì)于程序員，要使用好瀏覽器，那還得具備下一個(gè)能力：英語

過得去的英語

不得不承認(rèn)，在軟件創(chuàng)新領(lǐng)域，國(guó)內(nèi)還是落后于國(guó)外的，新的技術(shù)、一手的資料都是英文的。當(dāng)新技術(shù)被廣泛應(yīng)用之前，我們?cè)诎俣人训椒g要么是machine translated，要么錯(cuò)誤百出。看翻譯的最大問題取決于翻譯者本身的水平，即使翻譯水平都很高，但同一個(gè)單次往往有不同的翻譯，導(dǎo)致看文章的時(shí)候會(huì)有困惑，最好還是直接看英文原文。大多數(shù)原文，除去專業(yè)詞匯、還是比較好理解的，而且，我發(fā)現(xiàn)很多牛逼的項(xiàng)目，都有非常通俗易懂的文檔。

良好的編碼習(xí)慣

代碼是寫給機(jī)器執(zhí)行的，同時(shí)也是給人閱讀與維護(hù)的。維護(hù)者可能是別人、也可能是幾個(gè)月后的樣子。良好的代碼規(guī)范，必要的、清晰的注釋可以讓自己少被問候祖宗十八代。

對(duì)于代碼風(fēng)格，網(wǎng)上爭(zhēng)議也很多，最重要的是保持項(xiàng)目?jī)?nèi)的統(tǒng)一。做為技術(shù)負(fù)責(zé)人，一定要在項(xiàng)目開啟之初就頂號(hào)規(guī)范，當(dāng)大量代碼被堆出來之后就很難統(tǒng)一了，然后做好新人的review。

保持學(xué)習(xí)

程序員這個(gè)職業(yè)，相比其他職業(yè)，可能還是要年輕許多。特別是在國(guó)內(nèi)，最老的一批程序員好多都轉(zhuǎn)管理了，再過10年20年，我們會(huì)怎么樣呢，沒人知道。前段時(shí)間華為35歲程序員被離職的事情，給我們敲響了警鐘，悲哀之余，只有盡力學(xué)習(xí)了，拼不過體力就拼能力與經(jīng)驗(yàn)吧

學(xué)習(xí)這個(gè)事情說起來就復(fù)雜了，我覺得兩點(diǎn)很重要：基礎(chǔ)、學(xué)以致用。

獨(dú)立思考

合格的程序員解決的是問題，而不是實(shí)現(xiàn)某個(gè)解決方案。產(chǎn)品經(jīng)理（特別是知道一點(diǎn)技術(shù)的產(chǎn)品經(jīng)理）的某個(gè)需求可能只是某個(gè)問題的解決方案，他認(rèn)為這個(gè)方法可以解決他的問題，于是把解決方案當(dāng)成了需求，而不是真正的問題。程序員應(yīng)該主動(dòng)溝通，多問幾個(gè)為什么，了解真正的問題，也許能有更好的解決方案。

之前就有這么個(gè)例子，給到的需求：為每一個(gè)用戶（用戶有唯一的id標(biāo)示）生成一個(gè)唯一的邀請(qǐng)碼，同時(shí)也要為未來一段時(shí)間可能增加的用戶預(yù)生成邀請(qǐng)碼，保存到數(shù)據(jù)庫(kù)。而真正的需求是老用戶分享自己的邀請(qǐng)碼，如果新用戶使用了該邀請(qǐng)碼，則老用戶獲得相應(yīng)獎(jiǎng)勵(lì)。而我提出的方案很簡(jiǎn)單，直接用戶的唯一id生成可逆的邀請(qǐng)碼，這樣就根本無無需數(shù)據(jù)庫(kù)存儲(chǔ)。

產(chǎn)品經(jīng)理經(jīng)常改需求這是程序員最頭疼的事情，作為程序員應(yīng)該也站在PM的角度思考，幫助PM分析出本質(zhì)的需求，這也許可以減少需求的變更。當(dāng)然，前提是得干一行愛一行，需要對(duì)業(yè)務(wù)有一定的了解。

先思考后行動(dòng)

寫代碼的時(shí)候先想清楚了再下筆，而不是先寫出一堆代碼，然后在開始修bug。

休bug的時(shí)候，多看看上下文，搞明白為什么出bug，修改這個(gè)bug可能帶來的影響，然后再修改。反面教材有兩種：第一種隨便改改就把代碼改好了，但自己心里并不清楚為什么這樣修改就修好了，撞運(yùn)氣，也許還有其他同樣的bug也發(fā)現(xiàn)不了。另一種就是，頭痛醫(yī)頭腳痛醫(yī)腳，不仔細(xì)評(píng)估修改的影響，這樣往往會(huì)引入新的問題。

程序員成長(zhǎng)的一個(gè)辦法就是修bug，修別人用不了的bug，但前提是搞清楚bug的緣由，這樣才能避免類似的錯(cuò)誤，有所收獲。

順暢溝通

不是巧如舌簧、也不是忽悠達(dá)人。需要的只是耐心傾聽，然后清晰表達(dá)自己的意見。

現(xiàn)在的軟件開發(fā)，已經(jīng)不再是單打獨(dú)斗的年代，大多數(shù)的軟件、產(chǎn)品都需要多人、多部門的協(xié)作。而交流、溝通是非常耗時(shí)耗力的。溝通之前，先想好目標(biāo)，組織好語言，盡量不要發(fā)散、不要跑題，對(duì)事不對(duì)人。對(duì)于重要的事情，保留溝通記錄，最好有郵件，免得說不清。

溝通是門復(fù)雜的藝術(shù)，最基本是聽明白、說清楚。

管理好自己的暴脾氣

作為 一個(gè)程序員，要被PM懟、要被交互懟、要被QA懟，再變態(tài)的需求都可能有，QA給你提的BUG可能也不屬于你。而且，還有豬一樣的隊(duì)友（自己在別人眼里何嘗不是這樣呢）和下屬。不管誰是誰非，發(fā)脾氣、吵架都一點(diǎn)用沒有，吵完還是得解決問題。calm down，有怒火也得等個(gè)幾秒再發(fā)作，也許這幾秒理智思考一下，就能解決問題。

負(fù)責(zé)任

能力（技術(shù)能力）與責(zé)任心誰更重要呢，都重要。如果一個(gè)新人有培養(yǎng)的潛力，那么責(zé)任心就更重要。兩個(gè)人，第一個(gè)技術(shù)能力很強(qiáng)，但責(zé)任心很差，對(duì)項(xiàng)目的事情也不上心；第二個(gè)能力差些，但責(zé)任心強(qiáng)，是自己的問題一定負(fù)責(zé)到底，即使自己不能解決也能主動(dòng)詢求幫助。我覺得前者對(duì)項(xiàng)目的危害更大，特別是項(xiàng)目緊要時(shí)期，因?yàn)槟芰?qiáng)的人一般負(fù)責(zé)的是比較復(fù)雜、困難的功能，別人上手也需要時(shí)間，這個(gè)時(shí)候如果摞擔(dān)子，bug也不修，那么就很為難了。

不負(fù)責(zé)任的典型表現(xiàn)就是扯皮、甩鍋：這不是我的bug、不關(guān)我的事。有協(xié)作的地方更容易出現(xiàn)問題，比如前端與后端、各個(gè)部門之間。如果不清楚到時(shí)是誰的問題，不妨主動(dòng)一點(diǎn)，幫助排查。

不要總是說不會(huì)

作為程序員，總有一些工作是以前沒有做過的，也許來自產(chǎn)品人員的需求，也許來自項(xiàng)目自發(fā)的優(yōu)化。我見過一些程序員，在面臨未知的問題、挑戰(zhàn)時(shí)，總是習(xí)慣于說：不會(huì)、沒辦法、不可能，這樣的程序員就算不上合格的程序員。事實(shí)上，這樣的程序員是給自己過早地留好退路，事實(shí)上問題可能并沒有想象得那么困難，也許經(jīng)過一番探索就能解決。如果習(xí)慣于對(duì)未知說不，那么在別人看來就是能力不行，影響個(gè)人形象與聲譽(yù)，而且總是待在自己的舒適區(qū)也不利于自我成長(zhǎng)。

當(dāng)然，也不是說要盲目自信，急于拍胸脯保證一定能解決，這樣往往是坑自己。

所以，面對(duì)新的需求，謹(jǐn)慎對(duì)待，既不輕易否決也不隨意承諾，而是再理清需要先去研究一下，評(píng)估是否能完成，需要的資源與時(shí)間。