技术人员在大公司能学到什么

　　我在小公司待过、也在大公司待过、还作为小公司的咨询顾问在大公司待过很长一段时间，目前还在大公司待。对于个人成长，大公司能给你哪些小公司很难给的机会？这是本文想讨论的主题。

　技术人员在大公司要面对的问题

　　个人成长，方法大致是两种，第一是主动学，现在互联网这么开放，IT行业中的知识，只要你想学，几乎没有找不到的资料。基本上，稍微靠谱点的技 术人才，都具备主动学习的素质，然而这种学习方式，无论是看书、读博客、上在线课程…… 都有个非常明显的缺点，就是缺乏对问题的直观体验，几年前我看《Java Concurrency In Practice》，囫囵吞枣，表面上懂了，实际上压根没理解。近期当我面对一个比较典型的并发问题的时候，再翻出那本书，忍不住一口气读了几十页，因为 实在是太对胃口了！所以第二种学习方法往往更为重要，那就是：面对问题，解决问题，这是一种基于体验的成长，比基于纯理性的记忆理解，深刻得多。

　　所以， 有哪些问题，大公司需要面对？小公司不需要面对？ 我总结下基本是三个问题：


大公司服务的用户数量级相比小公司不在一个层次。


大公司需要考虑如何保持数百数千程序员高效工作。


大公司处理的业务往往非常之复杂。

　　当然上述几点并不总是正确的，比如现在会有一些小公司服务千万级别的用户，也需要面临类似的技术问题。但大体上就是这些问题，大公司必要面对，小公司在早期是不需要面对的。

　　上述三个问题实际上是 Scalability 的问题，具体我推荐大家看 《The Art of Scalability》 的详细阐述。解决上述三个问题，需要技术人员具备怎样的能力？

　三个问题要求你学什么？

　　第一个问题，如果面对百万级、千万级的用户，是被大家讨论最多的，具体的技术会涉及到：无状态应用、负载均衡、分布式缓存、分布式队列、高性能 Web服务器、数据分库分表…… 在大公司，也许根本轮不到你去开发分布式缓存，但只要你留点心，就能很快理解在什么情况下该用分布式缓存，它能带来多少性能提升，命中率还有多少提升空 间，等等。这一块，是大家面试的时候比较喜欢问题的，没做过的，都觉得很酷很牛逼的样子，经历过了，感觉其实也就那样，关键是你遇到问题了，并且用这些技 术解决了。

　　第二个问题，如何管理数百人的研发部门，更多的是被很多纯管理职位的经理在讨论。普通程序员，面对由于跨团队跨部门沟通所带来的消耗，10个程 序员估计会有11个骂娘；然而问题始终是客观存在的，我现在的日常工作一直遇到类似的问题，我也问过 Facebook 的工程师，人家也坦然承认，较之与 Facebook 早期，他们现在研发的效率也的确慢了很多。

　　保持自己工作高效，并不是个特别困难的问题；保持2-3人小团队工作高效，也不难，只要大家志趣相投、目标一致基本就可以了；10人左右的团 队，就需要聪明的管理者花许多时间去理解大家的想法并协调。当然，愚蠢的管理者只会开一大堆无意义的会，刷点存在感，传达点上面给的压力。团队规模再扩 大，带领上百人团队的中层管理者，他就需要去帮助一线管理者了，这个超出我的经验了。我想说的是，管理也是技术，不比编程更难，但也不见得比编程简单。

　　除了管理能力外，保持大规模团队的研发效率，还需要规范和工具支撑。使用一致的基础设施（如版本控制、测试环境、发布流程、沟通协议），规范化 大家的代码组织结构，抽取共有的技术服务，防止重复造轮子…… 这些都是非常具体、非常现实的技术问题。小公司几万行的代码做整体技术升级，找个牛逼的程序员就能搞定了，大公司几十万、几百万的代码做技术升级，没有任 何一个英雄主义程序员能搞定，解决这类问题需要有前瞻性的架构，需要有善于沟通的架构师。虽然过程中难免会需要和人扯皮开会，但做好了也是极富有成就感的 事情。

　　第三个问题，在大公司要面对更大的业务复杂度。也许是大公司产品经理太多了，大家都想折腾点东西出来，所以各种功能特性不停加不停变。这时候技术人员就不 得不去理解各种业务的含义，我们都知道，如果实现和业务意义不吻合，最终的代码就会变成一个无人可维护的怪胎，因此优秀的技术人员就能很好识别业务边界， 把小怪兽关在各自的笼子里，防止他们聚在一起搞得天翻地覆。再优秀的技术人员，就能说服产品经理，“这么干是不对的”。这方面我推荐 《Domain Driven Design》 。

　大公司的普遍弊端

　　我并不是说任何一个大公司的程序员都会去面对上面三个问题，事实上刚入职的新人程序员一般只会处理很小业务范围内的没有太大挑战的任务。不过只 要你有兴趣并持续提高自己能力，还是有很大机会去面对并处理这些问题的，因为公司的管理者终究是期望有人站出来帮他们排忧解难的。不过大公司或多或少都有 一些普遍的问题。

　　首先是 人浮于事、文山会海 。有很多人不停开会、不停写邮件，就是不干活，搞的你也没好心情干活。吐槽归吐槽，我还是会仔细想想为什么这样。首先，沟通是必要的，两三个人干活打个招 呼就行了，十多人干活就需要开会，事情多了，会也自然多，再加上很多人其实没有基本的主持会议技能，那很容易搞成垃圾会议。其次，公司大了自然会有一些兵 油子，每句话说出来都大方得体，但就没见他把事情落地，更别提自己挽起袖子干了，比较麻烦的是这些人普遍层级还相对高点。我能做的，就是离他们远点。

　　其次是 目光狭隘 。如果一个程序员刚毕业就来到大公司，而且恰好这几年这家大公司业务和技术突飞猛进，那他的眼光就容易受限，觉得自己的公司全国甚至全世界最牛逼，再加上 我们中国人普遍存在的报喜不报忧文化，他的这种盲目就更容易被环境所固化了。于是一不小心，一些人的技术视野就变得很窄，我在内部推广Git的时候，持疑 惑最大的也就是一些工作年限较长的资深工程师。

　　还有，我个人比较头大的是， 目标不一致 。跨团队、跨部门沟通的时候，你很容易发现自己在鸡同鸭讲。可能团队A关心技术架构，团队B关心业务指标，然后你上升一层，在部门层面做个决策先做什么后 做什么。一会你又发现，部门A关心业务指标、部门B关心基础建设，你又得上升一层，可那一层离你好远…… 所以你会发现很多大公司很多人做事很大程度上是在靠个人影响力，而不是正规的流程。如果我曾经做过些成功的事情，我平时对大家也比较热心，那我做一些事情 的时候，一些人会把自己的目标暂时放一边，来帮你一把，这就是俗称的“刷脸”。

　总结

　　总结之前，有一点我要额外提一下，大公司毕竟是藏龙卧虎的地方，各个领域都有比较资深的人存在，如果公司文化鼓励分享，那你就很容易找机会请人家喝杯咖啡，聊聊。

　　做任何选择，如果你不考虑失去什么，只考虑得到什么，那就是典型的幼稚。因此选择大公司还是小公司，你不仅得明白你期望收获什么，还得坦然面对要失去的东西。

　　我说这么多，基本就是告诉你，有些东西你肯定会失去，还有一些东西，如果你努力，你可能会得到。