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、行起来后，才能对外提供服务，才能在用户访问的过程中，解决业务问题。架构师需要关注运行过程中产生的数据比如业务成功率，系统运行资源占用数据、用户反馈信息、业务增长情况等，这些信息将会帮助架构师制定下一步架构目标和方向。所以软件架构不仅仅只是选用什么框架、选用什么技术组件这么简单。它贯穿了对人的组织、对技术的组织、对业务的组织，并将这三种组织以解决业务问题这一目标有机的结合在了一起。很多面试的候选人在被问及他所开发的系统采用什么架构的问题时，只会罗列出一些技术组件、技术框架等技术要素，这样看来其根本没有理清架构的深层含义。也有一些架构师只专注对底层技术的研究，以为打造一个卓越的系统是非常牛逼的事情
26、，可是他忽略了软件系统的价值是以解决业务问题的能力、支撑业务增长的能力为衡量标准，所以最后生产出了很多对组织，对业务没有帮助的系统。成本与收益阿里技术人生阿里技术人生另外一点比较深刻的案例则是在本人担任一个技术团队负责人的时候，在一次述职报告的时候，leader 问我对接下来团队工作有什么计划？我当时说了一堆什么改进代码质量，每天晨会，任务透明化，建立迭代机制等等，然后就被各种批驳一通。当时团队基本以外包人员为主，人员水平较差，开发出来的金融系统也是千疮百孔而这条业务线最重要的业务价值则是按计划实现潜在投资方的需求，争取拉到投资。所以不久 leader 就召集测试架构的相关人员与我这边一同梳理
27、对核心功能的测试工作，将研发、测试、上线的流程自动化。当时并不理解这样做核心价值是什么。但回过头来看这样的工作方式恰好符合了业务发展的需求，即确保系统是符合设计需求的，保证系统达到可接受的正确性，为后续能过快速前进打下基础，最重要的是为企业降低了构建成本。所以程序员想要工作出业绩，必须认清楚系统背后的业务价值，按价值去梳理工作优先级，而不是像我一般过度纠结细节，追求技术理想化。成也分工，败也分工正如在程序员的迷茫那一章节提到的：程序员的迷茫因为长期埋没于软件世界的浩大的分工体系中，无法看清从业务到软件架构的价值链条，无法清楚定位自己在分工体系的位置，处理不好自身与技术、业务的关系所致，所以在这
28、里我想谈谈分工。架构师为了使软件系统更好的服务业务，必然将软件系统生命周期进行拆分，比如分出开发生命周期、测试生命周期、用户访问生命周期、软件运维生命周期，并根据不同的生命周期划分出不同的职责与角色。阿里技术人生阿里技术人生从价值出发找寻学习与工作的新思路迷茫能引发思考，架构则塑造了视野，而价值则是我们之所以存活，之所以工作的逻辑起点。基于这样一种价值思维，对我们的学习和工作又可以有哪些改启示呢？明确自身的业务相关主体：找出你工作的协作关系网内的业务方和客户方，这样你就可以从客户方中找到离你最近的业务价值点，从你的业务方中挖掘更多的资源。甚至你可以按这个思路顺着网络向上或向下挖掘价值链条，整合
29、更多的上下游资源以实现更大的价值。向前一步，为更大的价值负责：不要因为自己是开发人员就不去关注软件运维，不要因为只是测试就不关注软件开发，因为你关注的越多你越能看清全局的价值目标。如果只关注一亩三分地，那么注定这辈子只能困守在这一亩三分地里，成为一名流水线上焦虑至死的码农。试着转变思维，从架构师的角度思考价值问题，看看能否将技术贯穿到业务、到用户、到最终的价值去。之前我的朋友说过要把产品经理踢到运营位置去，把程序员踢到产品经理位置去，这样才是正确做事方式。这句话也是类似的意思，向前一步才能懂得怎么做的更好。阿里技术人生阿里技术人生加班越久故障越多，如何跳出程序员的恶性循环？冠楠阿里妹导读：如何
30、让每一位可爱的工程师少加班、不加班？阿里巴巴技术专家张冠楠，在质量保障体系建设、持续集成领域、敏捷实践领域和研发效能领域方面具有丰富的经验和心得。今天，冠楠将用阿里研发团队的实际案例，生动说明如何用数据驱动研发效率提升。本文是我利用云效公有云度量功能，加上敏捷部分的方法指导，实践于某事业部几十人团队沉淀的成果，希望能给大家一些借鉴意义。我会就各种具有关键表征的数据进行介绍，但是详细数据，包括具体研发团队的数据，还需要访问云效公有云度量功能页面。注：本文图片数据来自云效度量数据功能，有兴趣的童鞋可点击文末“阅读原文”了解更多。阿里技术人生阿里技术人生于是我们带着数据暴露出来的这几个问题，和团队一
31、线研发人员、PD、TL 进行沟通，分析数字背后的意义。大家很快达成一致，发现团队存在的主要问题是：需求 deliver 传统瀑布模型，要 1 个半到 2 个月去完成一个特别大的需求，最后却和用户期望偏差较大，数据表征上就是之前需求数量较少，3 月份突然完成了很多而且时间很长的需求。大家加班加点干活，负载较重，引入的缺陷也较多，PD 和用户不满意带来的修改又会加重工作量，如此恶性循环。缺陷重视度不高，管理不规范，优先级划分不清楚，甚至残留重要缺陷，留在bug 列表里未解决而流到了线上引发故障。上面三点形成了恶性循环，结果就是越做越多，越多越错，越错越改，越改越多。解决方案落地和数据运营发现问题之
32、后，有针对性的进行解决和落地就相对容易，我们给到团队的解决方案是：需求细化：拆分成最小可交付产出，尽量避免一个需求做了 1 个多月，才去找PD 和用户验收。随时拥抱用户：迭代式产出，交付即验收，让不准确性降到最低，在错误误差最小的时候修正。重点跟进质量管理和运营：透明数据，鼓励团队尽早尽快修复 bug，并有严格的上线前 bug 解决率标准。尽全力保证线上发布成功率。同时辅助于团队的决策，我们进行定期的数据运营，每周都会去统计和分析数据，包括质量和效率相关的，确保我们能在第一时间发现问题，纠正偏差。所以在 3个多月的时间里，我重点关注了如下数据。关于这些数据的解读和分析，内容比较深阿里技术人生阿
33、里技术人生总体而言，就是需求交付的快，得到的反馈快，修正错误/缺陷的成本低，缺陷也慢慢收敛，质量也随之提升，缺陷修复的也快了，这就是一个良性循环，概括总计就是：效率提高了，质量也保证了。团队的人干活也是更加努力啦！如何进一步提升？根据对需求数量以及平均完成时长的数据显示，团队还是有上升空间的，对于需求的交付粒度和速率上，还是略显波动，要想更快的知道我们做的是否是用户需要的，就要快速的、迭代式的交付需求，以免用户想要个车，我们给了他 4 个轮子。所以能否彻底解决此团队需求的交付和用户期望偏差的问题，还是需要再向前走一步，需求继续细化，提升交付速率。参见敏捷中推荐的，快速迭代，快速交付，快速得到用
34、户反馈，只为了更快更准确。总结数据有魅力，研发数据也一样，我们使用它就是为了两个目的：一是保证质量；二是确保交付的速率。行走过程中深度使用了云效度量新功能，结合敏捷中部分理念，配合传统测试方式保障，来助力研发团队。阿里技术人生阿里技术人生另外缺陷的解决时间也没有加快，这样会导致越来越多的缺陷流到线上去，可见团队除去 1 月份无故障，后续几个月都有故障。而且这个团队的线上发布成功率持续走低，开发对上线的代码把控程度较低。所以，找到这些数据表征的背后原因，并且着手去解决掉，是这个团队近期最迫切的事情了。养成良好的研发习惯，保持高效的团队协作，应该是每个研发同学持之以恒的追求。阿里技术人生阿里技术人
35、生招聘的目的当今社会，技术已经成为影响商业成功的关键因素，工程师成为了这些公司最宝贵的财富，没有优秀的人组成团队来完成商业目标，公司根本不可能有今天的成就。所以招聘，就是选择最优秀的人。招什么样的人？招优秀的人显然是一个很模糊的概念，我们来度量的时候，我个人认为三个因素是最关键的：技能工作项目经验，以及解决疑难问题的能力，毕竟招来的人首先必须很好的完成工作，这是最基本的要求，注意，是很好的完成，不是仅仅完成。潜力这个概念看起来比较模糊，其实还是比较容易评价的，对计算机相关的专业的知识体系是不是完整，基础是不是扎实，平常是不是喜欢钻研，对这个世界充满好奇心，这几年走下来，沉淀的速度如何，都是判断
36、一个人的潜力的方式，注意我们看潜力主要是基于候选人的之前的成长经历实事求是来看，过去的优秀经历才能给未来背书。潜力和技能的重要性一样重要，我们不能只看眼前，团队是需要不断发展和前进的，所以我们招人应该面向未来。软实力软实力这里其实包含了性格，执行力，领导力等方方面面，它代表了候选人是否能快速融入团队，拿到结果，带领团队攻城拔寨，激励和影响身边的人变得更加优秀等等，软实力一般 HR 肯定会考察，虽然技术面不会特别去关注，但是从面试的过程中可以看出候选人的沟通能力，以及性格相关的特点，也值得我们注意。说了这么多，其实在招人上有一个对比的标杆，就是你招的人是不是比团队中同一等级中 50%的同学优秀，
37、如果你觉得没有他们优秀，那不用纠结，这个候选人不要了，团队必须不停加入更好的同学，才能变得更加强大。阿里技术人生阿里技术人生面试应该做的事 问已经发生的事情比如面试移动开发者，面试官应该认真看下其做过的 App，具体的工作是什么，准备一些相关的问题，这里就可以看出来之前工作中的积累是什么，有多深。问题解决思路针对项目经验和一些学习的经验上面，应该问拿到问题以后解决思路是什么，在什么场景下为什么这么做，这里根据面试者的方案，分析的方法论，就可以大致了解面试者是否聪明，知识面是不是够广，遇到问题时会不会举一反三。具体可以举个简单的例子，很多同学说自己做过架构，然后都会讲自己做了一个解耦和分层的框架
38、，其实这类框架 iOS 很多，外部 github 上就有各种方案。在阿里内部手淘早先做的 bundle 拆分时沉淀的容器规则，天猫开源出去的 beeHive，闲鱼内部的 Xframework，抑或是服务端的 spring mvc，其实都实现了 IoC，但实现和思路上都有一些差异，到底为什么这么做，其实是有区别的，这里面就可以看出知识广度，总结和思辩能力，在关键路径上的技术判断。又比如说，我们总在强调性能稳定性怎么做，业界也有很多方案，到底哪个方案更好呢？答案没有绝对的对错，取决于某个时间点和场景下哪个问题是最核心的突破点，而你的选择标准和落地的技术方案是不是合理（考虑成本，收益，以及后续的风险
39、是什么）。一般来讲，我们更倾向于用系统化的思维看待一个问题，也就是说，相比根据人的经验去识别性能瓶颈，我们更希望能通过自动化，智能化，数据化的方式去解决问题。少问多听一般刚开始做面试官的同学很喜欢以问为主，但因为大家的知识体系不太一样，成长环境也不同，直接这么问起来很难就找到面试者的优点，所以尽量让应试者自己陈述，然后以学习和交流的心态针对陈述中存疑的地方再进行发问，会更容易让应试者放松，也更容易让应试者更全面的表达自己。另外，问的差不多的时候，结尾的时候可以补充一句：您觉得刚才的面试中还有哪些我没问到的，您想再补充一下的内容？末了，再问下：我的问题问完了，您有什么想要问我的吗？阿里技术人生阿
40、里技术人生果只是看思路还好，但是如果说的天花乱坠，这个时候要警惕了，毕竟说和做之前的差异是很大的。对于假设的事情，面试官是没法评估具体效果的，因为它不像过去已有的项目和工作内容，是有明显结果的，如果对过去结果存疑，后续也可以背调了解具体的情况。针对假的 STAR，我们要甄别分辨出来，引导其表达出真正的情况。鉴别方式 更多的关心 What/How/Why做了什么事情，具体做的方案 1234 几步，为什么要这么做，比如图片的优化，最早肯定什么都没有，后续加 cache，cache 策略又可以升级，包括 cache 本身的算法以及多级 cache 的实现，图片尺寸上面后来有做了什么裁切之类的，图片格
41、式上面后续又做了优化等等。每个阶段不太一样，关注的重点也不一样，刨根问题问一问，会了解是不是真的做过这件事情，另外有一些可能项目做得很久说很多东西忘了，这里我分享一个观点，之前看过一句话，招聘的人中有一种人是比较好的，他总能比较清楚的记住过往阿里技术人生阿里技术人生技术人如何不断成长？招聘，培训，人才选拔晋升，我认为评价标准和方法都应该有比较多的重合的部分，我们从刚才的面试经验中，反思下，如果现在是我们去找工作，这个市场或者团队更需要什么样的人？经验丰富，知识体系完整经验能解决实际的问题，另外知识体系可以让你在遇到新的问题时举一反三，当然大公司和小公司要求的知识体系又不太一样，大公司更偏向一专
42、多能的 T 型人才，小公司更喜欢全栈，所以到底要成为什么样的人，跟你的职业规划很有关系，是想在大公司成就一番事业，还是出去闯荡，那你点的技能树肯定是不一样的。到底应该怎么做，我自己的经验是，找到身边的标杆，向更优秀的同学学习，在阿里当然非常优秀的专业人才也好，架构师也好，都非常多，所以标杆应该也好找，业界当然也有很多成功的人，有了标杆，就努力向上吧。阿里技术人生阿里技术人生使用开源项目的正确姿势，血和泪的总结李运华阿里妹导读：开源精神是技术发展的源动力之一，受到工程师们的热烈欢迎。但是开源项目如此之多，哪一个最适合自己？如何更好利用开源项目，甚至做二次开发？今天，阿里资深无线开发专家李运华，总
43、结多年与开源项目打交道的经验，讲述如何正确利用开源项目，希望对大家有所启发。软件开发领域有一个流行的原则：DRY，Don t repeat yourself，我们翻译过来更形象通俗：不要重复造轮子。开源项目主要目的是共享，其实就是为了让大家不要重复造轮子，尤其是在互联网这样一个快速发展的领域，速度就是生命，引入开源项目，可以节省大量的人力和时间，大大加快业务的发展速度，何乐而不为呢？然而现实往往没有那么美好，开源项目虽然节省了大量的人力和时间，但带来的问题也不少，相信绝大部分同学都踩过开源软件的坑，小的影响可能是宕机半小时，大的问题可能是丢失几十万数据，甚至灾难性的事故是全部数据都丢失。除此以
44、外，虽然 DRY 原则摆在那里，但实际上开源项目反而是最不遵守 DRY原则的，重复的轮子好多，尤其是歪果仁，一看哪个开源方案不爽，自己就吭哧阿里技术人生阿里技术人生我们在选择开源项目的时候，一个头疼的问题就是相似的开源方案较多，而且后面的总是要宣称比前面的更加牛逼。我们在选择的时候有点无所适从，总是会担心选择了 A 方案而错过了 B 方案，或者反过来。这里我们的经验是聚焦于是否满足业务，而不需要过于关注开源方案是否牛逼。案例：当时尝试一个社交类业务时，我们发现了 TT（Tokyo Tyrant）这个开源方案，觉得既能够做缓存取代 Memcached，又有持久化存储功能，可以取代MySQL，很牛
45、逼，很高大上，于是就在业务里面大量使用了。但后来的使用过程让人很蛋疼，主要表现为：1.不能完全取代 MySQL，因此有两份存储，设计的时候每次都要讨论和决策2.功能上看起来很高大上，但相应的 bug 也不少，而且有的 bug 是致命的，例如所有数据不可读，后来是自己研究源码写了一个工具才恢复了部分数据。3.功能确实牛逼，但需要花费较长时间熟悉各种细节后来我们反思和总结，其实当时的业务 Memcached+MySQL 完全能够满足，且大家都熟悉，当时的业务完全不需要引入 TT。简单来说：如果你的业务要求 1000 TPS，那么一个 20000 TPS 和 50000 TPS的方案是没有区别的。有
46、的人可能会担心我 TPS 不断上涨怎么办？其实不用担心，我们的架构会不断演进的，等到真的需要这么高的时候我们再来架构重构，记住：不要过早优化，过早优化是万恶之源 UNIX 编程哲学聚焦是否成熟很多新的开源项目往往都会声称自己比以前的项目更加牛逼：性能更高、功能更强、引入更多新概念。看起来都很诱人，但实际上都有意无意的隐藏了一个负面的问题：都更加不成熟！不管多牛逼的程序员写出来的项目都会有 bug，千万不要以为作者牛逼就没有 bug，Windows、Linux、MySQL 的开发者都是顶级的开发者吧，一样很多 bug。不成熟的开源项目应用到生产环境，风险极大。轻则宕机，重则宕机后重启都恢复不了，
47、更严重的是数据丢失都找不回了。还是以上面提到的 TT 为例：我们真的遇阿里技术人生阿里技术人生用：如何使用开源方案？深入研究，仔细测试很多人用开源项目，其实是完完全全的“拿来主义”，看了几个 Demo，把程序跑起来就开始部署到线上应用了。就好像看了一下开车指南，知道了方向盘是转向、油门是加速、刹车是减速，然后就开车上路了，其实是非常危险的。案例：我们有团队使用了 elasticsearch，基本上是拿来就用，倒排索引是什么不太清楚，配置都是用默认值，跑起来就上线了，结果就遇到节点 ping 时间太长，剔除异常节点太慢，导致整站访问挂掉。案例 2：很多团队最初使用 MySQL 的时候，也没有怎么
48、研究过，经常有业务部门抱怨 MySQL 太慢了，其实经过定位，发现最关键的几个参数（例如 innodb_buffer_pool_size,sync_binlog，innodb_log_file_size 等）都没有配置或者配置错误，性能当然会慢。可以从如下几方面进行研究和测试：1）通读开源项目的设计文档或者白皮书，了解其设计原理2）核对每个配置项的作用和影响，识别出关键配置项3）进行多种场景的性能测试阿里技术人生阿里技术人生即使我们前面的工作做得非常完善和充分，也不能认为就万事大吉了，尤其是刚开始使用一个开源项目，运气不好的话就可能遇到一个之前全世界的使用者从来没遇到的 bug，导致业务都无法
49、恢复，尤其是存储方面，一旦出现问题无法恢复可能就是致命的打击。案例（此案例是听说的）：某个业务使用了 MongoDB，结果宕机后部分数据丢失，无法恢复，也没有其它备份，人工恢复都没办法，只能接一个用户投诉处理一个，导致 DBA 和运维从此以后都反对我们用 MongoDB，即使是尝试性的。虽然因为一次故障就完全反对尝试是有点反应过度了，但确实故障也给我们提了一个醒：对于重要的业务或者数据，使用开源项目时，最好有另外一个比较成熟的方案做备份，尤其是数据存储。例如：如果要用 MongoDB 或者 Redis，可以用MySQL 做备份存储。这样做虽然复杂度和成本高一些，但关键时刻能够救命！改：如何基于
50、开源项目做二次开发？保持纯洁，加以包装当我们发现开源项目有的地方不满足我们的需求的时候，自然会有一种去改改的冲动，但是怎么改是个大学问。一种方式是投入几个人从内到外全部改一遍，将其改造成完全符合我们业务需求。但这样做有几个比较严重的问题：1）投入太大，一般来说，redis 这种级别的开源方案，真要自己改，至少要投入2 个人，搞个 1 个月以上2）失去了跟随原方案演进的能力：改的太多的话，即使原有开源项目继续演进，我们也无法合并了，因为差异太大。所以我们的建议是不要改动原系统，而是要开发辅助系统:监控，报警，负载均衡，管理等。以 Redis 为例，如果我们想增加集群功能，不要去改动 Redis
个人主页
