有一個讀者問我：你認為一個程式設計師具備什麼樣的能力，才算得上是厲害的程式設計師？
這個回答貌似有點抽象，不要緊看下面的文章你會慢慢有所瞭解。很多年前，當我還是一個小菜鳥的時候，我的領導經常告訴我，解決問題的時候，不要侷限於技術本身，並且形象的給我舉了一個例子。
有一次兩個程式設計師一直討論，如何判斷兩臺伺服器之間是否網路正常，爭爭吵吵了很久。旁邊的一個測試說，Ping 一下不就知道了嗎？就這樣他們用 Java 程式碼實現了 Ping 操作解決了這個問題。多年以後，雖然我知道有更優雅的方式來解決這個問題，但是我仍然覺得之前的那個測試人員很聰明。後面我們持續打過一年交道，她能力真的很強，在小公司相當於產品經理+測試的職能。需要給大家說明的是：解決問題的能力和技術能力是兩個能力區間，我見過很多程式設計師原始碼玩得一溜，生產出現問題的時候仍然不知道如何去解決問題。生產出現問題的時候，是考驗一個程式設計師的最高水準，在面對高強度高壓力下，動作不變形，能夠冷靜思考、分析、解決問題，能達到這個水平的程式設計師，這在古代可以拜為上將軍。我一直非常喜歡能夠快速解決問題的程式設計師，我也樂於在各種生產出現問題的時候，第一時間去研究去分析。說一句不厚道的話，好程式設計師都是在解決問題中鍛煉出來的，特別是生產環境出現問題時，能夠站出來的程式設計師。01. 老平臺和新平臺
老系統使用了很多年，早已經超出了它能支援的極限，最早在2013年上線這套系統的時候，預估每天的交易量在一兩個億，實際上現在每天已經跑出了 40 億的交易量。從2013-2017年，技術團隊做了很多努力，老系統使用的是 Oracle 資料庫，為支援最大的交易量，讀寫分離分庫分表+各種最強硬體搞上；系統拆分、重構、最佳化了很多次，仍然滿足不了公司日益增長的交易量。說實話，團隊能把一個老系統整成這個樣子，也確實不易。最初的架構設計不合理，縫縫補補終究解決不了大問題。研發新平臺成為公司發展必須要做的一件事情，新平臺一期設計可以支撐日百億的交易量，最重要的是支援後期日千億的擴充套件。經過兄弟們的艱苦奮站，新平臺終於上線了。新平臺上線是成功的一小半，後面的資料遷移才是最最重點的事情。執行了好幾年的老系統，使用的是傳統的垂直架構，（架構演進可以參考這篇文章：從架構演進的角度聊聊Spring Cloud都做了些什麼？），各種業務、政策、活動、風控都揉在了一起。新平臺使用的微服務架構，光微服務就搞了上百個，資料庫 Mysql HA。兩個系統在架構設計上隔了一代，在設計時為了相容老系統的部分功能，還做了部分冗餘設計，反正這兩個系統就不是一個時代的產物。遷移的要求是，從老平臺遷移到新平臺的時候，不能影響到商戶的正常交易。打個比喻就相當於，你開著車在高速公路上跑，在行駛的過程中換掉車輪，而這個過程還得讓坐車的你還不能有任何感覺。於是我們研發了一套遷移系統，本來計劃著一批一批的遷移，給新平臺一次切一兩個億的交易量，慢慢看看效果再根據節奏來走，但是突然來的一次政策（活動）打亂了這個節奏。對於第三方支付公司來講，經常會隨著市場環境推出一些新政策（活動），有些政策比較簡單，但大多數政策很複雜，往往需要很大的開發量。當時新平臺已經切換了一段時間，大家慢慢對新平臺有了一定的信心，就決定在這個新政策在新平臺實施。計劃在執行政策的當天晚上，把其中一個老平臺上剩餘的商戶全部遷移到新平臺。方案定下來之後，各部門開始各司其職，運營中心對外發通知，我們要在元旦的時候搞個大動作，可能會有什麼樣的變化；營銷中心負責聯絡各代理進行分批培訓；商務部門開始出公司的紅標頭檔案，下發各分公司。我們提前和客服、運營部門做好溝通，可能會面臨哪些問題提前做預案；公眾號、公司官網、App、郵件對外通知政策變化，公佈開始執行日期；產品中心負責政策落地需求梳理，研發中心開發新政策確定的方案。最最最重要的是，要確保元旦晚上可以把剩餘幾百萬的商戶，一次性平穩的遷移到新平臺。遷移程式之前已經執行了很多次，所以大家對這塊相對比較放心，但仍然和主要負責遷移的同事確認了好多次，開發環境提前兩週必須測試完畢，UAT環境需要在遷移一週前測試完畢，研發和測試雙驗證。直到距離遷移還有三天的時候，我還專門找到負責遷移的那名程式設計師瞭解進展，問有沒有在生產上進行過模擬測試。確認沒有問題後，根據主負責人反饋的時間預估三四個小時可以遷移完畢，這樣凌晨 1：00 開始，凌晨 4：00-5：00 之間可以遷移完畢。在真正執行遷移的前一天，又拉著各部門做了一次溝通會，大家一起討論可能出現的各種情況，以及各部門需要留守的人員。開完會之後，大家感覺都還不錯，靜等晚上這一場大戰！當天晚上留下來十幾名開發和兩名測試，以及一些其它部門的同事，大概二十幾人左右，12點之前大家說說笑笑，打打遊戲靜等凌晨 1 刻遷移，因為剛好是元旦，辦公室一片過節的感覺。
時間過得很快，凌晨1點的北京，窗外星光點點，辦公室內一片緊張。
十幾名同事都圍在了主要負責遷移的這名程式設計師旁邊，能明顯感覺到這名程式設計師很有壓力（哈哈，我估計這種事情放誰身上都會有壓力）。不過他還是熟練的按照之前多次測試的那樣，核查了多遍資料之後，點選遷移按鈕。首先在生產環境遷移一個代理商，看看資料是否正確，執行完畢後相關人員開始核驗資料。運維人員核查日誌，開發人員確認相關節點正常、資料庫工程師核對遷移資料；測試人員在運營平臺查詢資料核驗、測試 Pos 刷卡測試，一切正常！試了兩個代理商都沒有問題，下面就準備 All In 了，剩下幾百萬商戶，上千個代理商就計劃一把梭了。負責遷移的程式設計師，將所有代理商編號，配置到執行程式中，點選了執行按鈕，生產跟蹤了一下日誌，一切正常。留下幾個人監控資料，其他人就散了，等遷移完成後再進行後續工作。我也回到了工位，點起了一根菸，想著今晚還比較順利。凌晨的夜晚比較困，當我點起第三根菸的時候，負責遷移的這位程式設計師，急匆匆的跑過來找我了。心中一驚，猛吸一口煙，把煙掐滅，忙問到：“出現啥問題？”原來這位程式設計師在遷移程式執行後，就一直在跟蹤遷移的進展，發現過了半小時才遷移了10萬商戶，老平臺總共幾百萬商戶，按照這個速度，全部執行完需要幾天後。如果在上午8：00 之前不搞定這個事情，那就完全是重大事故了。先不說怎麼處理新老平臺資料割裂，如果公司政策推遲執行，怎麼在這麼短的時間內把資訊通知到幾百萬商戶、幾千個代理商，就是一個不可能完成的工作量。可以想象第二天都會出現什麼樣的狀況，客服400電話被打爆、運營人員溝通到吐血，因政策推遲執行可能導致的公司損失，針對代理商的補償行為...如果這個問題我們沒有在一個小時內解決掉，就需要立刻上報公司副總經理，然後估計連夜公司所有的管理層，都需要來公司開會商量後續處理方案。大腦中雖然閃過遷移失敗後的嚴重後果，但眼前還需要壓下所有的想法，先分析到底是哪裡出現了問題，有沒有什麼樣的降級方案或者補救方法。經過查詢日誌、核對資料基本查明瞭原因，開發人員在生產測試的時候，都使用的是中小型代理商進行的測試；但忽略了公司不同代理商規模之間差異極大，最大的核心代理商一家的資料，可能佔平臺整體交易量的5%-6%。所以根據中小型代理商評估的時間肯定是不準確的，事已至此先不說誰的問題。如何快速解決問題才是接下來的關鍵，大家都一起想解決方案，有什麼辦法可以讓遷移速度更快一點。比如先同步核心資料，其它內容後續再進行處理，先保障第二天的交易；比如可不可以全部使用人工導表來處理，資料庫工程師聽到這個方案的時候，差點哭暈過去，上千多張表，關係極為複雜；其它各種各樣的方案..在大家七嘴八舌討論最佳化方案的時候，才發現遷移程式的主流程沒有使用多執行緒來遷移。遷移程式提供了一個介面，每次遷移的時候開發人員會在頁面填寫需要遷移的代理商編號，後臺接收到頁面傳遞的引數後，開始 for 迴圈執行遷移。雖然代理商下的商戶使用了多執行緒遷移，但是遷移代理商的主程式入口，卻沒有使用多執行緒，因此大家想是否把代理商這塊也用多線來加快遷移速度。大家討論之後，覺得多執行緒來遷移代理商應該是目前比較好的一個方案，但是如果讓現場寫，沒有經過測試直接就生產執行，風險還是比較大。那還有什麼不用改程式就可以實現這種代理商併發遷移的效果嗎？確實有！大家知道我們平時開發的 Web 應用，前臺的每一次請求到後端就會分配一個 Servlet 來處理響應，這個 Servlet 其實就是一個獨立的執行緒。那麼每次多開啟幾個頁面，同時執行遷移請求不就實現了多執行緒遷移代理商的效果嗎？說幹就幹，把之前的遷移程式停掉之後，選擇十幾個代理商進行多執行緒遷移測試，同時開啟了4個頁面，每個頁面輸入不同的代理商，開始遷移測試，測試後發現一切正常。開始加大測試量，使用幾十個代理商，在不同的頁面輸入後，先後點選了遷移程式，在第二次併發遷移的過程突然發現不時的會報一些錯誤。停止遷移程式，開始尋找原因，根據報錯的原因發現是出現共享資料了。我們知道 Servlet 是執行緒不安全的，當出現多執行緒訪問的時候，如果有全域性共享變數就會出現執行緒安全問題。這個問題好解決，使用 ThreadLocal 來修飾就行，ThreadLocal 為每個使用該變數的執行緒提供獨立的變數副本，所以每一個執行緒都可以獨立地改變自己的副本，而不會影響其它執行緒所對應的副本。這個問題解決之後就繼續開啟多個頁面執行，但同一個 Tomcat 並行超過 6 個執行緒的時候，機器負載就會比較高，因為每個執行緒內還會再次調起另外的執行緒池來處理商戶、業務員的遷移邏輯。於是就立刻安排運維人員，在生產環境找十臺伺服器，在這十臺伺服器上都部署上遷移的主排程程式。為了防止開發人員手抖出現問題，我讓運維給我開了許可權。於是在我的電腦上（我使用了多個螢幕），分別開啟了十臺伺服器上的遷移程式頁面，把所有需要遷移的代理商按照每次十五個分組，每次在一個頁面輸入一組代理商來遷移，如此迴圈依次在每臺伺服器開始遷移代理商。當我迴圈執行了6次的時候，資料庫工程師檢測到明顯資料的遷移速度加快，就這樣我用了兩個小時，在頁面把所有的代理商分別進行了遷移。大概到凌晨 4 點的時候，我的工作基本上搞完了，剩下的就讓程式慢慢跑了；凌晨 5 點的時候，大部分商戶資料都已經遷移過來，只剩下兩臺伺服器還在繼續跑；到了凌晨 6 點的時候，十臺伺服器的遷移程式全部跑完。安排把所有相關資料一一進行了核對後，大家長長的舒了一口。早上 7 點一起下來吃早餐的時候，大家還在說，感覺昨天晚上差點就過不去了。開玩笑說，如果凌晨2、3點的時候，給我們老闆打電話，老闆會是什麼樣的感覺。那時候想，出現這麼大的事故，老闆把我們開除了都是小事，如何收場才是我們最關心的。工作丟了可以再找，事情不管怎樣都是需要我們這批人來解決處理的。上午 9 點開啟交易後，又陸陸續續出現了一些小問題，但都是小面積的、不影響交易的問題，整體範圍可控，晚上遷移的這幫人，幾乎都堅持到了下午沒有太大問題了才回去睡覺。事後回想時，大家都一種劫後餘生的感覺。
事後我們開復盤會的時候，總結了這裡面疏漏的很多點，但這些都不是本文的重點。我們還是回到文章的開頭，什麼是厲害的程式設計師？
大家可以看到這個問題並不是特別的複雜，處理時需要的技術手段也比較簡單，但最關鍵是解決了當時最最緊迫的問題。所以說技術沒有什麼高低之分，學習技術的本質也是為了解決各種各樣的問題，不要對技術迷之自信，能用起來才是最好。
技術人要學會享受壓力，因為壓力就是動力，壓力就是讓你去成長的，越早遇到成長得越快。人在高壓高強度的環境中，哪怕很簡單的動作可能都會變形，從而有可能引發更大的二次事故。在高強度、高壓力的環境下穩定保持一顆冷靜分析的心，只有你自己沉靜下來才能真正的發現問題解決問題。很多技術人，出現問題時你看他在忙，其實是沒有思路在那瞎操作。冷靜下來，仔細分析整個鏈條，設想哪個地方可能會出現問題，然後透過查詢日誌或者相關命令，一步一步去排查、驗證問題的根源在哪裡，只有真正找到了問題的根源，你解決的時候才可以胸有成竹。當天晚上留守遷移的程式設計師，都是我司最核心的一批程式設計師，但是誰有能力上誰有能力下，在這一晚上很容易就能發現，優秀的程式設計師就像金子一樣，關鍵的時刻它會發光的。很多人遇到問題就自然的就會後退幾步，有的人遇到問題就喜歡衝上去。不管你平時原始碼研究得多牛逼，不管你的 PPT 寫得有多好，公司需要的是遇到問題的時候，有人能夠頂上去把問題解決掉。凡是能夠在關鍵時刻頂上去的程式設計師，基本上後面都很容易走上管理崗位。人和人其實就是在不斷磨合中建立信任的，領導在選擇提拔員工時，主要考慮就是能不能放心把事情交給你。所以大家平時研究技術的時候，不要走偏，原始碼、設計模式這些東西是應該研究，但更應該考慮的是研究後如何去應用，多專注一些實戰型的知識，這些東西關鍵時刻可以救你的命（職場）。那麼作為一名程式設計師，如何培養自己解決問題的能力呢？實踐！實踐！實踐！平時的技術學習只是一種強力輸入，如果不進行實踐，這些能力就會很快流失了。那如何實踐呢，多做專案，如果公司的專案用不到此技術，可以自己業餘時間寫寫程式碼自己去除錯一番；另外同事出現問題的時候多去幫忙解決問題，公司出現問題的時候，主動去幫忙解決問題；解決各種各樣的問題，是提升能力的最快方式。實踐完成之後，最好還能覆盤總結一番，把總結的內容作為日誌或者部落格記錄下來。記錄下來的內容就會成為你的一個知識寶庫，以後遇到類似問題的時候，檢索一下即可解決，如此不斷豐富自己解決問題的經驗。作者簡介：純潔的微笑，一個有故事的程式設計師。曾在網際網路金融，第三方支付公司工作，現為一名自由職業者，和你一起用技術的角度去看這個世界。我的微訊號puresmile2，歡迎大家找我聊天，記錄你我的故事。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31545820/viewspace-2653170/，如需轉載，請註明出處，否則將追究法律責任。