周五，扯扯閑篇。木(mù)魚網絡作(zuò)為(wèi)一家網絡公(gōng)司，技(jì )術肯定是必不可(kě)少的。工(gōng)作(zuò)過程中(zhōng)，多(duō)多(duō)少少的都有(yǒu)些經驗和教訓。木(mù)魚網絡在做項目中(zhōng)，程序員肯定是必不可(kě)少的，木(mù)魚網絡每年服務(wù)那麽多(duō)客戶，雖不敢說百分(fēn)百滿意，但也算是雙方合作(zuò)愉快。其中(zhōng)，程序員的功勞不可(kě)否認。

項目過程中(zhōng)，程序員如何跟項目管理(lǐ)溝通、産(chǎn)品經理(lǐ)如何跟程序員交流，這都是“技(jì )術活”

今兒就跟大家扯扯程序員如何才能(néng)跟上節奏、怎麽在公(gōng)司地位不可(kě)動搖的“秘籍”——程序員的核心競争力在哪

尤其是自學(xué)能(néng)力，你啥時看到那些有(yǒu)名(míng)的程序高手在論壇上問“學(xué)習 XX 該看什麽書，如何快速學(xué)習 XXX，學(xué)習 XXX 有(yǒu)什麽代碼推薦”之類的問題，他(tā)們想學(xué)什麽很(hěn)快就能(néng)自己找到相關資料。這個行業發展太快，技(jì )術淘汰的速度也很(hěn)快，3 年不學(xué)新(xīn)東西就可(kě)能(néng)落伍了。

小(xiǎo)編就經常被吐槽，讓小(xiǎo)編少扯淡，多(duō)看書。

都是看書看資料，當别人還在糾結看什麽書，還在糾結書裏的字句是什麽意思的時候，有(yǒu)些人的幾百上千行代碼都已經能(néng)運行了。

看完木(mù)魚網絡程序員一天的工(gōng)作(zuò)，小(xiǎo)編感覺程序員的世界我果然不懂。

做程序員興趣固然重要，寫自己喜歡的代碼那是相當愉快的事情，但是程序開發中(zhōng)無論如何還有(yǒu)大量乏味無趣的事情，要能(néng)堅持，咬牙把這些做完。

如果你身邊有(yǒu)程序員朋友或同事，你會相信，程序員真的可(kě)以一坐(zuò)一天，一天不說話。

能(néng)在大庭廣衆下，把自己的想法邏輯清晰流暢地講出來，讓人聽懂。

項目合作(zuò)中(zhōng)，程序員的表達方式真的很(hěn)重要，相信我，小(xiǎo)編用(yòng)血的淚水傾訴！！

技(jì )術不重要，有(yǒu)了以上幾種能(néng)力，市場上需要什麽技(jì )術，很(hěn)快就能(néng)掌握了。

就是小(xiǎo)編自己都知道，三天不上網，已經跟朋友沒有(yǒu)共同話題了。

最後再說說工(gōng)資的事，記住兩句話：

~~~~我們公(gōng)司的程序員看完後敢辭職小(xiǎo)編我就跟你們拼了

我們都知道學(xué)習能(néng)力很(hěn)重要，那麽學(xué)習能(néng)力從何而來，除了去看書上課這種，如何在實踐工(gōng)作(zuò)中(zhōng)學(xué)習成長(cháng)？

什麽是能(néng)力？ 對待問題的态度，以及處理(lǐ)問題的思路和方法。

你服務(wù)器偶爾出 501 錯誤，也許比例不高，很(hěn)多(duō)程序員，沒錯，是很(hěn)多(duō)，假裝(zhuāng)看不見，不在乎，或者歸咎于人品問題。 這就是态度問題。

再往後，負載高了或者其他(tā)什麽原因，突然頻繁出現 501 錯誤，不去追尋深入的原因，而是找各種借口， 什麽 IDC 服務(wù)商(shāng)不好，服務(wù)器品牌不好，操作(zuò)系統不好，數據庫不好，CDN 不好，網絡狀況不好，web server 不好，甚至，直接對 Boss 說我們被 DDOS 啦！

這就是态度，觸目驚心，如果能(néng)對問題有(yǒu)敏感性，能(néng)知道對任何小(xiǎo)的，輕微的問題有(yǒu)足夠的敏銳度，你就有(yǒu)了一個快速成長(cháng)的基礎。對問題的敏銳度是非常重要的。很(hěn)多(duō)性能(néng)或程序邏輯上非緻命的 bug，在不夠敏銳的時候是發現不了的，但是一旦進入特殊場景就會驟然爆發，你多(duō)一點敏銳度，就會減少這種危機的風險。

有(yǒu)人對自己的解決方案信心滿滿，認為(wèi)萬無一失，但有(yǒu)的人就會多(duō)留一條後路；就好比你說我服務(wù)器要不要做安(ān)全加固，肯定要做對不對，要做到盡可(kě)能(néng)嚴謹和周全，但是你數據庫保存密碼的時候是不是還要加密?而且要随機 salt，不就是防止萬一依然有(yǒu)漏洞被人拿(ná)庫怎麽辦(bàn)麽。程序也一樣，以前寫的一些服務(wù)端守護進程，有(yǒu) bug，會莫名(míng)其妙的終止，這個 bug 當然要定位，要修複，但是同時，寫一個 cron 檢查這個守護進程狀态，一旦遇到終止給予自動恢複，這就是第二手準備，即便你多(duō)麽不希望他(tā)執行，這個準備還是要做的。對問題 做兩手甚至三手準備，也是優秀程序員，架構師的關鍵素質(zhì)。

産(chǎn)品或運營提了一個不靠譜需求，一句話打回去當然很(hěn)爽很(hěn)威風，但是有(yǒu)沒有(yǒu)仔細溝通分(fēn)析過，這個需求基于怎樣的實際訴求，這個實際訴求有(yǒu)沒有(yǒu)更合理(lǐ)的實現途徑，一句話“這個沒法做，這個實現成本太高”，不是正确的溝通态度，而且，最優秀的産(chǎn)品，往往是實現了那些原本人們認為(wèi)無法實現的訴求。

這樣的态度，才有(yǒu)了一個持續進步的基礎，下面說思路和方法。

優秀的程序員和平庸的程序員，如果隻看敲打代碼的速度，我覺得是分(fēn)不出來的，也許每人都可(kě)以一天寫很(hěn)多(duō)行代碼，但是遇到問題後，平庸的程序員的解決效率，和優秀程序員相比就會有(yǒu)天壤之别。 所謂解決效率，不外乎對 bug 的分(fēn)析、定位，以及思考。

最基本的一條，看執行日志(zhì)，看各種日志(zhì)，web server 的日志(zhì)，數據庫 的日志(zhì)，慢查詢日志(zhì)，binlog 日志(zhì)，php 的錯誤日志(zhì)，等等等等，線(xiàn)上出問題瞎猜連日志(zhì)都不看的大有(yǒu)人在。看日志(zhì)不仔細不完整的也大有(yǒu)人在，你能(néng)去認真研究日志(zhì)已經超越很(hěn)多(duō)人了。

程序員一個壞習慣就是上來就寫很(hěn)大一坨代碼然後再執行，不知道一個模塊一個模塊來寫來測試，執行出了問題不知道設置斷點，縮小(xiǎo)範圍逐步分(fēn)析。斷點分(fēn)析非常簡單，将整個代碼中(zhōng)插幾個中(zhōng)間輸出，觀察哪個環節出了問題，或者觀察每個環節的系統開銷，對調錯和性能(néng)優化都非常重要，高手們大概認為(wèi)這是 ABC 的東西，但是就這玩意我看到的大部分(fēn)程序員都沒有(yǒu)這個習慣。

搜索引擎上有(yǒu)各種豐富的技(jì )術資料和技(jì )術問答(dá)，你所遇到的錯誤信息和錯誤提示，通常都能(néng)在網上搜索到，當然，搜索到後要結合你的場景認真思考，并理(lǐ)解透徹，而不是照貓畫虎的去處理(lǐ)，否則可(kě)能(néng)這次運氣好就蒙對了，下次運氣不好又(yòu)不知道怎麽回事了。

對一個問題，一類問題，以及不同類型的問題，善于歸納整理(lǐ)，不斷反思自己的問題，即便是不出 bug 的代碼，你經過一段時間去回頭看，也有(yǒu)很(hěn)多(duō)思考不正确不合理(lǐ)的地方，有(yǒu)很(hěn)多(duō)優化點，如果你覺得自己的代碼一向牛逼，毫無破綻，那你一定是原地踏步，毫無進展。

大概就這些：

晚上準備買點方便面請公(gōng)司諸位程序員吃個便飯，今兒扯的太多(duō)了，萬一他(tā)們辭職了，小(xiǎo)編我怕是沒法過年了o(╯□╰)o