Article Outline
1、请您简单地向读者做个自我介绍，包括经历、现在的团队和自己的职责
平时大家会叫我小鱼或 Sofish，尴尬的是只有屈指可数的同行知道我真名叫林建锋。为了逃离数学，大学我选了法学这个专业；而毕业前又为了逃离职业性的「辩论」选择了不用说太多话的前端，至此踏上程序员的不归路。
从实习到远赴杭州支付宝，再作为第一个前端工程师加入百姓网后选择创业，最后加入饿了么并定居上海。目前作为饿了么大前端部门负责人，和一群小伙伴在努力把饿了么变的更好，顺路立志成为业界顶尖团队。
2、您所带领的团队是饿了么大前端团队，“大前端”这个名字当初是如何确定下来的？其具体的职责包括哪些？具体是如何分工的？团队间如何协作？
大前端这个词最早是因为在阿里内部有很多前端既写前端又写 Java 的 Velocity 模板而得，而部门成为之初也是因为那时我们承担的内容不仅仅是前端，还包含 CDN 和 Nginx 层，所以取名大前端。时至今日，大前端已经包含了前端、Node、Native-Like (Hybrid / WEEX / RN)，甚至 Native App 开发。
如上面所说的，除了纯 iOS / Android App 的开发，其他都是我们团队职责所在，同时我们还负责公司 HTTP API 层，有一些自己运维的系统。
从分工来说来，目前我们有架构与机动组负责框架、规范、工具的生产；Node 研发团队负责公司 Node 业务的基础设施和业务支撑；多个业务前端团队支持不同的 BU 前端。这里值得一提的是，架构与机动组中的成员，会对每个业务团队至少派出一名架构师长期、深入地了解业务团队所遇到的问题并反馈到架构团队，并在解决方案提出后协助推动。
在具体职能分工之外，各团队也有以项目而组织起来的虚拟团队，比如由我们部门负责的「游戏中心系统」就由 Node 研发团队和架构与机场组中的成员组成；又如小程序团队；亦如发起一次由 93 后独立组织的招聘；专栏编辑团队、官司微小分队、对内对外分享会小分队等等。除了大家看到的开源产品，内部的所有项目都是「内部开源」，特别鼓励大家提 Pull Request 和相互 Code Review。这些与部门所创建的文化息息相关，且如你可能猜到的，大多合作都是一旦有人提出，即自发组队。
3、您认为“大前端”这个概念应该如何定义？
在我看来，「大前端」是一种变化形态多过于固定的职责范围，是「前端」职责范围的延升，是对这个社会分工因为能力范围和因此所达到效率提升的一种进化形态。给大家分享个小道消息，CTO 曾多次开玩笑说 —— 你们负责的已经不仅仅是前端，要不就改名「大全栈」吧。这部门的名字很霸气但同时也太高调，所有并没有接受 BOSS 的提议，而是继续沿用这个部门名。
4、您认为“大前端”团队具有什么样的特点，和单纯的“移动开发团队+前端团队”有什么样的区别?大前端团队的模式有什么利弊？
特点前面已经说了，是对前端本身的一种能力范围延升。关于是移动开发团队我猜这里指的是包含移动网页、Native-Like、Native App 这样的团队，如携程；纯大前端的团队如美团和饿了么北京研发中心，只要是客户端的无论是网页还是 App 都在单一个团队；饿了么不仅有大前端，还有各 BU 的 Native App 团队，甚至还有专注于移动基础框架的公共的移动技术团队。
分工的利弊通常来说与公司状态、团队本身所创造的价格有很大的关联；虽然大家都是「离用户最近的工程师」，但没有公式可抄。
就拿饿了么大前端来说，最开始是因为业务的快速发展，除了 C 端部门，其他新成立的部门前端工程师极度紧缺，为了资源的高效配置，成立了这个部门。这是当时公司业务的状态。创始人和 CTO 问我，你觉得如果今天合了，几时会分？当时的想法是，如果一个业务前端团队发展到 10 人左右，在负责好本身的业务外，能建立且不断升级自己的技术基础设施又具备有自己的文化，是一个分的时机。时至两年后的今日，已经不再是这样的想法，并且新成立的 BU 更愿意把人放到大前端。为何？
如果一个大团队，并不能提便利的基础设施，不能创建自由且充满可能的文化，不能持续提升自己并帮助成员提升其自身水平。也就是大家经常谈到的技术追求、归属感、成就感。那么，打散到业务组可能更灵活。所以前端业务团队的分与合归根到底在于 —— 大团队是否创造比小团队更高的价值。
大多数人过高估计前端/后端/产品坐在一起就能完美解决问题。很多时候，对于程序员来说更少的打扰，更多的思考（比如坐内部电梯去找某个人太慢了，就会开始思考是不是有必要去找某个人）过后的沟通，是更高效的沟通。
划分框架、机动与业务团队，一方面基础设施共享（框架/工具）有更多重用，人员调度可以省不少资源（小团队需求少的团队可以合并支持）且又有专注于业务的团队，似乎是最前非常不错的划分方式，而在 10 个人的团队中是很难做到的。
由此，我们可以看出，一方面是业务影响，另一方面也依赖团队本身产生的价值，今天我们要分还是合，利弊计算出现在决定做出之后，带领团队的人能否利用「合」的优势去产生出更大的价值。这个问题的答案就是利与弊的答案。
5、据您了解，业界大前端团队的现状如何？饿了么有没有其他的大前端团队进行交流？
没有具体统计过这个问题，但从我这边交流过的团队来说，现在很多团队都是大前端方向，或向这个方向发展的比较多。有少部分像携程、腾讯这种体量本身就很大职能划分也比较明确的公司，做的事可能是「大前端」但分开仍是比较偏向于 JS / HTML / CSS 这样的纯前端模式。
至于具体的交流，团队每年都会以个人或者团队名义邀请多位前端业界大牛来内部交流，也会组织内、外部交流会，这通常是几个电话和微信就搞定的事，总体交流还是比较多的。即使没有专门的会议，也会偶尔相互通通气。这里也期望读者所在的团队，如有新的实践和想法我们可以偶尔探讨。
6、如果说一个企业的前端和移动开发团队要重组成大前端团队，您认为需要注意哪些点？
前面第 4 点也说了，一方面是业务是否需求，另一方面是看合能否比分开带来更大的价值。通常来说，除非人极少，通常来说业务大多数情况都会随公司的发展变得越分越开，而价值则主要是关于人和文化。目标不是为了合而合，或者追随业界模式，而应该着眼于是否优化了公司的人才架构从而优化业务。
如果一定要从具体实施点上来说，这里说两点。
- 框架团队和业务团队应该同时设立，并且框架与业务不能相互脱离，具体可以参考饿了么大前端的模式 —— 相互渗透。
- 在大职能团队下，尽可能以业务划分团队，不要以职能划分团队；反之亦然。
7、您是如何看待新技术的？关于 Vue.js、WEEX、PWA 等较新的技术上都有一些又快又好的实践，那么能否举例说明，这些新技术究竟是如何落地的？例如，能否以 Vue.js 为例，分享一下技术选型和具体落地的过程？
在面试前端 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 写起来好简洁啊，大家要不要一起来试试？」。然后，一个团队，两个团队... 几乎所有团队都开始应用，几乎所有新项目都在用。一位某跨国大厂的朋友告诉我，他申请在项目试用 Vue.js，上级说在半年后试用，结果半年后又被推翻了。所以你看，在合适的文化土壤里新事物就是一种常态，如果做一个项目用什么技术还要上级主管确定「能不能做」，那本身就不是一件简单的事。
我们对于技术选型通常来说要求是 —— 是否提升饿了么运行的效率或者团队开发的效率？是否能 hold 住？有没有人负责到底？符合这样的条件，就会被推动。当大家都在说 https 是好东西的时候，我们已经推动全网上线，诸如此类 —— Webp、Https、Vue.js / React.js / Angular.js、WEEX、PWA 都是如此。比如大家可能去年就关注到我们在上线 HTTP/2，而今天饿了么大前端内部已经做过 HTTP/2 Server Push 的实验，可以想象在不久的将来，线上应用将会大面应用。这就是我们的选型和落地模式。
8、在团队的管理方面，饿了么大前端团队有哪些特色？如何使得团队成员做到有思考地追求新技术，而不是盲目追赶？
特色？如果只用两个字来回答就是 —— 散养。但仅仅这样描述大家会一脸问号。外部对我们的评价是：「新技术跟进好快」「怎么又又又出去玩了」「下班很早」「好多大牛」「开源的东西获得好多星星」，诸如此类，但这不是我们要特地我呈现的，只是一种表像，或者说是一种副产品。
一个团队的风格与创始人有很大的关系，比如喜欢愉懒的我会更多考虑自动化；又如有洁癖所以会有代码规划和 Code Review；还有大家看到的爱玩，所以会经常有团建、下午茶这样的文化；但另一方面，我并不想让团队仅仅是和我一样有大家喜欢的，同时充满缺点，而希望是不断尝试的，兼容并包的，让每个人的闪光点都成为集体中有特色标志的。所以我有自己的一套，就是前端所说的「散养」式管理，说起来可能会很大，重点说几点：
招聘最好的人。最好的人不是业界里的所有明星，更重要的是能从某方面给带队带来提升的人。这些人通常自驱能力强，只要有一个方向就能推动事件的发生和发展。加入的人会被要求不要以学习姿态加入这个团队，而是以加入会让这个团队会让其变得更好为姿态，成长就会成为副产品。
鼓励创造结果而不是追求上班时间。如果我们的目标是页面加载时间不要超过 800ms，那么目标就是 800ms 而不是上 12 个小时的班。
营造环境。我们有最好的人，我们追求结果而不是追求上班时间，我们鼓励主动和主人公意识，我们创新以打破规则 ，我们声明所有人为自己而生为用户工作而非老板，我们会包个酒包或找个海岛玩到天亮。有很多东西是要刻意去营造的，创新土壤，主动的意识，热爱生活的文化，鼓励什么就会聚集/培养一群什么样的人。
因为这样的管理方式，通常大部分事情都会被内部很好地解决，而我也得到更多的时间去思考如何做和决定做什么；团队也因为成员不断成长闪耀不同的光芒而变得更好。如果以官话来说，就是我们要发现一种「可持续发展」的模式。这种模式目前运行的不错，无论是业务上的，还是团队文化本身，抑或是加入成员的成长，都是让人高兴的。但，更好的方式仍在探索，如果说只分享一个点的话，那就是千万别用「管」的方式，而是「理」顺，就会顺理成章。
至于是不是盲目追求新技术。上面我们已经谈过技术选型的要求，最最重要的也是最最根本的问题「是否进升饿了么运行的效率或者团队开发的效率？」，我相信如果大家能回答好这个问题，就解决了「盲目」追求的问题。
最后说一句，无论是管理上、技术上、生活上，预留一定的空间和自由度，一定会带来惊喜。具体就不解释了，大家自行理解，或许某天我们遇到可以用这个话题开场，就开聊起来了。