我在小公司待過、也在大公司待過、還作為小公司的咨詢顧問在大公司待過很長一段時間，目前還在大公司待。對于個人成長，大公司能給你哪些小公司很難給的機會？這是本文想討論的主題。

[[142601]]

技術(shù)人員在大公司要面對的問題

個人成長，方法大致是兩種，***是主動學(xué)，現(xiàn)在互聯(lián)網(wǎng)這么開放，IT行業(yè)中的知識，只要你想學(xué)，幾乎沒有找不到的資料?；旧?，稍微靠譜點的技 術(shù)人才，都具備主動學(xué)習(xí)的素質(zhì)，然而這種學(xué)習(xí)方式，無論是看書、讀博客、上在線課程…… 都有個非常明顯的缺點，就是缺乏對問題的直觀體驗，幾年前我看《Java Concurrency In Practice》，囫圇吞棗，表面上懂了，實際上壓根沒理解。近期當(dāng)我面對一個比較典型的并發(fā)問題的時候，再翻出那本書，忍不住一口氣讀了幾十頁，因為 實在是太對胃口了！所以第二種學(xué)習(xí)方法往往更為重要，那就是：面對問題，解決問題，這是一種基于體驗的成長，比基于純理性的記憶理解，深刻得多。

所以， 有哪些問題，大公司需要面對？小公司不需要面對？ 我總結(jié)下基本是三個問題：

1. 大公司服務(wù)的用戶數(shù)量級相比小公司不在一個層次。

2. 大公司需要考慮如何保持數(shù)百數(shù)千程序員高效工作。

3. 大公司處理的業(yè)務(wù)往往非常之復(fù)雜。

當(dāng)然上述幾點并不總是正確的，比如現(xiàn)在會有一些小公司服務(wù)***別的用戶，也需要面臨類似的技術(shù)問題。但大體上就是這些問題，大公司必要面對，小公司在早期是不需要面對的。

上述三個問題實際上是 Scalability 的問題，具體我推薦大家看 《The Art of Scalability》 的詳細闡述。解決上述三個問題，需要技術(shù)人員具備怎樣的能力？

三個問題要求你學(xué)什么？

***個問題，如果面對***、***的用戶，是被大家討論最多的，具體的技術(shù)會涉及到：無狀態(tài)應(yīng)用、負載均衡、分布式緩存、分布式隊列、高性能 Web服務(wù)器、數(shù)據(jù)分庫分表…… 在大公司，也許根本輪不到你去開發(fā)分布式緩存，但只要你留點心，就能很快理解在什么情況下該用分布式緩存，它能帶來多少性能提升，***率還有多少提升空 間，等等。這一塊，是大家面試的時候比較喜歡問題的，沒做過的，都覺得很酷很牛逼的樣子，經(jīng)歷過了，感覺其實也就那樣，關(guān)鍵是你遇到問題了，并且用這些技 術(shù)解決了。

第二個問題，如何管理數(shù)百人的研發(fā)部門，更多的是被很多純管理職位的經(jīng)理在討論。普通程序員，面對由于跨團隊跨部門溝通所帶來的消耗，10個程 序員估計會有11個罵娘；然而問題始終是客觀存在的，我現(xiàn)在的日常工作一直遇到類似的問題，我也問過 Facebook 的工程師，人家也坦然承認，較之與 Facebook 早期，他們現(xiàn)在研發(fā)的效率也的確慢了很多。

保持自己工作高效，并不是個特別困難的問題；保持2-3人小團隊工作高效，也不難，只要大家志趣相投、目標(biāo)一致基本就可以了；10人左右的團 隊，就需要聰明的管理者花許多時間去理解大家的想法并協(xié)調(diào)。當(dāng)然，愚蠢的管理者只會開一大堆無意義的會，刷點存在感，傳達點上面給的壓力。團隊規(guī)模再擴 大，帶領(lǐng)上百人團隊的中層管理者，他就需要去幫助一線管理者了，這個超出我的經(jīng)驗了。我想說的是，管理也是技術(shù)，不比編程更難，但也不見得比編程簡單。

除了管理能力外，保持大規(guī)模團隊的研發(fā)效率，還需要規(guī)范和工具支撐。使用一致的基礎(chǔ)設(shè)施（如版本控制、測試環(huán)境、發(fā)布流程、溝通協(xié)議），規(guī)范化 大家的代碼組織結(jié)構(gòu)，抽取共有的技術(shù)服務(wù)，防止重復(fù)造輪子…… 這些都是非常具體、非?，F(xiàn)實的技術(shù)問題。小公司幾萬行的代碼做整體技術(shù)升級，找個牛逼的程序員就能搞定了，大公司幾十萬、幾百萬的代碼做技術(shù)升級，沒有任 何一個英雄主義程序員能搞定，解決這類問題需要有前瞻性的架構(gòu)，需要有善于溝通的架構(gòu)師。雖然過程中難免會需要和人扯皮開會，但做好了也是極富有成就感的 事情。

第三個問題，在大公司要面對更大的業(yè)務(wù)復(fù)雜度。也許是大公司產(chǎn)品經(jīng)理太 多了，大家都想折騰點東西出來，所以各種功能特性不停加不停變。這時候技術(shù)人員就不 得不去理解各種業(yè)務(wù)的含義，我們都知道，如果實現(xiàn)和業(yè)務(wù)意義不吻合，最終的代碼就會變成一個無人可維護的怪胎，因此優(yōu)秀的技術(shù)人員就能很好識別業(yè)務(wù)邊界， 把小怪獸關(guān)在各自的籠子里，防止他們聚在一起搞得天翻地覆。再優(yōu)秀的技術(shù)人員，就能說服產(chǎn)品經(jīng)理，“這么干是不對的”。這方面我推薦 《Domain Driven Design》 。

大公司的普遍弊端

我并不是說任何一個大公司的程序員都會去面對上面三個問題，事實上剛?cè)肼毜男氯顺绦騿T一般只會處理很小業(yè)務(wù)范圍內(nèi)的沒有太大挑戰(zhàn)的任務(wù)。不過只 要你有興趣并持續(xù)提高自己能力，還是有很大機會去面對并處理這些問題的，因為公司的管理者終究是期望有人站出來幫他們排憂解難的。不過大公司或多或少都有 一些普遍的問題。

首先是 人浮于事、文山會海 。有很多人不停開會、不停寫郵件，就是不干活，搞的你也沒好心情干活。吐槽歸吐槽，我還是會仔細想想為什么這樣。首先，溝通是必要的，兩三個人干活打個招 呼就行了，十多人干活就需要開會，事情多了，會也自然多，再加上很多人其實沒有基本的主持會議技能，那很容易搞成垃圾會議。其次，公司大了自然會有一些兵 油子，每句話說出來都大方得體，但就沒見他把事情落地，更別提自己挽起袖子干了，比較麻煩的是這些人普遍層級還相對高點。我能做的，就是離他們遠點。

其次是 目光狹隘 。如果一個程序員剛畢業(yè)就來到大公司，而且恰好這幾年這家大公司業(yè)務(wù)和技術(shù)突飛猛進，那他的眼光就容易受限，覺得自己的公司全國甚至全世界最牛逼，再加上 我們中國人普遍存在的報喜不報憂文化，他的這種盲目就更容易被環(huán)境所固化了。于是一不小心，一些人的技術(shù)視野就變得很窄，我在內(nèi)部推廣Git的時候，持疑 惑***的也就是一些工作年限較長的資深工程師。

還有，我個人比較頭大的是， 目標(biāo)不一致 ?？鐖F隊、跨部門溝通的時候，你很容易發(fā)現(xiàn)自己在雞同鴨講?？赡軋F隊A關(guān)心技術(shù)架構(gòu)， 團隊B關(guān)心業(yè)務(wù)指標(biāo)，然后你上升一層，在部門層面做個決策先做什么后 做什么。一會你又發(fā)現(xiàn)，部門A關(guān)心業(yè)務(wù)指標(biāo)、部門B關(guān)心基礎(chǔ)建設(shè)，你又得上升一層，可那一層離你好遠…… 所以你會發(fā)現(xiàn)很多大公司很多人做事很大程度上是在靠個人影響力，而不是正規(guī)的流程。如果我曾經(jīng)做過些成功的事情，我平時對大家也比較熱心，那我做一些事情 的時候，一些人會把自己的目標(biāo)暫時放一邊，來幫你一把，這就是俗稱的“刷臉”。

總結(jié)

總結(jié)之前，有一點我要額外提一下，大公司畢竟是藏龍臥虎的地方，各個領(lǐng)域都有比較資深的人存在，如果公司文化鼓勵分享，那你就很容易找機會請人家喝杯咖啡，聊聊。

做任何選擇，如果你不考慮失去什么，只考慮得到什么，那就是典型的幼稚。因此選擇大公司還是小公司，你不僅得明白你期望收獲什么，還得坦然面對要失去的東西。

我說這么多，基本就是告訴你，有些東西你肯定會失去，還有一些東西，如果你努力，你可能會得到。