來源：陳皓
自從上次寫了《程式設計師技術練級攻略》 以來，就覺得似乎還有很多東西沒有談到，但當時沒有繼續思考了。而春節前有人問我，是做底層技術，還是做業務。這問題讓我思考了很多，不由自主地回顧了一 下我這十多年的軟體開發經歷，並順著整理分類了一下自己解決過的若干問題，還發散想了很多，經過了一個春節假期的發酵，產生了下面這篇文章。
前言
這篇文章必然是通過我的個人經歷來寫的。所以，我先說說個人經歷吧。我的經歷基本分成三個階段。
第一階段：我 剛畢業時在家鄉的某銀行工作，做些銀行的業務系統，還搞些網路，電子郵件系統，OA什麼的，因為大四的時候在老師的公司裡實習，銀行裡的人際關係太複雜， 而且技術都包給了產商，所以在銀行的每一天都覺得不能適應裡面的工作環境。兩年後離職，單位分的房也不要了，直接去了上海，在上海呆了兩年，本來想做互聯 網的，但是泡沫來了，最終去了一家做系統整合的國企公司還是繼續做銀行業務。這四年來，主要解決的都是一些業務上的問題，銀行裡的會計業務，OA業務，國 際業務，中間對公業務都非常地複雜，而且因為當時的軟體開發相當的不規模，所以基本上是在一種比較混亂的狀態下度過的，而銀行方面又很強勢，所以，這段時 間主要是做業務。所以，技術上主要是積累了如何使用那些技術。C+/Java， Windows程式設計，Unix程式設計，網路程式設計主要是這段時間學的，看了太多的書（我大學課程裡沒有C++和Java，也沒有Windows/Unix和網 絡程式設計，所以，只能拼命地看書和自學）。
第二階段：然後，我來了北京，到了一家做分散式計算系統的公 司，整天和一個高效能技術高可用性的企業級的叢集式的軟體產品打交道（這家公司去年被IBM收購了），在這家公司把Windows/Unix和網路程式設計有 了更深入的瞭解，對我長進比較大的是明白了怎麼做一個效能高，可用性高的叢集式的系統，天天和底層打交道，幹了4年多。然後去了一家金融資訊公司，這家金 融公司主要做全球的金融資訊資料處理，而我主要還是做核心資料釋出系統的效能調優的專案，金融資料的實時性要求的高，資料量非常地大，高可用性要求得高， 得想盡一切辦法省網路頻寬，增加系統效能，還要保持高的可用性，不當機，不丟包。又幹了4年多，去的時候從國外接過來兩個系統，其效能單機每秒可處理 120K message，我走的時候，我和團隊把其優化到了每秒1.4M messages 的吞吐，另一個系統，從接手時的100k message/s優化到了500k message/s。這八年多的時候，全是在和這些高計算高效能的專案打交量，幾乎沒有什麼業務，都是純技術，積累到了很多和效能有關的高併發高計算系統 架構級的知識。
第三階段：兩 年前來到了現在的做電子商務的網際網路公司Amazon，還是在做一個資料處理量很大的業務系統，因為要乾的是要把電子商務全球化的東西。但是，因為電子商 務的特殊性，必需要去兼顧業務的特點，而且在Amazon，耳讀目染了很多有趣的業務難題，比如，庫存計劃，配送優化，等等。雖然很多東西還不明白，但發 現，用技術來解決業務難題真是太有意思了。
我的這三個階段，第一個階段花了4年，第二個階段花了8年，第三階段剛剛開始2年不到，有時候我也去別的公司講課，所以，我很有幸經歷了中國軟體開發的進化過程。我的經歷就是中國軟體行業程式的一個縮影，而我把這三個階段稱為——軟體開發的三重門。它們分別是：
▲業務功能
▲業務效能
▲業務智慧
之所以加上“業務”二字，是因為我以為計算機是一個工具，其用來解決實際問題，所以，什麼都離不開業務，就算是效能優化也一樣，通過之前那篇《12306.cn的效能優化》中的“業務分析”段落，我們可以知道業務的不同，系統的難度和解決方法就可以不同。所以，我們總是用技術在解決業務問題。業務的形態對軟體的開發有決定性的作用。
下面讓我具體描述一下。
一重門：業務功能
這 是軟體開發的第一重門，也就是掌握可以實現業務功能的技術。通常分成三塊：語言+系統+資料處理。在這個階段，主要是能掌握各種技術，比如：開發用的各種 工具（如：IDE，XUnit，Debugger，等），各種程式碼庫和框架（如：C++的STL，ACE，Boost，等，Java的 Spring，Hibernate等），各種系統知識（如：Windows API，Unix/Linux API，TCP/IP，Socket，多執行緒多程式間的同步、互斥，併發安全，還包括Web平臺，移動平臺，等等），還需要掌握資料處理的知識（如：資料 結構，基本演算法，資料庫設計，資料庫引擎 ，SQL等）。
這個階段主要是把這些不同的技術組織成可以實現業務功能的解決方案。重點是能掌握和使用技術。很多流程和方法論的東西基本上就在這一重門裡。這重門主要解決的是實現問題。
二重門：業務效能
業務的功能搞定了以後，就是業務的效能問題了。搞定功能並不難，搞定效能是有點技術含量的事。有句話不是那麼說的嗎——每個人都可以搞一個網站出來，但不是每個人都能搞出能支援百萬級訪問量的網站。但是，我看到很多技術團隊或是工程師脫離了業務，只單純地搞效能，比如：單臺伺服器支援10萬個TCP連結的併發，等等。這些東西雖然在技術上有點意思，但是沒有業務的環境，也只能是自娛自樂了。
我們可以看到一些企業開始注重這個問題了，效能問題也是最近被大家討論得最多的問題，京東商場的效能問題，12306的效能問題，等等。
當然，所謂效能不併單單指系統的吞吐力，還指系統執行時的總體效能，比如，系統安全效能，系統的Accessbility的效能，系統的擴充套件性效能，等等，就像是前些天中《Web開發中需要注意的問題》一文中談到的那些事一樣。這表明著你對系統的全面和深入的瞭解。
在 這個階段，需要對業務模型，資料流，業務流，系統架構，演算法，和各種技術有深入的瞭解，要了解到本質上來。比如，在第一重門中，我們只需同要知 道，Java有同步關鍵字，在這一重門中，我們還要知道同步或互斥對效能的巨大傷害性，在第一重門中，我們只需要知道STL中的智慧指標或是STL的用 法，這一重門中，我們還要知道智慧指標中的refcnt的同步加鎖對效能的損害，還需要知道STL中容器的size()方法在某些時候是效能很差的。在第 一重門中，我們需要知道hash表的效率，在這一重門中，我們還需要知道hash表的碰撞問題。
最重要的是，在這重門重點是軟體的設計問題。你需要有足夠多的經驗能比較不同設計方案的優缺點，比如TCP和UDP，同步和非同步，epoll和select，push和pull，水平擴充套件的各種方案…… 還記得本站的那篇“程式設計師的謊謬之言還是至理名言”，廣度是你深度的副產品。所以，這重門是看你的技術視野有多深有多廣。
三重門：業務智慧
這 重門可能是最難的一重門了，如果你能進到這重門裡，你應該是科學家級的程式設計師了。讓你有智慧的業務，這個事可能是頂級的技術難題了。第一和第二重門都不算 難，這重門是最難的。參看Amazon的個性化推薦系統，或是Google搜尋引擎的結果個性化推薦等等（比如我輸入“黑天鵝”關鍵字，你怎麼知道我要找 的是動物，電影，還是本書？怎麼讓搜尋出來的結果排名即公正又可個性？），你就知道，用技術來解決這種類似的問題難度可想而知，不然就不會出現如 Hadoop之類的技術了。
我再舉兩個這重門裡的業務方面的例子。
▲一個例子是關於庫存計劃的，需要像天氣預報一樣 預測未來的銷售量從而決定庫存，所以，最簡單的做法是，監測各個商品的銷售統計，然後看一下最近的銷售趨勢，還要看一下往年的銷售趨勢（因為某些節假日會 是一個高峰期），還要分析一下大眾的喜好變化，比如，在某影評網站上的某電影的熱度其會告訴我哪個電影的DVD要滯銷了，得打折賣，哪個電影的DVD要暢 銷了，得多進貨了。還可能需要監控新聞評論，比如某權威人士推薦了某個商品，那麼我得趕快進貨了。等等。這完全就是一門科學。
▲還有一個例子是配送問題。我有一輛卡車要處理我倉庫和配送站間的物流問題，我需要找到一條最經濟的路線來在有限的時間內處理最多的物流。這個不是最短路徑問題，這是個計劃統籌學的東西。也是一門科學。
還有近期“方韓之爭”裡有很多人來分析文章相似度的技術，這些東西都屬於三重門裡的東西。
到了這重門裡，可能技術反而不是重要的了，而是數學模型。這重門裡主要是業務模型，資料模型和演算法問題。這些東西和你的業務模型密切相關。能解決這樣的問題，是真正的大牛。對於我來說，可能是高山仰止了。
後記
通過上面的說明，我們可以看到下面這些東西，
▲我的那篇《程式設計師技術練級攻略》裡的東西只能讓我們最多達到1.1 到 1.2重門。
▲一重門像是開墾荒地，二重門像是擴大生產，三重門像是精耕細作。
▲一重門（業務實現）裡聚集著大量的勞動密集型的企業，勞動密集型的企業通常都需要流程和方法論。敏捷過程改進這類的東西只在一重門裡。
▲二重門和三重門裡只有少數不多的技術型的公司。這類的公司通常非常注重技術，並且是企業文化是工程師的文化。
▲三重門裡可以產生的創新和那些可以用來改變世界的技術。
▲國內現在的情況是，一重門優化階段 + 二重門的學習階段。三重門裡似乎還沒有什麼見術。不過，我看到一些公司已在嘗試三重門的東西了。
▲作為技術人員的你，如果你想跟上時代，讓自己有價值的話，你至少要達到二重門。
▲因 為國內的技術環境等不良因素，導致大量的程式設計師在一重門的時候就已經失去信心，或被大浪淘沙淘掉了，所以，二重門裡的程式設計師比較少了，但是隨著年輕的一代 和技術的日趨成熟，也會慢慢多起來的，我現在已經看到這個趨勢了。而三重門裡的程式設計師成了稀缺的大熊貓。因為大量的二重門程式設計師幹到那個時候都轉管理了。
我的這些言論不一定對，但希望能讓大家有啟發，有所思考。
注：本來這篇文章的標題想取成“程式設計師要解決的三種問題”， 但是因為過年都在關注 “方韓之爭”，所以，乾脆取成了這個名字。你可以認為我比較調皮，也可以認為我愛ZB，還可以認為我標題黨，反正，請隨意理解。（這篇文章是我的自己寫 的，沒有代筆，因為你一定會在這篇文章中看到屬於我的用五筆打出來的錯別字，當然，我無法自證，哈哈）