面對萬“卷”世界，有人選擇拼命學習新技術，解決眼前的、點狀問題；有人提升思維層級，解決未來的、系統問題。您選擇什麼？
背景
我有10多年程式設計經驗和研發管理經歷，雖很久不寫程式碼，但有很多人找我諮詢技術問題，解決程式 BUG。因為不管多麼千奇百怪的技術棧，我都能幫到他們，或直接給出解題思路，或幫他們精準定位問題。
在很多具體的技術點上（比如SQLServer、Kubernetes上），我都算不上資深專家，但我總能幫這些資深專家快速解決 BUG。為什麼呢？
回答這個問題之前，我們要分清「診斷」和「治療」。「診斷」需要的是結構化思維，只要您理解計算機執行原理，對現代應用的組成有基本認知，您就可以用「假設樹」和「主動試驗」來逐步縮小範圍，最終確定「病因」。但「治療」，需要把想法實現，需要具體的技術知識。
很多程式設計師在具體技術上很精通，但在需要平移或擴充套件到其它類似技術時，往往捉襟見肘。這導致，為了自己的維持競爭力，需要拼命的學習新的技術棧。很累，卻效果不好。
本系列文章不介紹具體的技術，而介紹一種「程式診斷」的思維框架，是「價效比」更高的「通項公式」，可以跨場景解決任何問題，可以終生受益！
核心思路：做實驗→造現象→縮範圍
本「程式診斷」的核心思路就是依賴於「假設樹」，透過重複多次執行「做實驗→造現象→縮範圍」動作序列，逐級下鑽，縮小問題範圍，直到「執行者」可以接管的程度（通常是一個服務/模組/函式）。如下圖所示：
其基本邏輯是：
- 面對現象，先從宏觀去判斷第一層級的「可能的原因」，即原因所在的大類。當我們判斷了第一層級的原因，我們就把問題範圍縮小了。
- 假設確定原因大類為「可能的原因2」，接下來在更小的範圍中，我們需要進一步確定更具體的原因，是 2-1 還是 2-2 還是 2-3。
- 如果當前現象沒有提供充分的證據來幫我們進一步縮小範圍，則我們需要主動做試驗，來創造更多現象，以支撐我們縮小範圍。
- 重複上面三個步驟，直到把範圍縮小到執行者可以解決的程度。
在軟體領域，前幾層的「假設樹」一般有大致的套路。以一個 Web 應用為例，其前幾層「假設樹」通常可參考下圖製作。
我們面對一個現象時，通常先判斷是前端原因還是後端原因。
假設是前端原因，我們再判斷，是執行問題（程式碼問題）、資料問題、網路問題、還是執行環境問題。展開來說：
- 如果近期釋出過新版本，則有很大機率是執行問題（程式碼問題）。
- 如果排除了程式碼問題，並且 BUG 只有某些固定使用者出現，或只跟某些固定的實體（比如商品、流程）相關，那麼大機率是資料問題。
- 如果排除了以上兩者，並且 BUG 只有某些固定使用者出現，則可以檢查一下這些使用者的瀏覽器（品牌和版本）是否一樣，以確定是否瀏覽器問題。
- 如果排除了以上三者，並且 BUG 跟使用者所在的網路環境有很大關係，則可以檢查下網路。
再往後，以此類推。
請注意，「假設樹」沒有標準答案，以上只是 Web 應用的「假設樹」的「一種」拆分方法。面對不同的軟體應用場景、不同的現象，你可能需要繪製自己的「假設樹」。這個繪製不難，只要懂得計算機的基本執行原理和現代應用的基本組成部分，利用機構化拆解問題的基本方法，即可繪製。
從第一性原理來講，一個應用本質就是「處理」「資料」的程式。出現問題，要麼是處理邏輯發生了改變（一般是程式碼導致），要麼是資料發生了改變。如果我們能保證程式碼沒改變（透過釋出的版本號或者 Git 提交號來判斷），那麼一定是資料發生了改變。假設確定了是資料的問題，我們可以繼續列舉原因，可能是環境配置的資料、資料庫的資料、快取的資料、其它微服務傳遞過來的資料、前端傳遞過來的資料、時間等。這樣，就可以繼續往下鑽。
實踐原則：程式斷案三字經
透過上面的介紹，您大概已經知道了核心思路。但到實際使用，還需要一些操作原則來幫助。我把他們總結成「程式斷案三字經」：
- 先診斷，後開藥。
- 信機器，慎信人。
- 做試驗，縮範圍。
- 先脆弱，後穩定。
- 找不同，看變化。
篇幅原因，本文不展開介紹這些實踐原則，請關注本系列後續文章，我將深度講解實踐原則和典型案例。
總結
面對萬“卷”世界，有人選擇拼命學習新技術，解決眼前的、點狀問題；有人提升思維層級，解決未來的、面狀問題。您選擇什麼？
關於作者
您好，朋友。我現就職於西門子工業軟體，擔任高階諮詢顧問。成功領導 10 多個世界 500 強企業的數字化轉型專案，跨越政府、零售、金融、汽車製造、生物醫藥等多個行業，創造巨大商業價值。
如有任何與「數字化轉型」有關的問題，歡迎用以下方式與我交流：
-
新增我的個人微信「zjh1943」。新增時請註明姓名、行業、交流的問題。
-
關注我的微信公眾號「知明所以」。
-
關注我的知乎專欄：https://www.zhihu.com/people/zhu-jin-heng 。