程序員差異詳解

程序員的好壞，一方面體現在編程能力上，比如并不是每個程序員都有編寫一個編譯器程序的能力；另一方面，體現在程序設計方面，即使在沒有太多編程技能要求的領域下，比如開發一個訂單管理模塊，只要需求明確，具有一定的編程經驗，大家都能開發出這樣一個程序，但優秀的程序員和糟糕的程序員之間，依然有巨大的差別。

在軟件設計開發這個領域，好的設計和壞的設計最大的差別就體現在應對需求變更的能力上。而好的程序員和差的程序員的一個重要區別，就是對待需求變更的態度。差的程序員害怕需求變更，因為每次針對需求變更而開發的代碼都會導致無盡的 bug；好的程序員則歡迎需求變更，因為他們一開始就針對需求變更進行了軟件設計，如果沒有需求變更，他們優秀的設計就沒有了用武之地，產生一拳落空的感覺。這兩種不同態度的背后，是設計能力的差異。

應對需求變更最好的辦法就是一開始的設計就是針對需求變更的，并在開發過程中根據真實的需求變更不斷重構代碼，保持代碼對需求變更的靈活性。

我們在開始設計的時候就需要考慮程序如何應對需求變更，并因此指導自己進行軟件設計，在開發過程中，需要敏銳地察覺到哪些地方正在變得腐壞，然后用設計原則去判斷問題是什么，再用設計模式去重構代碼解決問題。

技術實力詳解

理解評估技術實力的基本原則后，我們知道了需要解決的問題復雜度越高，技術實力就越高。在這個基礎上，我把技術實力分為兩大類 6 分類：

硬實力：真正解決問題的能力，別人可以看出來的能力，技術實力按照“點、線、面、體”的 4 個分類逐層上升；

軟實力：比硬實力更厲害但也更虛的能力，簡單來說，要想解決問題首先得發現問題，但很多時候問題并不是一目了然的，需要有一定的技術洞察力。軟實力主要包括 2 個核心能力：發現問題、技術創新。

硬實力-技術點

“點”就是某個具體的技術，用來解決某個具體的問題，例如使用 JDBC 從數據庫讀取數據，目的是解決數據掉電丟失的問題；使用 Java 多線程，目的是為了解決大量用戶并發訪問的吞吐量和時延問題。掌握了技術點，就可以開始基本的業務功能開發了。

硬實力-技術線

“線”就是一系列相關的技術點組成，每個技術點都是為了解決某個問題。例如：

為了完成一個用戶請求，開發框架首先要有路由 router 功能，路由到具體 Controller 后，Controller 進行業務邏輯處理，處理過程中可能會使用 JDBC 來讀取數據，訪問 Redis 讀取緩存等，這一連串的技術每個都解決了一個問題點，串起來就完成了一個業務功能的處理過程。

為了定位一個線上 Java 服務器響應慢的問題，需要用到 tcpdump 抓包，使用 Java 工具查看 jvm 的狀態，使用 mysql 命令行或者工具查看數據庫狀態，使用 explain 分析可疑 SQL 語句。

掌握了技術線，就可以完成某個業務功能的全流程設計和開發了。

硬實力-技術面

“面”就是某一類相關技術線的綜合。例如：

Java 開發是一個技術面，包括多線程、JDBC、文件讀寫、JVM 調優、JVM 工具等多個技術線；

高性能開發是一個技術面，包括：數據庫分庫分表、緩存、多線程、HTTP 優化等；

數據庫維護是一個技術面，包括：數據庫調優、數據庫問題定位、高性能數據庫表設計等；

掌握技術面，已經是某個領域的專家了，簡單來說就是這個領域的問題找你都可以搞定。

硬實力-技術體

“體”就是多個技術面的綜合。

最常見的“體”就是架構設計，對于一個大型業務或者系統的架構師來說，需要掌握多個技術面，然后進行設計和取舍。例如，一個后臺架構師需要掌握 Java 的技術面、數據庫的技術面、網絡的技術面等，以及業務領域知識。

架構設計是橫向技術面的綜合，我稱之為廣度技術體；還有一種縱向技術面的綜合，我稱之為深度技術體。例如 Java 的開發工程師，當達到技術面的水平時掌握了“多線程、JDBC、文件讀寫、JVM 調優、JVM 工具等”，如果需要進一步在 Java 這個領域提升技術，就需要向下了解操作系統、硬件（CPU、內存、磁盤等），從而更好的解決某些復雜的問題，例如 Disruptor 高性能并發框架的設計。掌握了技術體，就可以進行架構設計，或者成為某個領域的資深專家了，解決領域級的復雜問題。

軟實力-發現問題

有的問題很明顯，例如線上出故障，系統性能不達標，系統性能需要達到 5W QPS；但有的問題并不那么明顯，并不能一眼看出是問題在哪里，是技術問題還是管理問題。

例如我們曾遇到團隊間協作開發效率很低，每次開發一個業務功能，都需要幾個系統的研發人員來討論接口協議、接口數據格式、接口安全加密、業務邏輯等，大家都不厭其煩，但好像又都必不可少，團隊間為了提高效率，項目經理制定了規范、流程、模板等，但作用最終都不大。那后來是怎么解決的呢？通過引入服務中心來完成系統間同步接口調用，通過引入消息隊列來完成系統間異步消息通知，系統間協作效率大大提高，以前要開會討論幾個小時的事情，現在只要明確接口傳輸的數據內容即可，甚至都不用開會，兩個研發一討論就差不多了。

除此以外，問題的根源往往掩蓋在很多問題表象之下，如果不解決根源問題，解決一個表象問題，獲得一時安寧，一段時間后又發生另外的問題，長此以往反反復復。

例如我們曾有個系統，今天交換機故障導致業務問題，明天系統 bug 導致業務問題，后天機柜斷電導致業務問題，還被黑客攻擊過，這些問題看起來都很獨立，問題的發生也感覺都是偶然的，按照出一個問題解決一個問題的方式也沒什么問題，但全年來看，業務就是出了很多問題，怎么解決？我們經過分析，發現根本原因是業務需要異地多活，而架構是雙機房單中心的，我們需要做到的不是避免每個問題的發生（事實上也不可能避免），而是應該做到問題發生后能夠快速處理，于是通過將架構重構為異地多活，重構完成后還是有各種偶發問題發生，但對業務的影響就很小了。

發現問題的能力主要來源于經驗，包括成功的經驗、踩坑的經驗、參考別人的經驗，因此如果要培養自己這方面的能力，多思考、多總結、多學習、多參加行業交流。

軟實力-技術創新

達到這個級別基本都是業界大神一般的級別，說實話我也沒什么經驗，只能仰慕這些大神。

例如：

當年貝索斯要求亞馬遜公司內的系統都服務化，后來是哪位大神想到可以把這個能力開放出來轉換為“云計算”？

阿里云王堅博士當年在眾人都不看好的情況下為何堅持云計算是未來？

Google 在解決大數據問題時，如何能夠提煉出三篇論文，開啟了一個大數據時代？