【转】解密饿了么大前端团队

   

    最近，"大前端"这个词被频繁说起，不少团队也在从新思考"大前端团队"和"移动团队+前端团队"这两种模式的优劣。而在你们还在热火朝天地讨论概念的时候，饿了么大前端团队已经茁壮成长，有了不少先人一步的实践了。InfoQ 特别邀请了饿了么大前端部门负责人林建锋，请他结合饿了么大前端团队的实践，向你们分享如何落地和管理一个大前端团队。
    平时你们会叫我小鱼或 Sofish，尴尬的是只有屈指可数的同行知道我真名叫林建锋。曾经，为了逃离数学，大学我选了法学这个专业；而毕业前，又为了逃离职业性的"辩论"选择了不用说太多话的前端开发，至此踏上了程序员的不归路。
    这段程序员的不归路从实习开始，到远赴杭州支付宝，然后以第一个前端工程师的身份百姓网，再以后选择创业，最后加入饿了么并定居上海。目前做为饿了么大前端部门负责人，我和一群小伙伴在努力把饿了么变得更好，顺路立志成为业界顶尖团队。
    1、饿了么大前端团队的定位
    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。这些与部门所建立的文化息息相关，且如你可能猜到的，大多合做都是一旦有人提出，即自发组队。
    2、饿了么大前端团队如何看待和落地新技术
    咱们是如何看待新技术的？在面试前端 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 的实验，能够想象在不久的未来，线上应用将会大面应用。这就是咱们的选型和落地模式。
    3、饿了么大前端团队的特点：散养
    特点？若是只用两个字来回答就是 —— 散养。但仅仅这样描述你们会一脸问号。外部对咱们的评价是："新技术跟进好快啊"、"怎么又又又出去玩了"、"下班很早"、"好多大牛啊"、"开源的东西得到好多星星啊"，诸如此类，但这不是咱们要特意我呈现的，只是一种表像，或者说是一种副产品。
    一个团队的风格与创始人有很大的关系，好比喜欢愉懒的我会更多考虑自动化；又若有洁癖因此会有代码规划和 Code Review；还有你们看到的爱玩，因此会常常有团建、下午茶这样的文化；但另外一方面，我并不想让团队仅仅是和我同样有你们喜欢的，同时充满缺点，而但愿是不断尝试的，兼容并包的，让每一个人的闪光点都成为集体中有特点标志的。因此我有本身的一套，就是前端所说的"散养"式管理，提及来可能会很大，重点说几点：
        招聘最好的人。最好的人不是业界里的全部明星，更重要的是能从某方面给带队带来提高的人。这些人一般自驱能力强，只要有一个方向就能推进事件的发生和发展。加入的人会被要求不要以学习姿态加入这个团队，而是以加入会让这个团队会让其变得更好为姿态，成长就会成为副产品。
        鼓励创造结果而不是追求上班时间。若是咱们的目标是页面加载时间不要超过 800ms，那么目标就是 800ms 而不是上 12 个小时的班。
        营造环境。咱们有最好的人，咱们追求结果而不是追求上班时间，咱们鼓励主动和主人公意识，咱们创新以打破规则 ，咱们声明全部人为本身而生为用户工做而非老板，咱们会包个酒包或找个海岛玩到天亮。有不少东西是要刻意去营造的，创新土壤，主动的意识，热爱生活的文化，鼓励什么就会汇集/培养一群什么样的人。
    由于这样的管理方式，一般大部分事情都会被内部很好地解决，而我也获得更多的时间去思考如何作和决定作什么；团队也由于成员不断成长闪耀不一样的光芒而变得更好。若是以官话来讲，就是咱们要发现一种"可持续发展"的模式。这种模式目前运行的不错，不管是业务上的，仍是团队文化自己，抑或是加入成员的成长，都是让人高兴的。但，更好的方式仍在探索，若是说只分享一个点的话，那就是千万别用"管"的方式，而是"理"顺，就会瓜熟蒂落。
    至因而不是盲目追求新技术。上面咱们已经谈过技术选型的要求，最最重要的也是最最根本的问题"是否进升饿了么运行的效率或者团队开发的效率？"，我相信若是你们能回答好这个问题，就解决了"盲目"追求的问题。
    最后说一句，不管是管理上、技术上、生活上，预留必定的空间和自由度，必定会带来惊喜。具体就不解释了，你们自行理解，或许某天咱们遇到能够用这个话题开场，就开聊起来了。
    4、大前端模式的利弊
    "大前端"模式的特色前面已有说起，便是对前端自己的一种能力范围延伸。移动开发团队，我这里指包含移动网页、Native-Like、Native App 这样的团队，如携程；纯大前端的团队如美团和饿了么北京研发中心，只要是客户端的不管是网页仍是 App 都在单一个团队；饿了么不只有大前端，还有各 BU 的 Native App 团队，甚至还有专一于移动基础框架的公共的移动技术团队。
    不一样的分工模式，其利弊一般与公司状态、团队自己所创造的价格有很大的关联；虽然你们都是"离用户最近的工程师"，但没有公式可抄。
    就拿饿了么大前端来讲，最开始是由于业务的快速发展，除了 C 端部门，其余新成立的部门前端工程师极度紧缺，为了资源的高效配置，才成立了大前端这个部门。这是当时公司业务的状态。
    创始人和 CTO 曾问我："你以为若是今天合了，几时会分？"当时，个人想法是，若是一个业务前端团队发展到 10 人左右，在负责好自己的业务外，能创建且不断升级本身的技术基础设施又具有有本身的文化，是一个分的时机。时至两年后的今日，我已再也不是这样的想法，而且新成立的 BU 更愿意把人放到大前端。
    这是为何呢？咱们从如下几点分析：
        若是一个大团队，并不能提便利的基础设施，不能建立自由且充满可能的文化，不能持续提高本身并帮助成员提高其自身水平。也就是你们常常谈到的技术追求、归属感、成就感。那么，打散到业务组可能更灵活。因此前端业务团队的分与合归根到底在于 —— 大团队是否创造比小团队更高的价值。
        大多数人高估了"前端+后端+产品"坐在一块儿的效果，认为这样就能完美解决问题。不少时候，对于程序员来讲更少的打扰，更多的思考（好比坐内部电梯去找某我的太慢了，就会开始思考是否是有必要去找某我的）事后的沟通，是更高效的沟通。
        划分框架、机动与业务团队，一方面基础设施共享（框架工具）有更多重用，人员调度能够省很多资源（小团队需求少的团队能够合并支持）且又有专一于业务的团队，彷佛是最前很是不错的划分方式，而在 10 我的的团队中是很难作到的。
    由此，咱们能够看出，一方面是业务影响，另外一方面也依赖团队自己产生的价值，今天咱们要分仍是合，其利弊计算出如今决定作出以后，带领团队的人可否利用"合"的优点去产生出更大的价值。这个问题的答案就是利与弊的答案。
    5、业界大前端团队的现状
    咱们团队每一年都会以我的或者团队名义邀请多位前端业界大牛来内部交流，也会组织内、外部交流会，这一般是几个电话和微信就搞定的事，整体交流仍是比较多的。即便没有专门的会议，也会偶尔相互统统气。
    我没有具体统计过业界现状，但从我这边交流过的团队来讲，如今不少团队都是大前端方向，或向这个方向发展的比较多。有少部分像携程、腾讯这种体量自己就很大职能划分也比较明确的公司，作的事多是"大前端"但分开还是比较偏向于 JS+HTML+CSS 这样的纯前端模式。
    这里也指望读者所在的团队，若有新的实践和想法咱们能够偶尔探讨。
    6、如何落地一个大前端团队？
    前文也有提到，要不要组建大前端团队，一方面是看业务是否有需求，另外一方面是看合可否比分开带来更大的价值。
    除非人极少，一般来讲业务大多数状况都会随公司的发展变得越分越开，而价值则主要是关于人和文化。目标不是为了合而合，或者追随业界模式，而应该着眼因而否优化了公司的人才架构从而优化业务。
    若是必定要从具体实施点上来讲，这里说两点：
        1.框架团队和业务团队应该同时设立，而且框架与业务不能相互脱离，具体能够参考饿了么大前端的模式相互渗透；
        2.在大职能团队下，尽量以业务划分团队，不要以职能划分团队；反之亦然。