总结回顾
分享人-施德来（有赞前端负责人）
有赞前端4年发展历程回顾
缘起，3月22日准备，4月11日 万科、掘金、SegmentFault、上直播赞助,4月21日分享。有赞前端技术开放日
有赞前端开源项目总结回顾
Zent组件库 基于React,主PC,有赞后台、微页面、SKU规格选择器、色彩、规范、主题
Vent组件库 基于Vue,主移动端
ZanUI-Weapp 微信小程序组件库
Felint
One More
技术产出原因：
- 业务逼的（多且复杂，C端用户多）
- 工程师文化
- 注重技术基础
技术项目本质：理念、套路、规范的工具化（工具>文档）
开源项目本质：传达一个团队的理念、套路、规范
理念：靠谱！有追求！
为什么开源？
对内-更高的要求
对外-理念输出、人才输入
失败技术项目分享
UI-Test-测试用例，适合变动较小比较稳定的项目
性能统计工具-浏览器performance API、服务器数据库持久化
Hulk-PC Vue组件库、被饿了么ElementUI取代
XPage-增删改查、图表，使用项目少
失败原因：没有准确估计投入产出比
有赞开源项目最佳实践
分享人-李晨
最佳Github使用姿势
- 一个好的README，建议：
格式：制定规范，统一形象；
语言：尽可能英语，不要把自己的用户局限在国内；
开发指南：帮助参与者快速上手。 - Github 模板：规范Issue + Pull Request 内容
根目录建.github，建立md模板。 - lable 管理
3个维度：状态（待处理、已处理），类型（bug、新功能），优先级。 - 持续集成 CI
PR提交校验、代码覆盖率
Travis、CircleCI - 里程碑-版本进度管理
技巧分享
- 版本发布遵循 Semantic Version，从V1.0.0 => V2.0.0；
- 代码规范用工具强保证，如：prettier、gofmt、refmt等；
- 开启Github PR 的 Squash Merging 功能，分支合并commit合并；
- CI不仅仅是用来跑测试的，脚本配置：代码校验；
- 给人看的更新日志要手写，推荐：机器生成+手写
- 论坛、群答疑
工具推荐
- 大仓库（Mono Repository）管理：lerna, npm多包管理依赖
- Change Log 自动生成：github-changelog-generator
- 自动创建Labels：git-labelmaker
本地调试线上代码–ZanProxy
分享人-小麦
提纲
- 痛点问题
- 方案演进与比较
- 设计与实现
- 后续计划
痛点问题
场景：开发的web应用，后端接口（本地调试）已上线（host切换），但有部分接口未完成（数据mock）。
本地调试：启动困难，上传服务器流程长且慢。
host切换：浏览器有缓存，host多，难以管理。
数据mock：等待数据浪费时间，mock数据污染代码。
方案演进与比较
- Mock Only
- Chrome Only
- ZanProxy: 本地文件，线上代理。
zan-proxy特点
- 支持Https, WebSocket代理
- 可通过自定义插件扩展
- 项目维度管理
其他：Charles、Fiddler
设计与实现
后续计划
- 支持WebSocket监控
- 推出桌面版
让前后端协作更高效–ZanAPI
分享人-连哥
痛点问题
- 文档问题
以前：提供方手动创建、维护doc文档
问题：难以维护，更新不及时 - Mock数据问题
以前：微信沟通，使用方手动创建，利用工具做数据Mock
问题：难以及时沟通 - 联调问题
以前：口头沟通
问题：无法确定联调时间点
解决方案
- 文档：操作方便；快速更新；包含足够多信息，但不能造成提供方太多额外工作量；友好的接口定义展示
- Mock数据：合作双方同时修改，即时生效（ZanAPI）；自动生成随机返回值（JSONSchema）；能根据不同请求值返回不同数据、对mock数据修改进行有效提示
- 联调：科学判断是否真的可以开始联调（接口集合测试）
业界现有方案：swagger、APIBlueprint
实现方式
- Intellij Idea 插件 + Java代码解析
- 包含足够信息（包含备注）：自动下载依赖包、使用JavaDoc解析Java注释、生成格式化接口数据
- 友好的接口定义展示
API文档生成流程
- 依赖获取–使用 Idea 提供的Api,生成 mainInterface;
- 生成依赖文件–pom.xml依赖,下载–使用maven下载完整依赖,解压,javaDoc + 自定义doclet 生成格式化接口数
据 - 联调&测试
落地流程
找一个团队先落地，迭代 -> 跟已有系统对接 -> 扩充线上api数量
正在做的事…
- 完善的团队接口管理
- 更有约束力的接口规范
- 基于场景的测试
- 接口Timeline
Node在有赞的实践
分享人-KK
提纲
- Node 基础框架的迭代与演进
- Node 接入有赞服务化体系的历程
- 未来需要做的一些事情
Node 基础框架的迭代与演进
Koa + 中间件（内部管理系统） -> Koa + 中间件 + 脚手架模板（有赞官网） -> Koa + 中间件 + Astroboy 阿童⽊（阿童木0.0.1） -> Koa + 中间件 + Astroboy 阿童⽊ + Youzan Base Framework + Plugin（阿童木1.0.0）
Node 接入有赞服务化体系的历程
- 服务化
- node如何调用Java
- 方案1：Java 添加注解方式生成 Restful API
缺点：Java开发需添加额外注解；运维需对每个服务配置域名；Node需维护很长的配置文件；HTTP方式调用，性能低。 - 方案2：Node 直接支持 Java Dubbo 接口调用
缺点：对前端不友好，每个参数都需写明参数类型；Node框架需负责hession协议解析；其他语言也需重复实现。 - 方案3：对方案 2 进行了优化
优点：使用简单（HTTP）；多语言接入成本低；后期方便做协议层优化。
Todo
- Node性能监控
- CPU Profile、GC Trace、堆快照、Heap Profile
有赞内部代码管理工具
分享人-冷涵
提纲
- 分支集成–公交车、快车
- Code Review–基于 GitLab 二次封装
- 前端在线打包–基于统一工具的服务器打包
- Changelog–基于 GitLab Merge Request 的信息整理
分支集成–公交车、快车
历史：巨型入口级应用；业务快速增长、小需求迭代快；回归测试到发布上线流程长、排队发布。
模式
- 公交车： Code Review&test（发车前安检）、荷载无上限、携带行李。
- 快车：功能间依赖度高，产品迭代迅速（小程序）、集中回归。
Code Review–基于 GitLab 二次封装
目的：旧版GitLab面向开源，是评论+1模式；串联分支合并的流程。
内容审查：有组织性的Review、发散式的邀请。
数据统计：目的：提供可靠参考指标、促使大家使用推广；特点：评选部分最佳、不同项目不同开发人员的review频次。
前端在线打包–基于统一工具的服务器打包
为什么：核心项目大，打包耗时长；webpack配置复杂、落实前端项目规范。
核心逻辑：Superman工具封装打包流程中的关键环节，如dev、prd、cdn、hash等；Web service 提供可视化界面；简单的任务调度。
Changelog–基于 GitLab Merge Request 的信息整理
原理：基于GitLab；按照Tag区间整理Accepted Merge Request；通过Label来进行分组。
作用：提供代码仓库的可用变更日志；和快车、公交车打通；方便发布前总结回溯。