钉钉全栈化实践总结-前端篇

作者：马赟 阿里云钉钉业务平台团队

一、背景

全栈工程师一直是个热议的话题，我所在的部门是钉钉的智能办公-场景技术，作为部门的前端“独苗”，要一个人收口部门十几条业务模块的前端工作，一个人要pk20多个服务端同学，在全局视角看这显然不是长久之计，我们在业务上会面临资源、效率等问题，而我们的保障策略是推进专业前端+后端研发全栈化的方式来应对。其次可以发挥专业前端在特殊位置的价值，让整个人力的利用效率最大化，最后可以通过实践将这套方法论贡献给有需要的团队去复用实践！

业务团队面临的问题

1）资源问题：目前业务团队在业务支撑方面，前端资源存在较大瓶颈。

2）效率问题：由于前后端的gap，业务、技术、交互等方面的沟通，成本不优

保障策略

专业前端+后端研发全栈化

• 专业前端：负责业务领域整体前端架构的设计、规划、优化以及负责性较高前端需求实现等

• 全栈工程师：负责中低复杂度前端需求的全栈化研发

1.1 全栈化的好处

1.1.1 具备更强更灵活的资源能力，为后续业务发展蓄力

• 提前准备好全栈化的建设，需求可以快速迭代上线，自给自足，帮助业务快速拿到结果。

1.1.2 拓宽知识面，思路考虑更完整

• 提高研发效率，提升解决问题能力，提高排查问题效率，可以快速侦破问题，及时处理问题。

• 向前一步，不给自己的能力设限，扩充自己的知识面，离架构师更进一步。

1.1.3 能理解不同岗位的同学的诉求，增强同理心

• 后端同学能理解为什么前端同学会对接口字段提出很高要求，期望后端提供的接口按照开源社区的标准来定义（好的接口是自说明的，不用过多的文档，遵循业界 API 设计规范，使用接口符合人的直觉，接口字段稳定）

• 前端同学能理解为什么后端同学不愿意轻易写特殊逻辑判断（一套模型已经定义得很优雅了，加个特殊分支就破坏了代码的一致性）

二、如何全栈化-我们怎么做的？

简单来讲，参与全栈化的同学要做到四个步骤，下面将围绕服务全栈化同学的视角，展开讲述我们落地过程的细节与机制。直接上图：



全栈化四部曲



备注：Step4 持证上岗 不是适用于所有部门落地全栈化作为参考，也不是衡量学习前端的唯一途经。

step1: 学习前端

前些天关注到这样一个路线图，https://github.com/kamranahmedse/developer-roadmap，用于指导你成为一个合格的开发者需要了解的东西，看完之后获益良多，自觉很适合作为钉钉同学学习前端开发的路线指导。因此进行改造后初步变为钉钉前端开发RoadMap，作为部门新人学习前端的一个导向。请注意这些路线图的目的是给你一个轮廓，并在你困惑的时候停下来看看接下来该学习什么的时候指导你，工具和框架经常都会变化，我们更应该了解为什么某个工具比其他工具更适合用在一些情况。

1. 前端开发学习RoadMap

这份图多为个人意见，仅供大家参考。



2. 资料补充（RoadMap每个节点代表一个里程碑）

2.1 阶段一：基础知识学习：





基础不牢地动山摇，前期打好一个基础很重要。

这部分的知识点比较基础，要先具备对基础知识的掌握。

2.2 阶段二：4-7 前端工程化学习





理解并掌握前端如何使用webpack等工具对你的代码进行打包配置，掌握前端资源部署的原理。



前后端分离：从服务端视角理解前后端分离。



图：前后端分离/未分离



分离前服务端的代码会有一个VM模版引擎写在java工程中，当发起URL Requst时，会返回这个HTML Response。

public String sayHello(Model m) {
    List list = new ArrayList<>();
    list.add("hello");
    list.add("hello world");
    list.add("hello world ！");
    m.addAllAttributes(list);
    return "hello";
}

Controller来填入数据，同时View层来模板引擎消费数据，处理数据展示。



变化1: 模板不再出现UI逻辑

变化2: SPA单页面应用 与多页面应用的区别

2.3 阶段三：8-11前端框架应用学习



选择一个前端框架，我认为学习前端框架有三个重点：

• 理解MVVM模式、单页面应用、前端路由；

• 掌握框架提供的API方法，比如页面的render原理、数据变更如何更新视图、以及框架的生命周期等；

• 会使用数据状态管理来分发数据到你的页面。

step2 实战上手

这一环节一定是最有效也最重要的环节，也是学习前端最快速的方式。

• 全栈化同学应当参与前端需求的评审。

• 完成前端需求的系分技术方案，包括实现思路、系统结构图、评估影响面，具体看‘系分文档模板’。

• 过程中遇到问题及时与前端师兄对焦。推动全转化的人要把自己当成一个项目经理对全栈化的同学进行风险管理，有每日对焦完成进度、风险提早暴露。

每个迭代都要保障全栈化同学在前端的投入时间，短期看不到收获，但长期来看是一定有价值的。

step3 沉淀

钉钉全栈化宝典-自查手册

高效学习 & 程序员练级攻略 · 语雀

里面记录了70余篇关于全栈化落地过程中的文档沉淀，其中包括：

• 开发遇到的前端问题以及背后的知识点总结。

• 项目复盘、问题复盘。

• 培训课程以及分享内容。

后续期待更多同学参与共建，一起让前端开发更加简单。这是一个长期需要去做并且一定会有回报有价值的事情，需要大家一起来共建，让更多的人参与进来一起进步。

step4 认证检验

玩游戏打怪会升级，前端开发也一样。

因此我们需要落地一个机制用来检验前端开发同学对前端知识的掌握及学习成果具体对应在哪个等级上。

以钉钉智能办公认证为例，上图针对每一个阶段都做了详细的要求说明。

认证形式为答辩形式：参与全栈化的同学将自己的材料总结后现场进行功能展示，由评委来进行打分。



中级认证要求：

1.完成一个页面的开发，并可跑起来

2.有点击事件

3.有使用jsapi

4.有使用引入npm包并且运行

5.页面元素较为丰富，达到1/2 屏（iphoneX机型标准)

6.DingDesign组件与自定义组件至少有一个

7.有arms监控代码

8.有组件化交互

9.有状态存储器Redux



高级认证要求：

1.跨页面通信

2.对现有小程序能力增强（扩展能力）

3.贡献小程序UI组件Antd组件库

4.现有native功能完成小程序改造

5.可用数据指标衡量的性能优化



代码规范：

组件优先使用AntDesign组件https://ant.design/docs/react

像素单位统一使用rpx

图片统一采用外链，mediaId或iconfont，不要使用相对路径引入

代码需要经过eslint检测（可以直接使用命令tnpm run lint:fix 修复代码）

整体目录清晰、命名规范

有容错机制（如对象序列化必须 try..catch，接口请求有异常处理）

评审细则：

• 功能完整40分： 独立应用：有3个以上页面，包含与后端的数据交互，包含增删改查常规能力。

• 业务场景5分： 不堆垒无意义的应用，真正为了解决某个方向问题或提高工作效率的背景下而开发应用。

• 稳定性15分： 提供数据大盘，提供error日志并根据数据分析应用目前情况。灰度机制建立回滚能力介绍。

• 技术考核30分：针对应用中涉及的知识点进行考核，能理解问题要点准确回答。

• 开发规范10分： 代码规范，理由脚手架生成等手段保障代码的规范性，变量命名清晰，文件结构符合规范。





认证权重占比参考

提交审核流程：提交审核流程到师兄->主管 完成审批后 颁发认证证书。

充分认可并认可全栈化同学的产出和成长！

三、过程管理

3.1 周会机制

定期参与内网前端相关文章或者专题分享会的学习，并在周会/周报/专项分享会中分享相关学习心得，半年至少2次，纳入KPI中。

高效周会一小时：

• 同步本周需求进展和风险，及时暴露出来方便整体调整把控，遇到的问题记录总结沉淀，及时同步分享给全栈化的所有同学。（纳入全栈化宝典）

• 现场答疑解惑，回顾上周action和本周action。

• 拉通团队中相关涉及前端的业务项目，碰撞、探讨，侧重业务、技术结构性共性问题的挖掘、定义和解决，并引导沉淀通用平台能力并推动落地与能力复用推广。

3.2 全栈化双周报

《全栈化双周报》能最有效且最直接让部门知道我们做的事，让问题被暴露出来从而接受一些好的建议做出及时调整，同时让全栈化做的好的同学被看见！所有同学要求在周报中增加思考总结部分，反馈这段时间遇到的结构性问题、思考与解决或者业务、技术趋势的判断，主管以及虚拟前端主管有针对性进行解答。

直接上模板

【上周action回顾】回顾上一次周报中的action同步更新完成情况。

【总体进展】全栈化目标的关键成果及进展，比如同步完成了多少次培训、学员进步情况等。

【培训计划进展】同步当前培训计划的进展。

【学员工作进展】：明细表格、体现工作明细、时间点和进度，对做的好的同学给予实名赞扬，让大家看见。

【问题总结】针对全栈化推进过程中遇到的问题。

【下一步规划】分享计划、以及文档沉淀计划。

【思考感受】说一下当前全栈化推进过程的思考和推进过程中的感受。

四、结果

以我所在的部门为例

• 【工作量】在过去六个月全栈化六个同学完成了90人/日左右的前端需求工作，每个迭代能完成50%以上的前端开发工作，并且可以做到无线上客诉和风险。（这里包括系分设计、开发、测试验收、设计还原、灰度计划以及上线后的大盘数据监控数据分析等流程）

• 【成长】而在过程中，我们一半以上我们服务端的同学也成长为了前端应用的owner，做到真正意义上的全栈化工程师。

• 【沉淀】 我们沉淀了全栈化宝典手册、完善的问题记录、复盘记录文档、和分享培训课程供新人学习提效，加速成长。

五、过程中的思考

5.1 我们踩过的坑

• 同样的坑会绊倒一样的同学。
  
  通过全栈化宝典沉淀出来。每周同步大家遇到的问题原因、背后的知识点以及解法。

• 需求交付压力大，线上发布风险高。全栈化同学刚上手需求，上线前发现不符合预期导致返工。
  
  这种问题本质上是过程管理没有做到位，一定是需求过程管理机制上出了问题，文章所述的每一环节都很关键。

• 全栈化同学需要兴趣导向，更需要完善的培训机制，每个人程度不一样，要及时听他们的反馈和建议，做出及时调整。

5.2 思考

• 全栈不代表降低要求，全栈是为了提升开发效率，如果质量差，不好维护，反而降低了团队效率。

• 避免只是多涉猎，而缺少实战，看过不等于会运用，部门提供全栈化的机会是一方面，需要全栈化的同学有坚定的决心和具体的学习计划。

• 全栈化落地是一个艰辛的过程，但长期来看一定是有价值的，可以很负责任的说我们已经尝到了甜头。过程中有问题，甚至造成返工，这都是预期内，也是必须要经历的，纸上得来终觉浅，绝知此事要躬行说的就是这个意思。

六、后续计划

• 邀请更多的小伙伴一起建设培训课程、全栈化宝典自查手册以及全栈化学习文档，沉淀高质量前端开发文档建设。

• 让全栈化这套机制为更多有需要的团队带来真正的帮助和价值，持续把价值做深。

无论你是前端后端客户端，有需要一起合作的同学欢迎加入，共建经验交流，一起做点有价值的事情！欢迎来投稿交流。邮箱帐号：[email protected]