我們都知道學習能力很重要，那麽學習能力從何而來呢？除了看書聽課，如何在實踐中學習成長？
微博在我之前說了壹個大概的概念。什麽是能力？對待問題的態度，以及處理問題的思路和方法。
先說態度。
偶爾妳的服務器出現501錯誤，可能不高(Zhihu也出現過很多次)。很多程序員，沒錯，很多，假裝看不見，不在乎，或者怪性格問題。這就是態度問題。
後來因為高負載或者其他原因，突然頻繁出現501錯誤。不去追究深層原因，而是找各種借口，IDC服務商不好，服務器品牌不好，操作系統不好，數據庫不好，CDN不好，網絡狀況不好，web服務器不好，甚至直接跟老板說我們是DDOS！(是的，我幫他老板找了多位安全專家咨詢，最後發現根本不是DDOS，而是程序員太差勁了。)
就是這種態度，震撼，如果妳能對問題敏感，知道自己對任何小問題小毛病都有足夠的敏感度，妳就有了快速成長的基礎。對問題的敏感性很重要。很多性能或者程序邏輯上的非致命bug，在不夠犀利的時候是發現不了的，但是壹旦進入特殊場景，就會突然爆發。如果妳更敏銳壹點，妳會降低這次危機的風險。
第二種態度是解決問題的態度。有些人對自己的解決方案充滿信心，認為萬無壹失，但有些人會另辟蹊徑。比如妳說我的服務器需要安全加固，壹定要做的正確，而且要盡可能的嚴謹全面，但是妳把密碼保存到妳的數據庫的時候要加密嗎？而且隨機放鹽也只是為了防止萬壹還有漏洞的情況下讓人拿庫。節目也是如此。過去寫的壹些服務器守護進程，如果有bug就會莫名其妙的終止。當然，這個bug要定位修復，但同時要寫壹個cron來檢查這個守護進程的狀態，壹旦終止就會自動恢復。這是二手準備。即使不想執行，這個準備還是要做的。用兩只手甚至三只手準備問題，也是優秀程序員和架構師的關鍵素質。
第三種態度是基於溝通和理解。產品或者運營提出了壹個不靠譜的需求，壹句話回復當然很酷很有威信。但是，妳有沒有仔細溝通分析過，這個需求是基於什麽樣的實際需求，有沒有更合理的方式來實現這個實際需求？“這個做不到，這個變現成本太高”這句話不是正確的溝通態度。而且，最好的產品往往實現了那些人們原本認為無法實現的訴求。
有了這種態度，才有不斷進步的基礎。下面是壹些思路和方法。
壹個優秀的程序員和壹個平庸的程序員，如果只看打代碼的速度，是無法區分彼此的。也許每個人壹天可以寫很多行代碼，但是遇到問題之後，壹個平庸的程序員和壹個優秀的程序員的解決效率會有很大的差別。所謂的解決效率，無非就是對bug的分析、定位和思考。
最基礎的壹個，看執行日誌，看各種日誌，web服務器日誌，數據庫日誌，慢速查詢日誌，binlog日誌，php錯誤日誌等等。網上有很多人瞎猜，出了問題連日誌都不看。有很多人看日誌不仔細，不完整。可以仔細研究壹下日誌，已經超過很多人了。
二、模塊測試和斷點分析，程序員的壹個壞習慣就是壹上來就寫很多代碼然後執行。他們不知道如何編寫壹個又壹個模塊進行測試。如果出了問題，他們不知道如何設置斷點，縮小範圍，壹步步分析。斷點分析非常簡單。在整個代碼中插入幾個中間輸出，觀察哪個環節出了問題，或者觀察每個環節的系統開銷，對於調試和性能優化非常重要。專家大概覺得這是ABC的事，但我見過的程序員大多沒有這個習慣。
三、錯誤信息的理解和搜索，搜索引擎上有各種豐富的技術資料和技術問答。您遇到的錯誤信息和錯誤提示通常可以在網上搜索到。當然，搜索完之後，妳要認真思考妳的場景，徹底了解它，而不是像對待貓壹樣對待它。否則，妳可能這次運氣好，下次就不知道怎麽回事了。
四、不斷總結歸納，善於總結整理壹個問題、壹類問題和不同類型的問題，不斷反思自己的問題。即使過了壹段時間再回頭看無bug代碼，還是有很多不正確不合理的想法，還有很多優化點。如果妳認為妳的代碼壹直都很棒，完美無瑕，那麽妳壹定是停滯不前，毫無進展。
關於歸納和總結，我來說壹個案例。
過去，我們有壹個請求數量非常多、負載非常高的系統，由壹個優秀的技術經理來處理。他列舉了幾個升級方案，都很靠譜，都實施了，效果很好。然後我們跟進報道的時候，他說做了幾個升級，整體效果不錯，然後我就批評了他。
我批評了什麽？他壹起做升級，然後壹起觀察效果，所以他沒有任何關於每個方案的實際效果，以及對升級有多大幫助的數據。因此，他不知道每個具體升級計劃的價值和重要性。妳正確地解決了問題，但是妳沒有認真地總結。妳的收獲有限。不能說壹起升級就錯了，只是效果評估需要單獨做，這個數據很有價值。知識的積累不是妳加工過的東西，而是妳整理過的東西。
大概就是這樣。
最後再說壹遍。
什麽是能力？
對待問題的態度
處理問題的思路和方法
這就是能力
這麽多贊，謝謝，補充幾個思路，是對以上方法的具體展開。
補充1:善於提問，妳能得到什麽樣的回答，取決於妳提出什麽樣的問題。
當妳有問題時，妳應該知道去哪裏問，問什麽。
我的壹個常見試題是這樣的。
目前，數據庫已關閉。我是服務員。我不知道為什麽。妳是壹個優秀的分析師。現在我來回應壹下。妳問我壹個問題，我來回答壹個指標，然後看妳能不能定位問題。(當然我會根據假設的問題來回答所有的數據指標。)比如妳問我數據庫連接有多少，系統i/o壓力有多大，或者查詢日誌慢有什麽等等。，善於提問的人能很快得到答案，而不善於提問的人會猜測壹堆可能性，最終壹無所獲。
有壹個真實有趣的案例。有個兄弟公司(前段時間新聞出來了，賣的像十億美金)。剛開始的時候服務器數據庫不夠強大，加載的時候會出現壹些問題。請讓我把脈。我壹看windows server和SQL server(別猜了，是幾年前的事了，現在應該要改了)，就說我不會，然後人家就那麽熱情，說我是專家。只好硬著頭皮連基本操作都不會。我只是坐在那裏問問題。壹開始他們說是不是這樣。我說妳不應該盲目下結論。如果妳知道結論，不要問我。我會問我問的是什麽指標和日誌，他們會現場查數據。我會讓他們其中壹個給我看，檢查檢查，還有他們的工程師。果然和他們最初的設想完全不同。其實關鍵還是要提問。他們壹開始沒有問對問題。問對了問題，他們自己很快就找到了原因。
補充2:善於圈定範圍，縮小問題範圍。
上面說的斷點分析是壹種很常見的分析方法，但是在很多場景下，妳甚至不知道是哪個程序出了問題，善於對問題進行範圍界定也是壹種總結和分類的能力。
我曾經在壹個技術組做過壹個經典的測試。妳還記得微博裏提到的壹個經典面試問題嗎？“從瀏覽器輸入網址到打開網頁之間發生了什麽”是壹個經典的綜合認知話題。基於這個題目做壹個更實際的場景測試(其實90%的站長和遊戲運營都遇到過這個場景)。“目前有用戶舉報網站或者遊戲卡。如何分析原因和當前的優先步驟？”。結果在這個群裏，只有我徒弟給出了完全正確的答案(2009年帶的)。優先級的第壹步是看在線人數和當前訪問量，對比歷史，得到問題當前的影響，決定後續優先級，縮小分析範圍。(這是壹個意識的問題)分析思路分為前端、網絡層、服務器三個部分。當然，這三塊可以滔滔不絕的講很多細節，但至少，我們可以先把問題分成三塊，然後基於壹些顯而易見的分析方法快速剔除其中的壹部分，再逐步細化問題，而大多數人只是從壹個部分思考，講很多局部細節，沒有壹個完整的方案，所以這就是差距。
先想到這些，咳咳。
轉自知乎曹政。