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