2018，程序員做好這11件事，必拿高薪！
翻開日歷，不知不覺間，2017 年的余額已不足 2%，這一年又猝不及防的步入了尾聲。今年過得怎么樣？你的目標(biāo)還差了多少？
在這一年僅剩下的小尾巴里，咱們程序員可以好好總結(jié)一下將要逝去的 2017，規(guī)劃即將到來的 2018。下面先來看看程序員工作中的 17 種狀態(tài)，你中槍了嗎？
程序員的 17 種狀態(tài)，扎心了
1.明明是個小 Bug 但就是死活修不好...
2.作為一個碼工我意外走入了一個充滿 PM 的會議室...
3.偶然間看到了自己多年前寫的代碼
4.調(diào)試過多線程的都會懂！
5.這就是你們追捧的結(jié)對編程
6.Git merge
7.當(dāng)他們問我是否需要兼容 IE 的時候
8.當(dāng)我以為已捕獲了所有可能的異常的時候
9.你永遠 try...catch 不到所有的可能性！
10.數(shù)據(jù)庫的 Delete 語句忘了，使用限定詞 Where...
11.當(dāng)我試圖把一個 Bug 踢給別人的時候....
12.好像真的沒人發(fā)現(xiàn)我產(chǎn)品里的 Bug...
13.第一次嘗試退出vim
14.當(dāng)我試圖清理幾行所謂的舊代碼的時候...
15.當(dāng)我按照 Stack Overflow 上的回帖，解決問題的時候......
16.編譯錯誤：括號不匹配
17.作為一個程序員，最后是拷問靈魂的時刻了：
“你熱愛自己的工作嗎？”
“...愛！”
“再給你一次機會”
“...唉...”
人艱不拆，求別說。
即將到來的 2018，如何做個合格的程序員？
最近同一部門另一個項目組的一位程序員被"主動離職"了，雖然我未曾與這個程序員共事過，但是聽過一兩次他的內(nèi)部分享，感覺技術(shù)還是挺厲害的。
后來與一個消息靈通的同事聊天，才知道真正的原因是老大覺得 A 難以溝通，搞得其他程序、QA 都怨聲載道。
工作這些年，身邊的好多同事來了又走了，主動或被動，這不禁讓我思考什么樣的程序員算得上合格的程序員。
雖然大家都自稱"碼農(nóng)"、"IT 民工"，但我相信，這僅僅是自嘲或者自黑，大多數(shù)程序員應(yīng)該還是認(rèn)可自己這個職業(yè)的。
當(dāng)然，我算不上一個優(yōu)秀的程序員，因為我都不曾在開源社區(qū)貢獻過代碼、也不精通白板算法、對技術(shù)也不狂熱、不 geek。
我的目標(biāo)是做一個合格的程序員：把本職工作做好，對得起自己的薪水，平衡生活與工作，996 什么的我是難以接受的。
對于程序員而言，技術(shù)過關(guān)當(dāng)然是非常重要的，這是硬實力。然而只會技術(shù)也是不行的，畢竟大多數(shù)的程序員還是要與人打交道，軟實力也是不可或缺的。怎樣才能算合格，我認(rèn)為有以下幾點：
扎實的基礎(chǔ)
計算機領(lǐng)域是一個快速更新?lián)Q代的領(lǐng)域，每隔一段時間都會有新的語言、框架、思想產(chǎn)生，追隨每一個新技術(shù)很累。
但仔細(xì)想想，事實上并沒有那么多新東西。很多新東西只不過是已有技術(shù)的封裝、或者借鑒的其他領(lǐng)域的技術(shù)。
比如緩存數(shù)據(jù)庫 Redis、Memcached，其基本思想不就是操作系統(tǒng)中的緩存嗎；分布式存儲中的分片與復(fù)制集，不就是文件系統(tǒng)中 RAID 的擴展嗎？
還有 Google 的 MapReduce 框架，不就是來源于函數(shù)式編程語言的 Map Reduce 嗎？掌握好計算機基礎(chǔ)知識，能夠更本質(zhì)的看待新技術(shù)。
善用工具
磨刀不誤砍柴工，打造好自己的工具集非常重要。
開發(fā)中會用到大量的工具，不管是編輯器、調(diào)試工具還是監(jiān)控工具，大家都喜歡爭論哪個 IDE 更好。
然而，這并沒有多大意義，關(guān)鍵在于能夠熟練的使用自己喜歡的工具，掌握各種快捷鍵，高度自定義，這樣能夠大大提高工作效率。
而且對于日常中重復(fù)的操作，最好腳本自動化，這里推薦一下 Python，寫小工具還是很快的。
另外，強調(diào)程序員必備的兩個工具，那就是瀏覽器和 VPN。后者大家都懂的，不多說，主要是有了后者才能發(fā)揮瀏覽器的威力。
瀏覽器大家天天都在用，但是如何高效的使用，比如在指定網(wǎng)站搜索、通過標(biāo)題、url 過濾、選擇合適的關(guān)鍵字還是值得研究一下。
對于程序員，要使用好瀏覽器，那還得具備下一個能力：英語。
過得去的英語
不得不承認(rèn)，在軟件創(chuàng)新領(lǐng)域，國內(nèi)還是落后于國外的，新的技術(shù)、一手的資料都是英文的。
當(dāng)新技術(shù)被廣泛應(yīng)用之前，我們在百度搜到翻譯要么是 machine translated，要么錯誤百出。
看翻譯的最大問題取決于翻譯者本身的水平，即使翻譯水平都很高，但同一個單詞往往有不同的翻譯，導(dǎo)致看文章的時候會有困惑，最好還是直接看英文原文。
大多數(shù)原文，除去專業(yè)詞匯、還是比較好理解的，而且，我發(fā)現(xiàn)很多牛逼的項目，都有非常通俗易懂的文檔。
良好的編碼習(xí)慣
代碼是寫給機器執(zhí)行的，同時也是給人閱讀與維護的。維護者可能是別人、也可能是幾個月后的樣子。良好的代碼規(guī)范，必要的、清晰的注釋可以讓自己少被問候祖宗十八代。
對于代碼風(fēng)格，網(wǎng)上爭議也很多，最重要的是保持項目內(nèi)的統(tǒng)一。做為技術(shù)負(fù)責(zé)人，一定要在項目開啟之初就定好規(guī)范，當(dāng)大量代碼被堆出來之后就很難統(tǒng)一了，然后做好新人的 review。
保持學(xué)習(xí)
程序員這個職業(yè)，相比其他職業(yè)，可能還是要年輕許多。特別是在國內(nèi)，最老的一批程序員好多都轉(zhuǎn)管理了，再過 10 年 20 年，我們會怎么樣呢，沒人知道。
前段時間華為 35 歲程序員被離職的事情，還有最近傳遍朋友圈的中興 42 歲程序員墜樓身亡的事（痛心！中興42歲程序員跳樓身亡，是什么把他逼上了絕路？），都給我們敲響了警鐘，悲哀之余，只有盡力學(xué)習(xí)了，拼不過體力就拼能力與經(jīng)驗吧。
學(xué)習(xí)這個事情說起來就復(fù)雜了，我覺得兩點很重要：基礎(chǔ)、學(xué)以致用。
獨立思考
合格的程序員解決的是問題，而不是實現(xiàn)某個解決方案。產(chǎn)品經(jīng)理（特別是知道一點技術(shù)的產(chǎn)品經(jīng)理）的某個需求可能只是某個問題的解決方案，他認(rèn)為這個方法可以解決他的問題，于是把解決方案當(dāng)成了需求，而不是真正的問題。
程序員應(yīng)該主動溝通，多問幾個為什么，了解真正的問題，也許能有更好的解決方案。
之前就有這么個例子，給到的需求：為每一個用戶（用戶有唯一的 id 標(biāo)示）生成一個唯一的邀請碼，同時也要為未來一段時間可能增加的用戶預(yù)生成邀請碼，保存到數(shù)據(jù)庫。
而真正的需求是老用戶分享自己的邀請碼，如果新用戶使用了該邀請碼，則老用戶獲得相應(yīng)獎勵。我提出的方案很簡單，直接用戶的唯一 id 生成可逆的邀請碼，這樣就根本無需數(shù)據(jù)庫存儲。
產(chǎn)品經(jīng)理經(jīng)常改需求這是程序員最頭疼的事情，作為程序員應(yīng)該也站在 PM 的角度思考，幫助 PM 分析出本質(zhì)的需求，這也許可以減少需求的變更。
當(dāng)然，前提是得干一行愛一行，需要對業(yè)務(wù)有一定的了解。
先思考后行動
寫代碼的時候先想清楚了再下筆，而不是先寫出一堆代碼，然后在開始修 Bug。
修改 Bug 的時候，多看看上下文，搞明白為什么出 Bug，修改這個 Bug 可能帶來的影響，然后再修改。
反面教材有兩種：
- 隨便改改就把代碼改好了，但自己心里并不清楚為什么這樣修改就修好了，撞運氣，也許還有其他同樣的 Bug 也發(fā)現(xiàn)不了。
- 頭痛醫(yī)頭腳痛醫(yī)腳，不仔細(xì)評估修改的影響，這樣往往會引入新的問題。
程序員成長的一個辦法就是修 Bug，修別人用不了的 Bug，但前提是搞清楚 Bug 的緣由，這樣才能避免類似的錯誤，有所收獲。
順暢溝通
順暢溝通不是巧如舌簧、也不是忽悠達人，需要的只是耐心傾聽，然后清晰表達自己的意見。
現(xiàn)在的軟件開發(fā)，已經(jīng)不再是單打獨斗的年代，大多數(shù)的軟件、產(chǎn)品都需要多人、多部門的協(xié)作。而交流、溝通是非常耗時耗力的。
溝通之前，先想好目標(biāo)，組織好語言，盡量不要發(fā)散、不要跑題，對事不對人。對于重要的事情，保留溝通記錄，最好有郵件，免得說不清。
溝通是門復(fù)雜的藝術(shù)，最基本是聽明白、說清楚。
管理好自己的暴脾氣
作為一個程序員，要被 PM 懟、要被交互懟、要被 QA 懟，再變態(tài)的需求都可能有，QA 給你提的 Bug 可能也不屬于你。而且，還有豬一樣的隊友（自己在別人眼里何嘗不是這樣呢）和下屬。
不管誰是誰非，發(fā)脾氣、吵架都一點用沒有，吵完還是得解決問題。calm down，有怒火也得等個幾秒再發(fā)作，也許這幾秒理智思考一下，就能解決問題。
負(fù)責(zé)任
能力（技術(shù)能力）與責(zé)任心誰更重要呢，都重要。如果一個新人有培養(yǎng)的潛力，那么責(zé)任心就更重要。
兩個人，第一個技術(shù)能力很強，但責(zé)任心很差，對項目的事情也不上心；第二個能力差些，但責(zé)任心強，是自己的問題一定負(fù)責(zé)到底，即使自己不能解決也能主動尋求幫助。
我覺得前者對項目的危害更大，特別是項目緊要時期，因為能力強的人一般負(fù)責(zé)的是比較復(fù)雜、困難的功能，別人上手也需要時間，這個時候如果摞擔(dān)子，Bug 也不修，那么就很為難了。
不負(fù)責(zé)任的典型表現(xiàn)就是扯皮、甩鍋：這不是我的 Bug、不關(guān)我的事。
有協(xié)作的地方更容易出現(xiàn)問題，比如前端與后端、各個部門之間。如果不清楚到底是誰的問題，不妨主動一點，幫助排查。
不要總是說不會
作為程序員，總有一些工作是以前沒有做過的，也許來自產(chǎn)品人員的需求，也許來自項目自發(fā)的優(yōu)化。
我見過一些程序員，在面臨未知的問題、挑戰(zhàn)時，總是習(xí)慣于說：不會、沒辦法、不可能，這樣的程序員就算不上合格的程序員。
事實上，這樣的程序員是給自己過早地留好退路，事實上問題可能并沒有想象的那么困難，也許經(jīng)過一番探索就能解決。
如果習(xí)慣于對未知說不，那么在別人看來就是能力不行，影響個人形象與聲譽，而且總是待在自己的舒適區(qū)也不利于自我成長。
當(dāng)然，也不是說要盲目自信，急于拍胸脯保證一定能解決，這樣往往是坑自己。
所以，面對新的需求，謹(jǐn)慎對待，既不輕易否決也不隨意承諾，而是再理清需求先去研究一下，評估是否能完成，需要的資源與時間。
暫時就想到這么多，與君共勉。Relax！準(zhǔn)備好迎接你的 2018 吧。
