前言
這篇文章必然是通過我的個人經歷來寫的。所以，我先說說個人經歷吧。我的經歷基本分成三個階段。
第一階段：我 剛畢業時在家鄉的某銀行工作，做些銀行的業務系統，還搞些網絡，電子郵件系統，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。這八年多的時候，全是在和這些高計算高性能的項目打交量，幾乎沒有什麼業務，都是純技術，積累到了很多和性能有關的高併發高計算系統 架構級的知識。
第三階段：兩年前來到了現在的做電子商務的互聯網公司，還是在做一個數據處理量很大的業務系統，因為要乾的是要把電子商務全球化的東西。但是，因為電子商 務的特殊性，必需要去兼顧業務的特點，而且在這家電商公司，耳讀目染了很多有趣的業務難題，比如，庫存計劃，配送優化，等等。雖然很多東西還不明白，但發 現，用技術來解決業務難題真是太有意思了。
我的這三個階段，第一個階段花了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重門。
• 一重門像是開墾荒地，二重門像是擴大生產，三重門像是精耕細作。
• 一重門（業務實現）裡聚集著大量的勞動密集型的企業，勞動密集型的企業通常都需要流程和方法論。敏捷過程改進這類的東西只在一重門裡。
• 二重門和三重門裡只有少數不多的技術型的公司。這類的公司通常非常注重技術，並且是企業文化是工程師的文化。
• 三重門裡可以產生的創新和那些可以用來改變世界的技術。
• 國內現在的情況是，一重門優化階段 + 二重門的學習階段。三重門裡似乎還沒有什麼見術。不過，我看到一些公司已在嘗試三重門的東西了。
• 作為技術人員的你，如果你想跟上時代，讓自己有價值的話，你至少要達到二重門。
• 因 為國內的技術環境等不良因素，導致大量的程序員在一重門的時候就已經失去信心，或被大浪淘沙淘掉了，所以，二重門裡的程序員比較少了，但是隨著年輕的一代 和技術的日趨成熟，也會慢慢多起來的，我現在已經看到這個趨勢了。而三重門裡的程序員成了稀缺的大熊貓。因為大量的二重門程序員幹到那個時候都轉管理了。
我的這些言論不一定對，但希望能讓大家有啟發，有所思考。
閱讀更多 碼農之屋 的文章
