自從上次寫了“程序員技術練級攻略” 以來，就覺得似乎還有很多東西沒有談到，但當時沒有繼續思考了。而春節前有人問我，是做底層技術，還是做業務。這問題讓我思考了很多，不由自主地回顧了一 下我這十多年的軟件開發經歷，并順著整理分類了一下自己解決過的若干問題，還發散想了很多，經過了一個春節假期的發酵，產生了下面這篇文章。

前言

這篇文章必然是通過我的個人經歷來寫的。所以，我先說說個人經歷吧。我的經歷基本分成三個階段。

第一階段：我 剛畢業時在家鄉的某銀行工作，做些銀行的業務系統，還搞些網絡，電子郵件系統，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，還可以認為我標題黨，反正，請隨意理解。（這篇文章是我的自己寫 的，沒有代筆，因為你一定會在這篇文章中看到屬于我的用五筆打出來的錯別字，當然，我無法自證，哈哈）

總結

以上是生活随笔為你收集整理的软件开发的“三重门”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。