2019 国内公司前端团队都在搞些什么?

用nodejs代替php，性能提高25%，机器节约了10几台，写了个ts的web框架。

本来22号要去GIAC分享的，家里有事取消了，有机会在知乎把逐字稿和ppt放上吧。

把 Backend For Frontend 升级为 Serverless For Frontend，提升研发效能，解决 BFF 阶段带来的额外成本(人员培养成本、运维成本、应用治理成本)。

离玉伯的前端提效 100 倍的愿景又迈了一小步。现在活多人少有挑战，撸起袖子拼命干。年底搞完再分享下，未来可期，想象空间挺大的，欢迎加入一起搞事。

自主研发内部前端框架和库

把jq改为vue。。。。。
因为不是什么先进大厂啦，基本上上年纪的项目都是3、5年以上。
jq遍地走，所以现在都2019年了，vue就感觉很多前端都会，但实际在生产的项目就寥寥可数（在我的公司）。那肯定为了更好的体验，改咯。慢慢改。

我们搞的东西也不少。JS 层（类 RN）实现了完全动态化，开发、构建、测试、发布、运营各业务线完全独立化；Native 层渐渐去业务化，只做支撑；C++ 层做逻辑复用和高性能渲染。

同时针对各种横向同层依赖、纵向跨层依赖做出各类依赖分析，确定修改代码的影响范围、版本间的变动所影响的功能（以确定最小化的测试范围）等，通过 GraphQL 接口提供数据。

我也在持续考虑 Serverless 场景，打算在我们的 IDE 里集成阿里云的函数计算服务，让前端同学可以编写、发布一把梭。适合敏捷地做一些接口聚合、异构重整（tranform）等工作。复用阿里云函数计算可以做出比之前更完美的 BFF 层。

我们也在考虑将采用 TypeScript 的业务编译成 WASM 来提高性能，甚至 UI 框架也在考虑用 C++ 重写，因为性能对地图应用来说真的太重要了。很高兴看到 Rax 已经开始做了。

还有各种如框架、调试能力、测试能力、IDE 等一大堆的事儿可以做，编译原理、算法、Node.js 都有得玩。事多挑战多人少，团队有魄力，机会很多，欢迎前端架构方向的同学加入我们，有兴趣请私信。

参加技术评审，合不合理，怎么做，听后端说就行了，有时候一个需求后端与后端、后端与产品讨论花费一半的时间

为什么还要前端参与，因为要你来做事。技术评审你可以讨论该不该展示，怎么展示的问题，怎么做的问题还是算了吧，重逻辑在后端

偶尔和产品撕一撕某个按钮应该放在哪里等问题，现在不撕了，倾向于妥协

需求下来后定个排期，后端5天，前端4天吧，可能一天就做完了，但太快也不好，多点自己的时间

有了接口文档和产品PRD就开干吧

git checkout master && git pull && git checkout -b "new_branch" && npm run dev

新建一个.vue/.jsx文件，太懒了没在vscode里用snippets，直接找个代码不多的文件复制粘贴吧

vue项目写template，打开element官网，复制粘贴；react写JSX，打开ant-design官网，复制粘贴

import xxx from "element-ui" | import xxx from "antd"

把接口文档里的数据复制粘贴到mock平台

根据交互请求接口，有vuex/redux的项目就dispatch，没有就放到data/state里

根据交互做一些简单逻辑判断，if，else，for，if用的挺多

做需求过程中前端之间几乎不用交流，前端团队一般比较安静，逻辑较简单，没什么历史包袱，业务相关的新需求基本不需要问老人，新人来了2天之内就能接需求，教一下怎么起项目打包上线就行；做同一个项目，没有交集的模块，也不需要交流；倒是偶尔与后端、产品沟通一下之前没想到的细节

开发完了联调，提测，上线

经历了公司不同部门的两个团队，大同小异，坐标TMD某较核心部门FE组

小厂也来说一下。

基于 qiankun 和 umi 准备把后台系统拆分成微服务。

想继续完善 umi pro。用编辑器插件来实现语言层面无法实现的功能。

各有各干的事

同样的大厂前端，这楼里这两个链接，简直天上地下

一个复制粘贴，一个 C++ 优化

搞不好复制粘贴的人工资和职级还更高，你说这世界到底是啥样的

前端？

日常是这样的：

我看了看上级发来的需求，老板问我什么时候做完？我无奈的摇了摇头，一副生无可恋又心有余力不足的表情，老板拍了拍我的肩膀，说，不要着急，慢慢做！我说了一句，俩周内尽量做完。老板满心欢喜的表情让我觉得此刻非常充实，我打开了antd ，再打开我的idea，严肃且认真地敲上了几行，哦，不，粘贴了几行，用我深邃的且跳跃的思维，改了改代码。一番摧枯拉朽之后，终于大功告成！我疲倦地看了看我手上的劳力士，离完成老板的需求竟然只剩下13天23小时。我满意地点了点头，喝了喝刚去楼下买的可乐，哎，前端的工作，就是这么朴实无华，且枯燥。。

不是前端。我是写php的。然后把我司后台从jq带上react。结果发现。同事排斥。大家都不愿意学习新的技术？fuck！所有后台我一个人写。后来我就写了一个自动生成后台的工具。具体可以参考qcon今年那个自动配置后台。大同小异。然后我现在天天没事做。上班刷知乎

没有用Serverless，写了前端微服务框架，以及配套的基础设施。

前端工程化套件，并基于套件造了很多小轮子。

前端监控、全埋点、数据采集框架，美其名曰：全链路监控引擎。

17年底统一换了TS，现在无论框架还是业务都在用，获益良多。

小厂人少，总是一个人写像在自嗨…

早上到公司，打开电脑，打开vscode，打开chrome，点击书签栏上的"知乎"，然后就吃饭了。

午觉起来，需求评审"你这么点时间，很难办啊"，需求评审结束。

回到工位，把刚刚需要做的，c+v搞定。看看了时钟，嘶，新建chrome标签页，点击书签栏上的"知乎"，然后就下班了

我自己感觉可以总结成几个方面

1. Serverless
2. 云 IDE
3. 跨端技术：Flutter，Swift UI
4. 语言编译性能优化：TS to WASM，JS to Bytecode

说说自己的日常吧：

前公司一位前端小弟发来微信：“老大，我们这做一个新项目，vue + element-ui，有个功能不会做，能给个思路吗？”

我看了看需求，不难，帮他写了比给他讲会更节省时间。

我：“coding项目把我拉进来，我给你写吧。“（公司管理很松散，这种违规操作基本没人管。）

他：“多谢老大！~~~哈哈哈！”

clone完项目之后，我一愣，只有master分支。

我：“咱们项目就一个分支吗?”

他：“啊，是的。”

我：“这样比较危险，也不利于管理，我建一个自己名字的分支，给你写完，你看没问题就merge到master上吧，当然，开发最好再建一个develop分支，发布的时候在merge到master。”

他：“大哥，怎么merge啊，没用过。”

我：“这个......百度自己查查吧！”

半小时后，功能写完，注释清晰易懂，push代码。

我：“搞定了，注释看看能不能看懂，没啥问题的话，百度看看git怎么用，然后自己合并分支吧。”

他：“多谢大哥！~~~哈哈哈”

日常就是这么low，小菜问老鸟，老鸟问小牛，小牛问大神，再菜都有比你菜的，再牛也有比你牛的。有时间嘲笑新人lowB不如耐心指导一下他，没准碰上一个可塑之才呢。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

第二次更新，技术交流加微信：xiaozhoubaogao

1. 网站用react重构
2. 开发一堆给别人用的中台系统，用antd-pro开发的
3. 写一堆能够在各个系统内复用的功能性组件

最近就是写了个在线剪视频的平台，顺便写了两个内部用的，减少antd-pro配置的umi插件。

搞了个可配置的表单，开始内部用的时候搞了一版，后来自己用typescript重构（写）了一版

1. 扩展前端能力，比如跨端（RN、Flutter）、Node
2. 提升前端开发效率的手段，比如脚手架、组件库、建站工具、微前端
3. 搭建保障前端开发质量的平台，比如性能、日志、监控、测试等
4. 将前端和某一个领域结合，比如可视化、多媒体、游戏
5. 日常业务需求开发

给大家分享几个身边的案例

我之前的同事，现在在国企，他们当前的项目，前端开发技术栈虽然用的是JQuery。正在放弃IE8，电脑系统升级为win10，因为企业团队比较看重Angular在重交互表单的处理，以及后期项目维护，所以计划用Angular+Java开发之后排期的项目。

还有个同事现在在某一线大厂，他们公司目前做的项目有：人机交互，数据可视化，产品web，算法执行，模型训练等等，他们现在在做某个电商平台的项目，通俗点讲，就是统计各个商品的售卖数据，用人工智能分析不同群体的购买能力。

他们隔壁的团队在推进机器客服的项目，有了初步成果之后，估计可以取代当前三分之一的人工客服，直接降低成本。

我哥哥的公司，目前专攻人工智能方向，用的是React||Angular node.js Go，版本管理工具用git。目标客户是中学生，学生不会的题目，拍一张照片，通过APP发给后台，然后能够快速，精准回复给答案与解析。

由于wkwebview不让拦截请求，导致离线化方案在iOS没法run

上半年搞了一个新方案，来解决上述静态资源网络IO慢的问题，效果还不错。

杭州宋小菜，B+ 轮，服务端 30 人，前端 20 人，卖菜的公司，业务从上游的囤货仓储延展到下游的批发市场，人群种类差异大，体现在端上就有 8 款 APP，3 个小程序，5 个 H5 核心交易场景，以及更多的采配销中台系统，我们技术上不断在遇到挑战的同时，非技术方面也遇到了更大的挑战，具体讲就是技术和工程能力是前提条件，需要持续不断的建设，除此以外，还需要有更多的软实力辅助，才能更好的助力业务不断攻城略地拿下更漂亮的结果，所以答案就是技术折腾以外，我们团队在不断的通过各种内训来提高大家的综合软实力，至于技术栈方面，大家可以看这篇文章：

针对软实力，我专门写了一篇文章，向团队的同学们宣讲，为什么从今年起，大中型公司的资深前端，会发现做出成绩会越来越难了，是因为前端已进入到深水区：

对于普通人，最大潜水深度一般不超过水下 30 米，极限为水下 40 米，超过 40 米就进入到技术潜水的范畴，就会面临各种复杂的危险状况，需要各种装备的集成和系统化的训练才能保证一定的安全性。
- 为什么技术晋升越来越难了
- 为什么高薪资的岗位 Offer 越来越难拿了
- 为什么公司总是说做技术也要懂业务
- 为什么很多团队主管总把价值挂在嘴边
- 为什么 What/How/Why 必须要搞清楚
- 为什么单纯技术硬很难向前突破了
- 为什么前端开发往上走比之前更难了
- 为什么我想发力却总是懒于动手
- 为什么我趴键盘上看不到明天看不到希望 - ...

红利已逝，今非昔比。对比 2010 年，整个前端生态已经翻新了好几遍，直到近几年的 Node BFF、IDE Cloud，抑或是客户端 AI，还是 Serverless 的建设，前端想要深度参与的话，单纯依靠原来的 HTML/CSS/JS 三件套技能也远远不够了，再抛开技术，整个互联网创业生态也重构了好几遍，生意的本质没变，但做生意的理念和方法论以及辅助的工具都发生了巨大的变化。

新的商业环境下就有新的公司组织架构形态，以及新的产品研发流程和合作模式，这些也对今日的前端开发工程师提出更新更高的要求，无论是技术层面还是意识层面，如今的前端开发已经进入深水区，要在深水区中生存以及捕捞猎物，就需要有深水区所需要的系统化的技能体系以及配套的软硬件能力，以及从浅水区进往深水区所需要的进阶方法论，本文试图向大家传达这样一种观点，希望带给大家一些启示，无论是新人老人都要居安思危，提前做出储备，以应对新的职场挑战，更灵活的延展自己的职业路线。

本文是小菜前端 TL 内训课程中， 《上手技术管理的初级套路》 这一节里面，关于前端已迎来深水区这个观点的展开陈述，文中会截取几页 PPT 来辅助叙述帮大家理解:

浅水区需要哪些技能

站在 2019 年，通常一个工程师履历中体现的是跳槽历史、参与项目的难度、React/Vue/Angular 等框架底层熟悉度、编程方法论的掌握程度以及职位的变迁等，而在工作中的确与编程强相关的技能有很多（该图是我多年前整理修改而来，有同学知道出处可以告知我）：

抛开 BATMD 这种大体量的公司，放在市面上任意一个 50 人规模以下技术团队的公司里面，大概率掌握最好的是 IDE/框架/API 这一层，至于代码实现的足够优雅很难保障，更不要提程序设计的娴熟套路、项目背后沉淀的方法论等等，单纯在这张图上打怪升级花个 5 年 10 年丝毫不为怪，而对于前端工程师，这张图的技能点花个 7 年 10 年全部打满打透，此时也差不多三十而立了，而立之年也就是摸到了技术路线的第一个天花板，这个天花板就是技术专家，即便如此，用 10 年时间碰到这个天花板的人依然是极少数，大部分人需要花费更久甚至一直到不了这个高度，而所有这张图上我把它定义成浅水区技能，是肉眼可见的，是可以量化的，是最容易产生共鸣而形成学习动力的，但是放在如今的新商业环境中就显得很单薄了。

为什么单薄呢？我们把图上的能力和知识体系打碎重组，提炼后就是三个关键字：架构、编程、运维，一个是意识和逻辑层面，一个是过程实现层面，一个是环境保障层面，这些能力依然是落纯技术体系内，并没有跟外部的商业和职场环境发生多少交集。

深水区需要哪些技能

在深水区，脑海中如果只有编程二字是不够的，就算带一些沟通合作也还是远远不够，但是不是一定需要深水区技能才能把工作做好，答案也并不是，深水区技能是更长期性更深刻的，从长期看具备这些特质可以更快更好的跨过技术专家的这个天花板，走到更高的一个 Level，但不具备这些特质也未必会严重影响浅水区的表现。不过当更多同龄人具备深水区能力的时候，只具备浅水区能力的你慢慢就变成了裸泳，而更多更多的新人跳入到浅水区和你一起竞争，此时你跟深水区已经是隔绝的两个世界，看到的和收获也截然不同了。

我把深水区的技能，更口语化的总结为： 技术创新、流程优化、团队合作、影响大盘、驱动业务、商业决策和团队管理，如下图：

每一个能力的解释我也标注在了图上，再通俗的解释一下：

• 技术创新，从技术面、业务和产品面出发，以技术作为突破点，取得技术上的突破，比如兼容多端的框架研发、客户端浅层次 AI 的实现
• 流程优化，更多是从产品研发流程上发力，借助向上向下的管理，推动流程变得更高效，比如前后端的接口联调方式、比如产品 PRD 到测试流程的介入更敏捷的迭代方式，可能是规范可能是工具层面
• 团队合作，这个最好理解也最难做好，同样是从管理和业务的视角切过去，促成团队成员之间有更高层面的共识达成，有更信任的纽带关系，以及有更匹配的使命目标驱动，比如与业务同学一起出差拜访客户，并在过程中发现更多共鸣点，从而驱动彼此更快调整协作方式，最终为客户解决问题
• 影响大盘，所谓大盘就是公司或者部门的业务大盘，这个一定需要对业务的前景有较为客观深刻的认识，并且形成自己的独立判断和决策，去发现业务缺失哪些核心的因素点，并去补全这个遗漏甚至是发现一个机会点，去发掘实现一个新的业务可能性，比如公司的内容生产是一个核心业务，去发现它未来规模化生产会遇到人力瓶颈，有没有可能通过产品化背后的技术能力提供生产力，让业务看到一个新的可能性从而修正整个内容的规划方向
• 驱动业务，与影响大盘不同，驱动业务更多是有实质性的推进而不仅仅是想法，比如通过配套的埋点监控工具，来捕捉用户一些有意义的行为，从而不断从中发现问题并推动业务去优化解决，或者发现有价值的方向，从而开放这些价值点背后的技术能力给到业务和产品，赋能他们更好的迭代业务流程
• 商业决策，这一点更多是从数据价值层面，比如可视化很多时候是从前端来主导研发和推进，从各种展现模型中为业务提供更好的决策视角，但在它之前一定是对业务和产品有足够深的理解才会形成有效的决策路径和模型
• 团队管理，这个则是一个很大的话题了，站在组织的视角把团队从弱带到强，从小带到大，从层次不齐带到规矩有章法能冲能创，成为公司具备核心影响力的团队

经过我们再次简单分析后，可以发现这些技能背后，是四个核心能力，分别是：技术、产品、业务和管理能力，把它们再拆到每个能力上，按照影响的权重，是这样的对应关系：

大部分仅仅是靠技术都不可能去推进了，甚至技术都未必是它的重要影响权重，比如团队合作、影响大盘、商业决策等，统统这些能力的集合就是一个足够资深的工程师，他能在深水区存活，并且靠此打出一片天所需要的软实力了。

怎么修炼深水区能力

聊清楚深水区对于工程师的 What 和 Why 以后，我们来聊一聊 How。开始之前我们必须认识到这些能力不是一蹴而就的，无论是你已经具备了部分能力，还是丝毫不具备，我们都要认识到它的习得需要一个过程，这个过程通常就分为这三个阶段：初级练习阶段、渐变娴熟的阶段、质变内化为能力的阶段，在初级练习阶段没有足够的沉淀前，直接跳往后两个阶段都是不切实际的。

首先是初级阶段怎么练习，我把 PDCA 修改后形成这一个做事套路，大家可以参考：

工作中的每一项具体的任务，都可以按照这个路子走一遍，一开始的时候会不适应，甚至有点僵硬的硬套模精品，多来几次慢慢就会成为一种习惯，举个例子：

团队里有很多表单开发的场景，大家的效率都很低，开发很痛苦，我看到这个问题后，就想要做一个复杂表单组件，我首先就是研究各种市面方案，研究公司的业务场景，研究已有的端产品上业务表达的交互表达方式，团队有没有人研究过表单的方案，我去收集相关的信息，并且我也弄明白为什么要开发这个表单组件，它能为业务带来实际的价值么，这个表单应该承载什么核心功能呢，做完能推动落地么，我本人能推得动么.... 这个环节就是形成判断决策的时候，也就是捉摸。

捉摸明白后，我开始制定目标，这个要符合 SMART 法则，尽量的可量化，比如：我要用 2 周时间开发一个表单组件，这个组件要可以被兼容替换到 AB 两个业务的 DEF 三个产品的 10 个页面的交互中，然后开始制定具体的开发计划，哪个时间点找老板征得同意，开始定出分几个版本来迭代，每个版本的周期是几天，每个版本完成的具体功能是什么，在这个过程中需要哪些资源，比如架构组同学的支持，业务组同学的反馈，交互组同学的设计配合，产品经理同学的理解和认同，然后把整个开发过程以可被感知的方式量化出来，透明化出来，这就是规划的阶段。

规划后开始进行技术方案的设计，模块的设计，三方库等等直到编码完成，开始推动组件在匹配的业务线和产品中使用，推动并帮助其他同学使用该组件，跟踪组件使用的效果并及时的修理 Bug 优化交互等，这个就是执行阶段。

在业务线用了一段时间后，组织一个小小复盘，针对实际应用中的问题做个收集整理，并且把过程中自己的不足也做一个检视，比如经常忘记跟老板同步进度，经常疏忽其他同学的吐槽建议等等，另外根据复盘和反馈来确保这个组件的确有提效的价值。

最后是沉淀开发组件的方法论，相应的技术文档（这个往往在开发过程中就沉淀下来了），以及组件化立项开发的套路，自己个人能力有什么成长，这种能力如何快速复制给其他新手同学...也就是沉淀 Share 的阶段。

实际工作中的问题，往往比一个组件要复杂的多的多，这就需要我们更加谨慎的对待每个阶段，把它们灵活应用并保障每次都比上一次拿到更好的结果，个人每次都比上一次方法论用的更纯熟。

上面抛砖引玉介绍了单纯实现层面可以训练的方法论，这种方法论同样适用了任何能力的练习，但方法论毕竟是方法论，真正决定它们训练结果其实还有一个前置条件，就是你的做事驱动力，也就是能力和意愿的情况。

能力意愿是前置条件

我们先讲了方法论，让大家更明确的感受到一些可执行的套路，然后再来看能力和意愿的重要性，所谓能力就是你判定问题和分析解决问题的能力，所谓意愿就是你面对任何一个突入飞来的难题或者任务，内心是抵触、认同还是兴奋这样的一种情绪。

首先，我们分析下一个员工的做事动机，通常有这几类：

• 不知道不关心，对这个任务不清楚 what/how/why，也不关心它做不做的价值有多大
• 这么做是因为必须这么做，依然不理解它的价值，但知道这样做是因为我是前端工程师，这是我分内事
• 不这么做会有罪疚感，老板对我有信任，我如果不做好会觉得不好意思，心理过不去
• 这么做对我很重要，我认同这件事交给我做的原因和意义，这件事对我的成长及未来晋升都有意义，我很重视
• 喜欢并专注去做，这件事是我一直以来期待的机会，我很喜欢很想去实现它，我很理解它做好的意义

所以一个同学有可能做不同的项目会有不同的动机，即便做同一个项目的不同阶段也会有不同的动机，这是一个完全主观的事情，但是它很重要，因为不同的动机会带来三个结果：老板及周围同事通过你做这件事所看出的你的做事态度，这件事你做完达成的结果，以及你由此而获得的成就感或者成长，当然所有的团队都希望你无论喜欢与否，都至少是理解并执行这个任务：

最怕的是理解不执行和不理解和不执行，最终反映在能力和意愿上，在一个团队的分布中，你就有了不同的象限，是能力好意愿度高的，还是能力高意愿度低的，只有意愿高能力高的人才能获得最大程度的授权和自由空间，反之不仅获得授权会缩水，甚至必须听从具体的拆解后的任务去做执行的角色，所以如何让自己无论能力高低，先让自己具备一个高意愿度都是一个明智的选项。

那么存不存在一些事情是无意义的，做了也是白做呢，一定存在，现在这样高节奏的创业环境中，试错始终是一种常态，做一件事而拿不到结果也是常有的事，但是不是因此就否定了组织的动机，从而把自己束缚的越来越紧，正面看过去好像自己不再亏什么了，反过来看自己却失去了进入深水区而该有的历练，这个历练中一定有汗水也有委屈。

面对深水压力不需紧张

其实何止前端开发，整个技术行业都已步入深水区，只是前端工程师的感知来的晚一些而已。只要把眼光投向深水区，问题就会一个接一个的浮上来，当越来越多问题浮起来的时候，就是你慢慢沉向深水区的时候，这时候不需要太过紧张，此时的发生正在见证者你的成长，欢迎大家文后提问更多问题，我们可以再换一期来针对性讨论，本文主要帮大家引导到深水区已然到来，在它之上需要储备技能的必要性和重要性，目的就达到了。

Scott 近两年无论是面试还是线下线上的技术分享，遇到许许多多前端同学，由于团队原因，个人原因，职业成长，技术方向，甚至家庭等等原因，在理想国与现实之间，在放弃与坚守之间，摇摆不停，心酸硬扛，大家可以找我聊聊南聊聊北，对工程师的宿命有更多的了解，有更多的看见与听见，Scott 微信： codingdream

写小程序