006_饿了么大前端总监sofish帮你理清前端工程师及大前端团队的成长问题！

做者｜Sofish编辑｜小智 & 尾尾本文是前端之巅向 sofish 的约稿《什么样的人能够称为架构师？》、采访《 饿了么大前端团队到底是如何落地和管理的?》以及 sofish 作客大咖说直播节目的总结和整理，但愿能帮助各位淀粉更清晰地理解 sofish 的观点。获取大咖说视频下载连接，请关注前端之巅并回复“鱼老板”，查看饿了么大前端更多实践请回复“饿了么”。视频回顾

 

程序员成长之：跨界、困惑与架构师1. 如何看待“大跨度入行编程”——跨界程序员？

从个人角度来讲，角色的变换，是一个从兴趣到职业的过程。兴趣可能持续一段时间就再也不感受兴趣了，就放弃了，但职业不同，是担起的担子，是对一群人包括本身的一种责任，有些事不喜欢不只得作，还要作的漂亮。

从法学院出来当程序员其实并无想象中那么难 。在学校那段时间，晚上常常一写代码就忘记时间，看到外面天亮了才睡觉。从不知道如何压缩 PNG 到解决编码上的问题。那时候彷佛不须要技巧，一切都是新的，每一个点都是新的，凭着一股单纯的热爱去学习，通宵所感觉到的不是疲惫反却是一种享受。但工做了，要作好却并不像入门那么简单。一方面是兴趣消退，一方面是工做并不能像兴趣同样只作本身喜欢的事，也不能随意创做，须要按照画好的 UI 和预约的 UX 来作。因此开始须要一些技巧，或者说一些工做的信条。

工做信条方面。到如今还印象很深入的是，刚工做那会对于任务的第一感觉是「这个网站究竟要作到几时才会停下来?」，一切都彷佛没有终点，人也在工做中变行焦虑起来。这是很难受的一件事。万幸的是，多方的影响，从完成一件任务的心态慢慢变成如何打磨一个拿的出手做品。这也是如今一直在实践的一个技巧：一方面要求本身不仅是简单地去完成一个任务；另外一方面是不要只跟同事作比较，写文章、开源代码、出做品接受更多人的挑战。

年轻的时候一直有一个疑问没有解开：人与人之间能力是否真的相差十倍甚至百倍千倍？由于武侠小说或者电影里的英雄一般能以一敌十，而现世生活中人与人之间积累的财富更是有巨大的差异。后来慢慢解开，正常状况也是，社会资源的流向老是倾向那些准备多一点点，优秀多一点点的人。好比学习成绩好会加分，加分会考上更好的学校，好学校会获得更好的教学环境和更优秀的同伴，诸如此类。

工做也同样，作的多承担更多责任，承担更多责任得到更多回报。除了工做三年积累二十万拿着爸妈给的六百万全款买了上海中环内的房子这类非正常的方式外，能者多劳、多劳多得这种套路一直没有变过。

从学习方法来讲。入门一个新领域都会挑选一本比较系统的书来看，读懂后开始动手作一个相关的项目。好比 CSS 看《精通 CSS》，JS 我会推荐《Pro JavaScript》，设计有一本叫《写给你们看的设计书》是一本不错的入门书，后来学 SQL、PHP、Go 同样，刚转到管理岗那会也是看了好几本管理书边学边用。彷佛总能获得不错的结果。

关于如何从非科班生变成技术总监。你们的方法都不一样，但有一点必定是相同的 —— 不设限。若是你们只见解学方面的书，就不会写代码，天然不会成为程序员更别说技术总监。前端能够学点设计，天然也能够学后端，甚至操做机器。去年得了公司的管理奖，算是对本身管理上的阶段性确定。所以上半年给本身定了个目标是看懂财报，学习从会计的角度是如何看公司的。

2. 如何看待“编程终极目标”——架构师？

我曾问过不少自称热爱代码的程序员的发展规划，大多都回答说指望成为一名架构师。而在招聘一方，有的团队会过滤掉屡次提起架构一词而一点不提具体内容的简历。可见，虽然在大多数程序员眼里，架构师是神圣的，但又不得不认可事实是：“架构”和“架构师”是最常被滥用的。那些写能 PPT 而不能写代码的人，只作和事佬而不考虑软件快、稳、便捷的人，都称不上作“架构”更别提“架构师”。

那么什么样的人能够称为“架构师”？

据称架构一词源于建筑行业，架构师这个职位，无论是前端仍是后端，职责是相同的。而用规划一次房屋的装修来描述架构师这个职位的职责是很是合适的。

创建一套 Web API 就像在定装修风格。要选择注重重 CRUD 的 RESTFul 式，仍是请求自定义性更强的 GraphQL 式，又或者是简单的 JSON-RPC 式，这就像装修风格是选要简洁的日式、粗犷的美式仍是奢华的欧式。定方向和选型这件事无处不在，架构师必须根据实际需求，作各类决策，为后面各部分总体结合打好基础。

灯光、墙面、家具等各个部分都须要根据风格精心设计、执行和不断修正，才可能达到原定目标，架构也同样。拿光线控制来讲，施工人员可能会忽略你注重的一些细节：暖色的书房氛围；明亮且能切到影院模式的客厅；装在合适位置才不会刺眼的背景灯。在每一个环节的执行上，架构师既要设计，又要保证对每一个角色充分理解，必要时不排除动手编写重要环节的功能，而在经验或考虑不足的点上一旦出现问题就必须迅速调整。空有一个好的设计而没有好的执行，是很是让人可惜的。

值得一提的是，选用最好的卫浴用品、最贵的过滤器并非得到最佳洗浴室体验的关键点。一样，软件架构并非说把每一个部分作到最好再拼凑起来就能达到佳效果。最好洗浴室体验的关键点在于折中和妥协。例如，在水压不是特别高的状况下，把过滤器安装在总闸虽然能让用水达到最健康的状态，但会致使淋浴的水压不够，进而使体验大打折扣。把过滤器安装在厨房出水口多是最佳的平衡，既保证水压又保证了用水的健康。分红多个部分是解耦，而协做的平衡是内聚。低耦合、高内聚是架构师处理软件各部分协做的终极目标。

装修有不少细节，例如，若不喜欢晾衣服且生活在有“黄梅天”的上海，可选洗烘一体机；房子面积不大，可选扩展型家具；对通风质量要求比较高，可安装新风系统。软件架构也须要考虑不少细节，例如客户需求、实际环境、技术可用黑科技之类、安全、重用、扩展等。而这些细节方面的考虑，并非一个刚入门的新人能作到的。

总的来讲，称得上架构师的人，必须是具有丰富系统设计经验且能保证设计执行的设计师和决策者；必须参与设计、开发执行和测试但又不局限于一个角色。也许架构师并不必定全是这样，这仅表明我的见解和指望。

3. 如何解答程序员的成长困惑？跳槽如何选择？

跳槽这件事我并无什么话权，祼辞和看缘分彷佛是我一直的方法，固然谈薪资也同样，因此不止一次被老婆说根本不懂得如何去赚钱。不过从选择团队上，我有一个不错的建议，也是我本身选择的底线，两种团队：一是选择喜欢的一个产品；一是选择一个有趣的团队。

选择一个喜欢的产品。若是你喜欢饿了么让全世界都足不出户就能够享受各类美食，那么有什么理由不加入？工做就是人生追求这件事，简直梦寐以求。喜欢一个产品老是很直接的，因此选择起来很是简单。

为何要选择一个有趣的团队？一个被业务缠身的团队是没法有趣的，没时间；一个没有水平的团队是没法有趣的，烂事一堆都焦头烂额了，哪来有趣？有趣的团队必定是好玩的，且热爱生活的，这样的团队一般不只能够学到新的酷的，还会获得一群有趣的朋友。但如何判断一个团队是否有趣呢？看他们的做品，是否是老是为了生活更简单，好比喜欢自动化，喜欢抽象，交互简单且有效等等；或者看他们是否有很特别的方式在玩，好比找个海岛、包个酒吧之类，或者去深山里玩狼人杀。

不管是否有这样的团队，我以为有一点比选择更重要的是，成为一个某个产品或团队由于有你而变得更好的人；若是没有这样的产品或者团队，那么个人方式是 —— 创造一个。

技术和管理如何互转？

关于技术和管理如何互转上，不少人以为因人而异，照本身的喜欢的来选就能够了。作了这么久的技术，转到管理岗于我，就像从法学院毕竟转身成为程序员同样，是一个新的挑战，当时义无反顾接受。若是你也同样，碰到一些两个单选均可以的状况，照个人见解是，既然生命只有一次为什么一直重复作一样的事。事实上，每次选择的结果彷佛都还不错。

顺路分享一个有趣的心路历程。上上周人在美国 LA，当时第一次在那边开车，陌生的 JEEP 大切诺基、山路、晚上，而且中间被警察拦下来过一次，不过这些都不重要。重要的是在公路上你们都开的超快，当时我也开的特别快，朋友说刚想睡就被我一个弯就愰醒了。过后你们都以为我开车真的有点太吓人。而当时内心却只有一句话 —— 若是一切都在掌控之中，说明一切跑的并不足够快。若是生活老是在掌握之中，说明咱们跑的并不足够快，甚至只是原地踏步。

其余就不说了，分享一个初作管理的心得和一个成就优秀团队的重要的策略。

心得。你们均可能摸清了套路，写代码你只要作的比预期多一点点，代码写的抽象一点点，你们都会开始叫你大神，说你就是那样棒棒的。因此作管理的时候，碰到别人不会的问题，你一般过会想 —— 「走开，让我来」。千万别这样作！无论你懂或者不懂这句话的真正涵义，千万别这样作。而后，你就会开始获得不少很好的助手。这个就很少解释了，有些事能够边学边作，越受打击越强大。

策略。永远不要静止地看团队，特别是在招人上。什么叫静态地看待团队？举个例子，有多少业务申请多少资源，而后业务永远都在原地踏步，团队永远在只是一个创建时同样的团队。个人策略是这样的，一方面半年前与半年后招聘同一级的人必定要比原来的要求更高，且重点挑选团队缺乏的人才；一方面看半年到一年后但愿变成一个什么样的团队，而去作相应的 5% 左右的人才储备。看似浪费资源，但长远来看，相比由于招不到人支持不了业务的时候才是真正的浪费。

统观大前端之概念及团队落地4. 如何看待大前端的概念？

大前端一般是指全部客户端，由于会有 Native App 和 Web 两个前端；另外还泛指不只仅是负责静态内容，而是向后端扩展负责更多的内容，好比除 Model/DB 层之外都称为前端。简单来讲就是前端及接受前端的层。方面其实不是很重要，若是喜欢跟 UI 打交道，那么选择大前端就没错了。

在参加大咖说的直播过程当中，有观众问到一个问题 —— 前端会消亡吗？从社会分工的角度来讲，彷佛目前仍是比较稳定的职位。但现实世界变化特别快。之前咱们看父母辈均可以在一家公司工做上 二、30 年，而今一家公司是否能存活这么久仍是一个问题，几乎能够说，这个世界上惟一不变的就是变化，并且愈来愈快。因此不管选择什么方向，一方面尽力作到最好；另外一方面不要给本身设限，去接受更多挑战以提高本身；这样多是比选择一个方向要更靠谱的方法。

5. 饿了么大前端团队的定位是什么？（1）为何叫“大前端”团队

大前端这个词最先是由于在阿里内部有不少前端开发人员既写前端又写 Java 的 Velocity 模板而得，而咱们部门成为之初所承担的内容不只仅是前端，还包含 CDN 和 Nginx 层，因此取名“大前端”。时至今日，你们所说的大前端已经包含了前端、Node、Native-Like (Hybrid / Weex / RN)，甚至包括 Native App 开发。

（2）我所理解的“大前端”

在我看来，“大前端”是一种变化形态多过于固定的职责范围，是“前端”职责范围的延伸，是对这个社会分工由于能力范围和所以所达到效率提高的一种进化形态。给你们分享个小道消息：CTO 曾屡次开玩笑说 —— 大家负责的已经不只仅是前端，要不就更名“大全栈”吧。这部门的名字很霸气但同时也过高调，全部并无接受 BOSS 的提议，而是继续沿用“大前端”这个部门名。

（3）饿了么大前端团队的职责

如上面所说的，除了纯 iOS / Android App 的开发，其余都是咱们团队职责所在，同时咱们还负责公司 HTTP API 层，有一些本身运维的系统。

从分工来讲来，目前咱们有架构与机动组负责框架、规范、工具的生产；Node 研发团队负责公司 Node 业务的基础设施和业务支撑；多个业务前端团队支持不一样的 BU 前端。这里值得一提的是，架构与机动组会对每一个业务团队至少派出一名架构师长期、深刻地了解业务团队所遇到的问题并反馈到架构团队，并在解决方案提出后协助推进。

在具体职能分工以外，各团队也有以项目而组织起来的虚拟团队，好比由咱们部门负责的“游戏中心系统”就由 Node 研发团队和架构与机场组中的成员组成；又如小程序团队；亦如发起一次由“93 后”独立组织的招聘；专栏编辑团队、官微小分队、对内对外分享会小分队，等等。除了你们看到的开源产品，内部的全部项目都是“内部开源”，特别鼓励你们提 Pull Request 和相互 Code Review。这些与部门所建立的文化息息相关，且如你可能猜到的，大多合做都是一旦有人提出，即自发组队。

6. 饿了么大前端如何看待和落地新技术？

咱们是如何看待新技术的？在面试前端 Leader 候选人的时候，我一般会问一个问题：你如何看待技术债，有没有办法能够避免？几乎任何程序员都讨厌还技术债，因此才会有那句“挖坑一时爽，填坑火葬场”。由于痛苦才会很是值得咱们去思考和解决。技术债从某种程序上表明着过期的技术，而新技术也将在将来某个时刻变成新的“技术债”。饿了么大前端是如何回答这个问题的？就是咱们对新技术的见解。

我 2014 年加入饿了么，那会 PC 和 Mobile 都仍是后端渲染的模式，使用 Bootstrap 和 jQuery。我进去的 第一件事是用 Angular.js 重写移动网站，而且前 / 后端分离，提倡后端即服务。在高速发展期利用移动网站支撑了当时 10 倍增加的业务；第二件事是重构 PC 站，把 web2 升级到 web3（Code Name），一样是先后端分离，到 14 年末 15 年初，基本实现彻底分离。重构一方面是提升前端协做的效率，一方面是提高两部各自的掌握力 —— 只要 API 约定一致，内部封装能够本身随时变动（提高）。在此以后，咱们的方向一直是比较激进的技术模式 —— 新业务能够用任何框架，你们自由选择；旧业务只要负责团队（人）有能力升级，那就鼓励用最新的。因为后端已经彻底分离出去，因此从掌握力大大提高，加上这种受鼓励的激进技术模式，Angular.js 1.x 这种当年的新技术在日渐变成技术债的今天，也已经几乎全被重写成 Vue.js 和 React.js。

固然，也像今天你们能看到的，当你们都还在转发关于 PWA 文章的时候，咱们已经和 Google 合做并把 PWA 上线；开源的项目大可能是内部成熟应用的项目，而开源的产品亦让咱们成为 Vue.js World Ranking 最高的团队；Weex 方面，咱们是除阿里内部团队外最先上线的大型用户。这些看起来快速和无止追求新技术的背后，其实并无你们想的那么了不得，仅仅是由于团队文化自己就鼓励利用新技术解决问题。

若是必定要拿 Vue.js 来举例，可能和你想象不同的是，不用“落地”，仅仅是由于有人说了一句“WOW，Vue.js 写起来好简洁啊，你们要不要一块儿来试试？”。而后，一个团队，两个团队... 几乎全部团队都开始应用，几乎全部新项目都在用。一位 IBM 的朋友告诉我，他申请在项目试用 Vue.js，上级说在半年后试用，结果半年后又被推翻了。因此你看，在合适的文化土壤里新事物就是一种常态，若是作一个项目用什么技术还要上级主管肯定“能不能作”，那自己就不是一件简单的事。

咱们 对于技术选型一般来讲要求是 —— 是否提高饿了么运行的效率或者团队开发的效率？是否能 hold 住？有没有人负责到底？符合这样的条件，就会被推进。当你们都在说 HTTPS 是好东西的时候，咱们已经推进全网上线，诸如此类 —— Webp、Https、Vue.js / React.js / Angular.js、Weex、PWA 都是如此。好比你们可能去年就关注到咱们在上线 HTTP/2，而今天饿了么大前端内部已经作过 HTTP/2 Server Push 的实验，能够想象在不久的未来，线上应用将会大面应用。这就是咱们的选型和落地模式。

7. 饿了么大前端团队的特点是什么？

特点？若是只用两个字来回答就是 —— 散养。但仅仅这样描述你们会一脸问号。外部对咱们的评价是：“新技术跟进好快啊”、“怎么又又又出去玩了”、“下班很早”、“好多大牛啊”、“开源的东西得到好多星星啊”，诸如此类，但这不是咱们要特意我呈现的，只是一种表像，或者说是一种副产品。

一个团队的风格与创始人有很大的关系，好比喜欢愉懒的我会更多考虑自动化；又若有洁癖因此会有代码规划和 Code Review；还有你们看到的爱玩，因此会常常有团建、下午茶这样的文化；但另外一方面，我并不想让团队仅仅是和我同样有你们喜欢的，同时充满缺点，而但愿是不断尝试的，兼容并包的，让每一个人的闪光点都成为集体中有特点标志的。因此我有本身的一套，就是前端所说的“散养”式管理，提及来可能会很大，重点说几点：

1. 招聘最好的人。最好的人不是业界里的全部明星，更重要的是 能从某方面给带队带来提高的人。这些人一般自驱能力强，只要有一个方向就能推进事件的发生和发展。加入的人会被要求不要以学习姿态加入这个团队，而是以加入会让这个团队会让其变得更好为姿态，成长就会成为副产品。

2. 鼓励创造结果而不是追求上班时间。若是咱们的目标是页面加载时间不要超过 800ms，那么目标就是 800ms 而不是上 12 个小时的班。

3. 营造环境。咱们有最好的人，咱们追求结果而不是追求上班时间，咱们鼓励主动和主人公意识，咱们创新以打破规则 ，咱们声明全部人为本身而生为用户工做而非老板，咱们会包个酒包或找个海岛玩到天亮。有不少东西是要刻意去营造的，创新土壤，主动的意识，热爱生活的文化，鼓励什么就会汇集 / 培养一群什么样的人。

由于这样的管理方式，一般大部分事情都会被内部很好地解决，而我也获得更多的时间去思考如何作和决定作什么；团队也由于成员不断成长闪耀不一样的光芒而变得更好。若是以官话来讲，就是咱们要发现一种“可持续发展”的模式。这种模式目前运行的不错，不管是业务上的，仍是团队文化自己，抑或是加入成员的成长，都是让人高兴的。但，更好的方式仍在探索，若是说只分享一个点的话，那就是千万别用“管”的方式，而是“理”顺，就会瓜熟蒂落。

至因而不是盲目追求新技术。上面咱们已经谈过技术选型的要求，最最重要的也是最最根本的问题“是否进升饿了么运行的效率或者团队开发的效率？”，我相信若是你们能回答好这个问题，就解决了“盲目”追求的问题。

最后说一句，不管是管理上、技术上、生活上，预留必定的空间和自由度，必定会带来惊喜。具体就不解释了，你们自行理解，或许某天咱们遇到能够用这个话题开场，就开聊起来了。

8. 大前端模式的利弊有哪些？

“大前端”模式的特色前面已有说起，便是 对前端自己的一种能力范围延伸。移动开发团队，我这里指包含移动网页、Native-Like、Native App 这样的团队，如携程；纯大前端的团队如美团和饿了么北京研发中心，只要是客户端的不管是网页仍是 App 都在单一个团队；饿了么不只有大前端，还有各 BU 的 Native App 团队，甚至还有专一于移动基础框架的公共的移动技术团队。

不一样的分工模式，其利弊一般与公司状态、团队自己所创造的价格有很大的关联；虽然你们都是“离用户最近的工程师”，但没有公式可抄。

就拿饿了么大前端来讲，最开始是由于业务的快速发展，除了 C 端部门，其余新成立的部门前端工程师极度紧缺，为了资源的高效配置，才成立了大前端这个部门。这是当时公司业务的状态。

创始人和 CTO 曾问我：“你以为若是今天合了，几时会分？”当时，个人想法是，若是 一个业务前端团队发展到 10 人左右，在负责好自己的业务外，能创建且不断升级本身的技术基础设施又具有有本身的文化，是一个分的时机。时至两年后的 今日，我已再也不是这样的想法，而且新成立的 BU 更愿意把人放到大前端。

这是为何呢？咱们从如下几点分析：

1. 若是一个大团队，并不能提便利的基础设施，不能建立自由且充满可能的文化，不能持续提高本身并帮助成员提高其自身水平。也就是你们常常谈到的技术追求、归属感、成就感。那么，打散到业务组可能更灵活。因此 前端业务团队的分与合归根到底在于 —— 大团队是否创造比小团队更高的价值。

2. 大多数人高估了“前端 + 后端 + 产品”坐在一块儿的效果，认为这样就能完美解决问题。不少时候，对于程序员来讲更少的打扰，更多的思考（好比坐内部电梯去找某我的太慢了，就会开始思考是否是有必要去找某我的）事后的沟通，是更高效的沟通。

3. 划分框架、机动与业务团队，一方面基础设施共享（框架 / 工具）有更多重用，人员调度能够省很多资源（小团队 _ 需求少的团队能够合并支持）且又有专一于业务的团队，彷佛是最前很是不错的划分方式，而在 10 我的的团队中是很难作到的。

由此，咱们能够看出，一方面是业务影响，另外一方面也依赖团队自己产生的价值，今天咱们要分仍是合，其利弊计算出如今决定作出以后，带领团队的人可否利用“合”的优点去产生出更大的价值。这个问题的答案就是利与弊的答案。

9. 如何看业界大前端团队的现状？

咱们团队每一年都会以我的或者团队名义邀请多位前端业界大牛来内部交流，也会组织内、外部交流会，这一般是几个电话和微信就搞定的事，整体交流仍是比较多的。即便没有专门的会议，也会偶尔相互统统气。

我没有具体统计过业界现状，但从我这边交流过的团队来讲，如今不少团队都是大前端方向，或向这个方向发展的比较多。有少部分像携程、腾讯这种体量自己就很大职能划分也比较明确的公司，作的事多是“大前端”但分开还是比较偏向于 JS+HTML+CSS 这样的纯前端模式。

这里也指望读者所在的团队，若有新的实践和想法咱们能够偶尔探讨。

10. 要不要组建大前端团队？

前文也有提到，要不要组建大前端团队，一方面是看业务是否有需求，另外一方面是看合可否比分开带来更大的价值。

除非人极少，一般来讲业务大多数状况都会随公司的发展变得越分越开，而价值则主要是关于人和文化。目标不是为了合而合，或者追随业界模式，而应该着眼因而否优化了公司的人才架构从而优化业务。

若是必定要从具体实施点上来讲，这里说两点：

• 框架团队和业务团队应该同时设立，而且框架与业务不能相互脱离，具体能够参考饿了么大前端的模式 —— 相互渗透；

• 在大职能团队下，尽量以业务划分团队，不要以职能划分团队；反之亦然。

Reference:http://www.infoq.com/cn/news/2017/03/Hungry-front-team-decryption