'如何一名合格的程序員，成為永不被拋棄的“IT 民工”？'

最近同一部門另一個項目組的一位程序員被"主動離職"了，雖然我未曾與這個程序員共事過，但是聽過一兩次他的內部分享，感覺技術還是挺厲害的。

後來與一個消息靈通的同事聊天，才知道真正的原因是老大覺得 A 難以溝通，搞得其他程序、QA 都怨聲載道。

工作這些年，身邊的好多同事來了又走了，主動或被動，這不禁讓我思考什麼樣的程序員算得上合格的程序員。

雖然大家都自稱"碼農"、"IT 民工"，但我相信，這僅僅是自嘲或者自黑，大多數程序員應該還是認可自己這個職業的。

當然，我算不上一個優秀的程序員，因為我都不曾在開源社區貢獻過代碼、也不精通白板算法、對技術也不狂熱、不 geek。

我的目標是做一個合格的程序員：把本職工作做好，對得起自己的薪水，平衡生活與工作，996 什麼的我是難以接受的。

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

紮實的基礎

計算機領域是一個快速更新換代的領域，每隔一段時間都會有新的語言、框架、思想產生，追隨每一個新技術很累。

但仔細想想，事實上並沒有那麼多新東西。很多新東西只不過是已有技術的封裝、或者借鑑的其他領域的技術。

比如緩存數據庫 Redis、Memcached，其基本思想不就是操作系統中的緩存嗎；分佈式存儲中的分片與複製集，不就是文件系統中 RAID 的擴展嗎？

還有 Google 的 MapReduce 框架，不就是來源於函數式編程語言的 Map Reduce 嗎？掌握好計算機基礎知識，能夠更本質的看待新技術。

善用工具

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

開發中會用到大量的工具，不管是編輯器、調試工具還是監控工具，大家都喜歡爭論哪個 IDE 更好。

然而，這並沒有多大意義，關鍵在於能夠熟練的使用自己喜歡的工具，掌握各種快捷鍵，高度自定義，這樣能夠大大提高工作效率。

而且對於日常中重複的操作，最好腳本自動化，這裡推薦一下 Python，寫小工具還是很快的。

另外，強調程序員必備的兩個工具，那就是瀏覽器和 VPN。後者大家都懂的，不多說，主要是有了後者才能發揮瀏覽器的威力。

瀏覽器大家天天都在用，但是如何高效的使用，比如在指定網站搜索、通過標題、url 過濾、選擇合適的關鍵字還是值得研究一下。

對於程序員，要使用好瀏覽器，那還得具備下一個能力：英語。

過得去的英語

不得不承認，在軟件創新領域，國內還是落後於國外的，新的技術、一手的資料都是英文的。

當新技術被廣泛應用之前，我們在百度搜到翻譯要麼是 machine translated，要麼錯誤百出。

看翻譯的最大問題取決於翻譯者本身的水平，即使翻譯水平都很高，但同一個單詞往往有不同的翻譯，導致看文章的時候會有困惑，最好還是直接看英文原文。

大多數原文，除去專業詞彙、還是比較好理解的，而且，我發現很多牛逼的項目，都有非常通俗易懂的文檔。

良好的編碼習慣

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

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

保持學習

程序員這個職業，相比其他職業，可能還是要年輕許多。特別是在國內，最老的一批程序員好多都轉管理了，再過 10 年 20 年，我們會怎麼樣呢，沒人知道。

前段時間華為 35 歲程序員被離職的事情，還有最近傳遍朋友圈的中興 42 歲程序員墜樓身亡的事（痛心！中興42歲程序員跳樓身亡，是什麼把他逼上了絕路？），都給我們敲響了警鐘，悲哀之餘，只有盡力學習了，拼不過體力就拼能力與經驗吧。

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

獨立思考

合格的程序員解決的是問題，而不是實現某個解決方案。產品經理（特別是知道一點技術的產品經理）的某個需求可能只是某個問題的解決方案，他認為這個方法可以解決他的問題，於是把解決方案當成了需求，而不是真正的問題。

程序員應該主動溝通，多問幾個為什麼，瞭解真正的問題，也許能有更好的解決方案。

之前就有這麼個例子，給到的需求：為每一個用戶（用戶有唯一的 id 標示）生成一個唯一的邀請碼，同時也要為未來一段時間可能增加的用戶預生成邀請碼，保存到數據庫。

而真正的需求是老用戶分享自己的邀請碼，如果新用戶使用了該邀請碼，則老用戶獲得相應獎勵。我提出的方案很簡單，直接用戶的唯一 id 生成可逆的邀請碼，這樣就根本無需數據庫存儲。

產品經理經常改需求這是程序員最頭疼的事情，作為程序員應該也站在 PM 的角度思考，幫助 PM 分析出本質的需求，這也許可以減少需求的變更。

當然，前提是得幹一行愛一行，需要對業務有一定的瞭解。

先思考後行動

寫代碼的時候先想清楚了再下筆，而不是先寫出一堆代碼，然後在開始修 Bug。

修改 Bug 的時候，多看看上下文，搞明白為什麼出 Bug，修改這個 Bug 可能帶來的影響，然後再修改。

反面教材有兩種：

隨便改改就把代碼改好了，但自己心裡並不清楚為什麼這樣修改就修好了，撞運氣，也許還有其他同樣的 Bug 也發現不了。

• 頭痛醫頭腳痛醫腳，不仔細評估修改的影響，這樣往往會引入新的問題。

程序員成長的一個辦法就是修 Bug，修別人用不了的 Bug，但前提是搞清楚 Bug 的緣由，這樣才能避免類似的錯誤，有所收穫。

順暢溝通

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

現在的軟件開發，已經不再是單打獨鬥的年代，大多數的軟件、產品都需要多人、多部門的協作。而交流、溝通是非常耗時耗力的。

溝通之前，先想好目標，組織好語言，儘量不要發散、不要跑題，對事不對人。對於重要的事情，保留溝通記錄，最好有郵件，免得說不清。

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

管理好自己的暴脾氣

作為一個程序員，要被 PM 懟、要被交互懟、要被 QA 懟，再變態的需求都可能有，QA 給你提的 Bug 可能也不屬於你。而且，還有豬一樣的隊友（自己在別人眼裡何嘗不是這樣呢）和下屬。

不管誰是誰非，發脾氣、吵架都一點用沒有，吵完還是得解決問題。calm down，有怒火也得等個幾秒再發作，也許這幾秒理智思考一下，就能解決問題。

負責任

能力（技術能力）與責任心誰更重要呢，都重要。如果一個新人有培養的潛力，那麼責任心就更重要。

兩個人，第一個技術能力很強，但責任心很差，對項目的事情也不上心；第二個能力差些，但責任心強，是自己的問題一定負責到底，即使自己不能解決也能主動尋求幫助。

我覺得前者對項目的危害更大，特別是項目緊要時期，因為能力強的人一般負責的是比較複雜、困難的功能，別人上手也需要時間，這個時候如果摞擔子，Bug 也不修，那麼就很為難了。

不負責任的典型表現就是扯皮、甩鍋：這不是我的 Bug、不關我的事。

有協作的地方更容易出現問題，比如前端與後端、各個部門之間。如果不清楚到底是誰的問題，不妨主動一點，幫助排查。

不要總是說不會

作為程序員，總有一些工作是以前沒有做過的，也許來自產品人員的需求，也許來自項目自發的優化。

我見過一些程序員，在面臨未知的問題、挑戰時，總是習慣於說：不會、沒辦法、不可能，這樣的程序員就算不上合格的程序員。

事實上，這樣的程序員是給自己過早地留好退路，事實上問題可能並沒有想象的那麼困難，也許經過一番探索就能解決。

如果習慣於對未知說不，那麼在別人看來就是能力不行，影響個人形象與聲譽，而且總是待在自己的舒適區也不利於自我成長。

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

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

在不久的將來，多智時代一定會徹底走入我們的生活，多智時代該平臺，專注於人工智能、大數據、雲計算和物聯網的入門學習和科譜資訊，讓我們一起攜手，引領人工智能的未來