不止是代码-阿里巴巴.pdf
《不止是代码-阿里巴巴.pdf》由会员分享,可在线阅读,更多相关《不止是代码-阿里巴巴.pdf(113页珍藏版)》请在文库网上搜索。
1、阿里技术微信公众号阿里巴巴机器智能公众号扫一扫二维码图案,关注我吧如何快速成长为技术大牛?阿里资深技术专家的总结亮了 1毕业 3 年,为何技术能力相差越来越大?10程序员吃的是青春饭?本质上取决于 15技术变化那么快,程序员如何做到不被淘汰?21加班越久故障越多,如何跳出程序员的恶性循环?32如何在阿里技术面试中脱颖而出?39使用开源项目的正确姿势,血和泪的总结 48前端工程师的未来在哪里?57前端 Leader 如何做好团队规划?阿里内部培训总结公开 65一位优秀前端的自我修养 76如何成为一名顶尖的阿里架构师?87哪些技术好书值得一读再读?这有一份经典书单 94阿里技术大牛最爱的“闲书”,
2、你看过多少?103目录阿里技术人生阿里技术人生我也是一位程序员,所以我希望通过以下基于程序开发的一些例子,帮助大家解决这些困惑。大道理是相通的,测试、运维都可以借鉴。几个典型的误区拜大牛为师有人认为想成为技术大牛最简单直接、快速有效的方式是“拜团队技术大牛为师”,让他们平时给你开小灶,给你分配一些有难度的任务。我个人是反对这种方法的,主要的原因有几个:大牛很忙,不太可能单独给你开小灶,更不可能每天都给你开 1 个小时的小灶;而且一个团队里面,如果大牛平时经常给你开小灶,难免会引起其他团队成员的疑惑,我个人认为如果团队里的大牛如果真正有心的话,多给团队培训是最好的。然而做过培训的都知道,准备一场
3、培训是很耗费时间的,课件和材料至少 2 个小时(还不能是碎片时间),讲解 1 个小时,大牛们一个月做一次培训已经是很高频了。因为第一个原因,所以一般要找大牛,都是带着问题去请教或者探讨。因为回答或者探讨问题无需太多的时间,更多的是靠经验和积累,这种情况下大牛们都是很乐意的,毕竟影响力是大牛的一个重要指标嘛。然而也要特别注意:如果经常问那些书本或者 google 能够很容易查到的知识,大牛们也会很不耐烦的,毕竟时间宝贵。经常有网友问我诸如“jvm 的-Xmn 参数如何配置”这类问题,我都是直接回答“请直接去 google”,因为这样的问题实在是太多了,如果自己不去系统学习,每个都要问是非常浪费自
4、己和别人的时间的。大牛不多,不太可能每个团队都有技术大牛,只能说团队里面会有比你水平高的人,即使他每天给你开小灶,最终你也只能提升到他的水平;而如果是跨团队的技术大牛,由于工作安排和分配的原因,直接请教和辅导的机会是比较少的,单凭参加几次大牛的培训,是不太可能就成为技术大牛的。阿里技术人生阿里技术人生1)上班做的都是重复工作,要想提升必须自己额外去学习形成这个误区的主要原因还是在于认为“写业务代码是没有技术含量的”,而我现在上班就是写业务代码,所以我在工作中不能提升。2)学习需要大段的连续时间很多人以为要学习就要像学校上课一样,给你一整天时间来上课才算学习,而我们平时加班又比较多,周末累的只想
5、睡懒觉,或者只想去看看电影打打游戏来放松,所以就没有时间学习了。实际上的做法正好相反:首先我们应该在工作中学习和提升,因为学以致用或者有实例参考,学习的效果是最好的;其次工作后学习不需要大段时间,而是要挤出时间,利用时间碎片来学习。正确的做法Do more做的更多,做的比你主管安排给你的任务更多。我在 HW 的时候,负责一个版本的开发,这个版本的工作量大约是 2000 行左右,但是我除了做完这个功能,还将关联的功能全部掌握清楚了,代码(大约 10000行)也全部看了一遍,做完这个版本后,我对这个版本相关的整套业务全部很熟悉了。经过一两次会议后,大家发现我对这块掌握最熟了,接下来就有趣了:产品讨
6、论需求找我、测试有问题也找我、老大对外支撑也找我;后来,不是我负责的功能他们也找我,即使我当时不知道,我也会看代码或者找文档帮他们回答。最后我就成了我这个系统的“专家”了。虽然这个时候我还是做业务的,还是写业务代码,但是我已经对整个业务都很熟悉了。以上只是一个简单的例子,其实就是想说:要想有机会,首先你得从人群中冒出来,要想冒出来,你就必须做到与众不同,要做到与众不同,你就要做得更多!怎么做得更多呢?可以从以下几个方面着手:1)熟悉更多业务,不管是不是你负责的;熟悉更多代码,不管是不是你写的这样做有很多好处,举几个简单的例子:阿里技术人生阿里技术人生后来用上了几次,每次都解决了卡死的大问题,而
7、有的同学,写了几年的 java 代码,对于 stop-the-world 是什么概念都不知道,更不用说去优化了。Do better要知道这个世界上没有完美的东西,你负责的系统和业务,总有不合理和可以改进的地方,这些“不合理”和“可改进”的地方,都是更高级别的怪物,打完后能够增加更多的经验值。识别出这些地方,并且给出解决方案,然后向主管提出,一次不行两次,多提几次,只要有一次落地了,这就是你的机会。例如:重复代码太多,是否可以引入设计模式?系统性能一般,可否进行优化?目前是单机,如果做成双机是否更好?版本开发质量不高,是否引入高效的单元测试和集成测试方案?目前的系统太庞大,是否可以通过重构和解耦
8、改为 3 个系统?阿里中间件有一些系统感觉我们也可以用,是否可以引入?只要你去想,其实总能发现可以改进的地方的;如果你觉得系统哪里都没有改进的地方,那就说明你的水平还不够,可以多学习相关技术,多看看业界其它优秀公司怎么做。我 2013 年调配到九游,刚开始接手了一个简单的后台系统,每天就是配合前台做数据增删改查,看起来完全没意思,是吧?如果只做这些确实没意思,但我们接手后做了很多事情:解耦,将一个后台拆分为 2 个后台,提升可扩展性和稳定性;双机,将单机改为双机系统,提高可靠性;优化,将原来一个耗时 5 小时的接口优化为耗时 5 分钟还有其它很多优化,后来我们这个组承担了更多的系统,后来这个小
9、组 5 个人,负责了 6 个系统。阿里技术人生阿里技术人生内存分布和垃圾回收情况。这样的程序写起来很简单,简单一点的就几行,复杂一点的也就几十行。Reactor 原理:自己真正去尝试写一个 Reactor 模式的 Demo,不要以为这个很难,最简单的 Reactor 模式代码量(包括注释)不超过 200 行(可以参考Doug Lee 的 PPT)。自己写完后,再去看看 netty 怎么做,一对比理解就更加深刻了。MySQL:既然有线上的配置可以参考,那可以直接让 DBA 将线上配置发给我们(注意去掉敏感信息),直接学习;然后自己搭建一个 MySQL 环境,用线上的配置启动;要知道很多同学用了很
10、多年 MySQL,但是连个简单的 MySQL环境都搭不起来。框架封装了 DAL 层:可以自己用 JDBC 尝试去写一个分库分表的简单实现,然后与框架的实现进行对比,看看差异在哪里。用浏览器的工具查看 HTTP 缓存实现,看看不同种类的网站,不同类型的资源,具体是如何控制缓存的;也可以自己用 Python 写一个简单的 HTTP 服务器,模拟返回各种 HTTP Headers 来观察浏览器的反应。还有很多方法,这里就不一一列举,简单来说,就是要将学到的东西真正试试,才能理解更加深刻,印第安人有一句谚语:I hear and I forget.I see and I remember.I do a
11、nd I understand,而且“试试”其实可以比较简单,很多时候我们都可以自己动手做。当然,如果能够在实际工作中使用,效果会更好,毕竟实际的线上环境和业务复杂度不是我们写个模拟程序就能够模拟的,但这样的机会可遇不可求,大部分情况我们还真的只能靠自己模拟,然后等到真正业务要用的时候,能够信手拈来。3)Teaching一般来说,经过 Learning 和 Trying,能掌握 70%左右,但要真正掌握,我觉得一定要做到能够跟别人讲清楚。因为在讲的时候,我们既需要将一个知识点系统化,也需要考虑各种细节,这会促使我们进一步思考和学习。同时,讲出来后看或者听的人可以有不同的理解,或者有新的补充,这
12、相当于继续完善了整个知识技能体系。阿里技术人生阿里技术人生毕业 3 年,为何技术能力相差越来越大?蛰剑阿里妹导读:毕业三年,每个人在技术能力跑道上,有了或大或小的差距。有些人永远在重复的劳动,有些人却能从中总结和解决问题。今天我们来探讨下,如何避免让战术上的勤奋掩盖战略上的懒惰,使得真正掌握好的知识点慢慢生长,连接,最终组成一张大网。写在前面高考的时候大家都是一样的教科书,同一个教室,同样的老师辅导,时间精力基本差不多,可是最后别人考的是清华、北大或者一本,而有些童鞋的实力只能考个三本,这是为什么?阿里技术人生阿里技术人生系统化的知识哪里来?知识之间是可以联系起来的并且像一颗大树一样自我生长,
13、但是当你都没理解透彻,自然没法产生联系,也就不能够自我生长了。当我们讲到入门了某块知识的时候一般是指对关键问题的点理解清晰,并且能够自我生长,也就如滚雪球一样可以滚起来了。好的逻辑又怎么来?实践 复盘讲个前同事的故事我有一个前同事,所有解决不了的问题都找他。这位同学让我最佩服的是解决问题的能力,好多问题其实他也不一定擅长,但是他就是有本事通过 Help、Google 不停地验证、尝试就把一个不熟悉的问题给解决了,这是我最羡慕的能力,在后面的职业生涯中一直不停地往这个方面尝试。阿里技术人生阿里技术人生空洞的口号很多文章都会教大家:举一反三、灵活运用、活学活用、多做多练。但是只有这些口号是没法落地
14、的,落地的基本原则就是前面提到的,却总是被忽视了。什么是工程效率,什么是知识效率有些人纯看理论就能掌握好一门技能,还能举一反三,这是知识效率,这种人非常少。大多数普通人都是看点知识,然后结合实践来强化理论,要经过反反复复才能比较好地掌握一个知识,这就是工程效率,讲究技巧、工具来达到目的。肯定是知识效率最牛逼,但是拥有这种技能的人毕竟非常少(天生的高智商吧)。从小我们周边那种不怎么学的学霸型基本都是这类,这种学霸都还能触类旁通非常快地掌握一个新知识,非常气人。剩下的绝大部分只能拼时间+方法+总结等,也能掌握一些知识。非常遗憾我就是工程效率型,只能羡慕那些知识效率型的学霸。但是这事又不能独立看待,
15、有些人在某些方向上是工程效率型,有些方向就又是知识效率型(有一种知识效率型是你掌握的实在太多,也就比较容易触类旁通了,这算灰色知识效率型。)使劲挖掘自己在知识效率型方面的能力吧,两者之间当然没有明显的界限,知识积累多了,逻辑训练好了,在别人看来你的智商就高了。知识分两种一种是通用知识(不是说对所有人通用,而是说在一个专业领域去到哪个公司都能通用),另外一种是跟业务公司绑定的特定知识。通用知识没有任何疑问,碰到后要非常饥渴地扑上去掌握他们(受益终生,这还有什么疑问吗?)。对于特定知识就要看你对业务需要掌握的深度了,肯定也是需要掌握一些的,特定知识掌握得好的,一般在公司里混得也会比较好。阿里技术人
16、生阿里技术人生 你希望技术能进一步积累,那你积累的方向和期望达到的结果分别是啥?你希望能有技术决策,希望有影响力,你觉得应该如何做到?是希望通过岗位任命的方式吗?你觉得是否成功的标志,就是今年或明年得到晋升吗?等等大部分同学在面对这些问题时,其实是比较迷茫的,也缺少真正可度量的衡量标准。是否能在短期内获得晋升成了大部分人作为“组织是否认可、自己是否认可”的衡量标准了。当然,这个话题仁者见仁、智者见智,这里我简单地谈谈我的看法。我以相对比较口水化的方式,将职业发展分两个阶段来进行阐述:1)第一阶段:大学毕业 3 到 5 年2)第二阶段:大学毕业 5 到 10 年阿里技术人生阿里技术人生发现没有?
17、这个阶段,我们能协调好的资源其实就是自己,更多的是一个“个人贡献者”。只要把自己管好了,学习计划执行好了,工作高质量做好了就能得到认可。第二阶段:大学毕业 5 到 10 年很多本科同学,特别是研究生同学。在毕业 10 年后,就已经到了 34、35 岁左右了。也是前段时间网上广泛讨论的所谓 34+岁现象。其实,年龄并不是问题的真正原因。真正的原因还是在于自身“竞争力”是否符合这个年龄所应该具备的。到了这个年龄的人,往往已经不是“个人贡献者”了,而是“团队贡献者”。团队贡献者可能是带团队的 TL,也可能是个架构师,在技术决策上具有团队影响力和话语权。那么,为什么这些人能管理团队或者有影响力呢?从公
18、司的经营视角看,一个管理团队的人,他必须为业务的成功负责。说个大白话,一个 TL 管了 N 个人,他至少要能保证大家输出所产生的价值,至少要高于这个团队的工资、奖金、五险一金、OPEX、CAPEX 等等吧。这个 TL 为了大家输出得阿里技术人生阿里技术人生 另外,在这 10 年内,比较关键的是你还经历过什么有挑战的业务、技术、产品、平台等方面的成功与失败经验?在这些经历里,你可能会遇到这些困难与挑战:团队磨合的挑战、技术方案上的争执、平台优先 or 业务优先的博弈、低落的团队氛围、个人的低谷等等。这些困难与挑战,你是退缩了?还是有成长?在带团队时,再次面临这些挑战时,这时你是否有解或者有勇气了
19、?发现没有?毕业 10 年后,作为一个团队贡献者,你可能需要具备这些能力,并且还远远不止。而且,更可悲的时,当毕业 10 年后,突然发现自己不具备这个能力时(比如晋升失败时发现了),这些能力 GAP 就不再是 2 到 3 年就能追得上的了。我见过一些有准备的同学,他们给自己的目标是在毕业第 7 年就要具备这些能力,他有严格的学习计划、实践计划、甚至是冒险的创业经历。当他到第 10 年这个点时,这些高阶技能很可能已经有 3 年的实践经验了。如果我们没有做好准备,10 年后,如何和这批人竞争?这些软、硬知识,从十年这个时间刻度倒排,学习计划、实践计划的执行还是很紧张的。所以,从现在开始给自己制定一
20、个严格的学习计划、严格执行,多实践吧!阿里技术人生阿里技术人生程序员的迷茫不仅仅是面对技术繁杂的无力感,更重要的是因为长期埋没于软件世界的浩大的分工体系中,无法看清从业务到软件架构的价值链条,无法清楚定位自己在分工体系的位置,处理不好自身与技术、业务的关系所致。很多程序员打心底不喜欢业务,这一点我曾经也经历过,我更宁愿从事框架工具、技术组件研究的相关事情。我有个朋友经常吐槽我说:”你们天天加班加点写了那么多代码,然后呢?有改变什么吗?还不是写出了一堆垃圾。”仔细想想很多时候业务在我们脑海中存留的只是逻辑和流程,我们丢失的是对业务场景的感受,对用户痛点的体会,对业务发展的思考。这些都是与价值紧密
21、相关的部分。我们很自然的用战术的勤快掩盖战略的懒惰!那么这样的后果就是我们把自己限死在流水线的工位上,阉割了自己能够发现业务价值的能力,而过多关注新技术对职场竞争力的价值。这也就是我们面对繁杂技术,而产生技术学习焦虑症的根本原因。业务、技术与软件系统的价值链那么什么是业务呢?就是指某种有目的的工作或工作项目,业务的目的就是解决人类社会与吃喝住行息息相关的领域问题,包括物质的需求和精神的需求,使开展业务活动的主体和受众都能得到利益。通俗的讲业务就是用户的痛点,是业务提供方(比如公司)的盈利点。而技术则是解决问题的工具和手段。比如为了解决用户随时随地购物的业务问题时,程序员利用 web 技术构建电
22、子商务 App,而当需求升级为帮助用户快速选购商品时,程序员会利用数据算法等技术手段构建推荐引擎。技术如果脱离了业务,那么技术应用就无法很好的落地,技术的研究也将失去场景和方向。而业务脱离了技术,那么业务的开展就变得极其昂贵和低效。阿里技术人生阿里技术人生的利润,这是人肉所不可比拟的。理解了这一层面的概念,你就可以清楚这个价值链条:公司依靠软件系统提供业务服务而创造价值,程序员则是通过构建并持续演进软件系统服务能力以及业务功能以支撑公司业务发展从而创造价值。有了这个价值链条,我们就可以反思自己的工作学习对软件系统的服务能力提升起到了多大的推动作用?可以反思自己的工作学习是否切实在解决领域的业务
23、问题,还是只是做一些意义不大的重复性工作。前两天面试了一个候选人,他的工作是从事票务系统开发,他说自己在研究linux 内核与汇编语言,我就问他 linux 内核和汇编语言的学习对你的工作产生了哪些帮助?能否举一个例子?他哑口无言,我内心就觉得这样一个热爱学习的好苗子正迷茫找不到重心,正在做一件浪费精力的事情。正确的学习方式应该是将学习与具体业务场景结合起来,和公司通过软件系统开展业务服务而创造价值,程序员通过提升软件系统服务能力创造价值这一链条串接起来,从对这些价值产生帮助的程度去思考优先级。学习本身没有错,错的往往就是那颗初心。现在你再来看高并发分布式相关的知识,你会发现并不是因为这些知识
24、比较高深、比较时髦,很多公司有需求才值得学习,而是他们对价值链条有着实实在在的贡献。价值驱动的架构一谈到软件系统,人们免不了想起架构这件事来。之所以此处去谈及架构是因为每一个程序员本质都是软件架构体系中的一分子,我们可能深埋于体系流水线之中,感受不到位置和价值。但如果站在架构这一高度去看这些问题则将会非常透彻。那么架构究竟是什么?和上述的价值链又有什么关系呢?什么是架构?在我看来软件架构就是将人员、技术等资源组织起来以解决业务问题,支撑业务增长的一种活动。可能比较抽象,我想我们可以从架构师的一些具体工作任务来理解这句话含义:阿里技术人生阿里技术人生他非常关心软件的运行状况。因为只有在软件系统运
25、行起来后,才能对外提供服务,才能在用户访问的过程中,解决业务问题。架构师需要关注运行过程中产生的数据比如业务成功率,系统运行资源占用数据、用户反馈信息、业务增长情况等,这些信息将会帮助架构师制定下一步架构目标和方向。所以软件架构不仅仅只是选用什么框架、选用什么技术组件这么简单。它贯穿了对人的组织、对技术的组织、对业务的组织,并将这三种组织以解决业务问题这一目标有机的结合在了一起。很多面试的候选人在被问及他所开发的系统采用什么架构的问题时,只会罗列出一些技术组件、技术框架等技术要素,这样看来其根本没有理清架构的深层含义。也有一些架构师只专注对底层技术的研究,以为打造一个卓越的系统是非常牛逼的事情
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 不止 代码 阿里巴巴