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

标签: 总结 Scalability 思考 | 发表时间:2015-07-26 09:57 | 作者:juvenxu
出处:http://www.juvenxu.com

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

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

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

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

  1. 大公司服务的用户数量级相比小公司不在一个层次。
  2. 大公司需要考虑如何保持数百数千程序员高效工作。
  3. 大公司处理的业务往往非常之复杂。

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

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

三个问题要求你学什么?

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

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

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

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

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

大公司的普遍弊端

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

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

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

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

总结

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

做任何选择,如果你不考虑失去什么,只考虑得到什么,那就是典型的幼稚。因此选择大公司还是小公司,你不仅得明白你期望收获什么,还得坦然面对要失去的东西。我说这么多,基本就是告诉你,有些东西你肯定会失去,还有一些东西,如果你努力,你可能会得到。

相关 [技术 大公] 推荐:

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

- - Juven Xu
我在小公司待过、也在大公司待过、还作为小公司的咨询顾问在大公司待过很长一段时间,目前还在大公司待. 对于个人成长,大公司能给你哪些小公司很难给的机会. 技术人员在大公司要面对的问题. 个人成长,方法大致是两种,第一是主动学,现在互联网这么开放,IT行业中的知识,只要你想学,几乎没有找不到的资料. 基本上,稍微靠谱点的技术人才,都具备主动学习的素质,然而这种学习方式,无论是看书、读博客、上在线课程…… 都有个非常明显的缺点,就是缺乏对问题的直观体验,几年前我看《Java Concurrency In Practice》,囫囵吞枣,表面上懂了,实际上压根没理解.

扒一扒知乎上的帖子——“为什么有些大公司技术弱爆了?”

- - 四火的唠叨
知乎上看到一个热帖,我觉得很有意思,叫做“ 为什么有些大公司技术弱爆了. 我刚看到标题的时候,先入为主和刻板偏见了一下,正如同第一个回答一样,我皱了皱眉头,产生了对题主的鄙视之情;但是很快,读完帖子以后,我却立场明确地站到题主一边了. 看题目以为是题主傻逼,看了正文发现真的是公司傻逼. 上面这种情况其实发生的概率挺低的,但是我觉得这回是真的发生了.

前端技术

- - CSDN博客综合推荐文章
随着互联网产业的爆炸式增长,与之伴生的Web前端技术也在历经洗礼和蜕变. 尤其是近几年随着移动终端的发展,越来越多的人开始投身或转行至新领域,这更为当今的IT产业注入了新的活力. 尽管Web前端技术诞生至今时日并不长,但随着Web技术的逐渐深入,今后将会在以下几方面发力. JavaScript的兄弟们.

SSI技术

- - 开源软件 - ITeye博客
1.       SSI,通常称为“服务器端包含”技术. 使用了SSI技术的文件默认的后缀名为.shtml,SSI技术通过在html文件中加入SSI指令让web服务器在输出标准HTML代码之前先解释SSI指令,并把解释完后的输出结果和HTML代码一起返回给客户端. 2.       SSI技术的优点:SSI技术是通用技术,它不受限于运行环境,在java、dotnet、CGI、ASP、PHP下都可以使用SSI技术;解释SSI的效率比解释JSP的效率快很多,因为JSP规范提供了太多的功能,这些功能都需要servlet引擎一一进行解释,所以效率比较低.

技术选型

- - 企业架构 - ITeye博客
MVC Framwork: SpringMVC3.0 Restful的风格终于回归了MVC框架的简单本质,对比之下Struts2概念太复杂更新又太懒了. Template:JSP2.0且尽量使用JSP EL而不是taglib,万一要写taglib也用纯JSP来编写,一向是SpringSide的推荐,Freemarker们始终有点小众, 而Thymeleaf与美工配合度非常高,可惜也是太少用户了.

技术的异化:读《技术垄断》

- Dynamic - It Talks--上海魏武挥的博客
事实上,我认为国内对马克思或神圣化或妖魔化,都是要不得的. 我们应该还马克思一个伟大的社会学(当然还有哲学、经济学之类)学者的本来面目,而不是把他的话当成教义. 异化就是一个相当精到的学术词语,它所描述的是人们创造发明某物本来为了让人们自己更好地工作生活,结果该物却成了人的主宰. 在很多领域,都有异化的影子,比如宗教,比如官僚体系,当然,也包括技术.

HBase技术介绍

- 三十不归 - 搜索技术博客-淘宝
HBase – Hadoop Database,是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统,利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群. 上图描述了Hadoop EcoSystem中的各层系统,其中HBase位于结构化存储层,Hadoop HDFS为HBase提供了高可靠性的底层存储支持,Hadoop MapReduce为HBase提供了高性能的计算能力,Zookeeper为HBase提供了稳定服务和failover机制.

Web技术整理

- Gabriel - 博客园-首页原创精华区
  Web技术或许是将来最为热门的技术之一. 这里略作一些总结,以及对各种Web技术作一些概要性介绍. (以下内容建立在我的粗略理解之上,欢迎指正).   推荐个学习Web技术比较好的网站,介绍的比较全面.   页面的展示使用超文本标记语言(HTML)来表示. 这是一种标签语言,本身不具有执行能力,只是结构化页面内容.

Hadoop相关技术

- - CSDN博客云计算推荐文章
Apache的Hadoop是什么. Apache的Hadoop项目™®开发出可靠的,可扩展的,分布式计算的开源软件. Apache的Hadoop的软件库是一个框架,允许大型数据集通过计算机集群使用简单的编程模型,进行分布式处理. 它的设计规模从单一服务器到数千台计算机,每个提供本地计算和存储. 软件库是用来检测和处理应用层失败的,而不是依靠硬件提供高的有效度,因此在计算机集群上提供高度可用性服务,其中每个都有可能会有失败.

zookeeper技术浅析

- - CSDN博客云计算推荐文章
 Zookeeper是hadoop的一个子项目,虽然源自hadoop,但是我发现zookeeper脱离hadoop的范畴开发分布式框架的运用越来越多. 今天我想谈谈zookeeper,本文不谈如何使用zookeeper,而是zookeeper到底有哪些实际的运用,哪些类型的应用能发挥zookeeper的优势,最后谈谈zookeeper对分布式网站架构能产生怎样的作用.