最近团队在做一个类似 ant-design/pro-components 的组件库，便 fork 了这里的代码。一是要把底层依赖比如 antd 修改为内部的基础组件库，二是需要使用公司内部的“研发和发布流程”、其中不少改动都跟 lerna 有关，为了彻底搞清楚它的用法、也看了一遍它的核心代码，总结了一些实践出来。

从 22 年入职字节、选择了一个对自己来说完全陌生的“监控”领域和“APM”团队，就这样开始了几乎每一天都是充满新鲜感、充满挑战的日子。整个团队当时有几块业务：对前端同学来说最核心的是“前端监控平台” Slardar web (对外的上云版本是 Apmplus) ，其次是 iOS/Android 端监控平台，另外还有后端监控平台 “云监控(对外)、Argos平台(对内)”。我入职当时作为团队(近三十人)内除了主管之外最资深的同学，就承担起了主管最关注的 Slardar web 这个由前端自己掌控的前端监控平台。我虽作为平台的 owner、但本身对这个领域完全陌生，内心其实是有些不安的、于是边学习边承担起各种“力所能及”的工作。

我们职业生涯的几个阶段、如果都能遇到好的主管，那是非常幸运的事、很可能会助你快速上升。反过来，比如在突破瓶颈的最关键的时候“遇人不淑”，那也会给你带来了巨大的伤害和后果。说到管理问题和leader、想举一些实际case来说明，一个好的leader、客观上应该和不应该做的事情。

本文是内部分享的脱敏版本，由于团队内有国外同事、前十多分钟说英语。 整体内容比较多，前一部分做了手工翻译、后边内容翻译软件自动翻译。

最近在支撑后端监控产品 Argos 的开发，其中在 E2E 的建设上投入了不少精力。基于团队内 Apmplus、Slardar 前端监控产品之前的 E2E 实践经验，结合了 Argos 复杂的业务，并且改变了和 QA 同事的协作方式，进而总结出了一些新的经验。全篇分为两大块做介绍：

1. 开门见山地把“实操”过程的各种要点展示出来，如果你也在写E2E、这部分经验可以直接拿来使用。
2. 简单讨论一些高级话题，比如“测试金字塔、如何写有效的测试、作用和效果”等，这部分经验可以拿来做参考。

去年底、我这边接手了一个新的工具产品“工作日志”(后改名叫周日报)的开发，经过近一年的功能迭代、现在已平稳地运行在线上。近两三个月又被 BU 老板进行了“强制性”推广，所以每到周四周五、大家集中写周报时流量就陡然上升，数据统计发现也已经成为我们“GTS工作台”流量排第二的产品模块了。与此同时、在产品功能和体验上，主管的要求和用户的诉求都越来越多，而这其中大多工作量都体现在前端上、并且有相当的难度…

我们的组织和个人，从人性的角度看、都有些天生的特点，比如：

• 都存在“过度期望”(跳一跳的目标/既还又都全要/不合理诉求/以一当十/过度自信)
• 都有“滞后性”(被动地解决问题)
• 都想“改变规则”(导致容易做无意义的东西/改变他人)
• 风险与安全感(可靠性/充分把控/进度延后)
• 不理性(对人与事强化“喜/恶”)，不自知(所在位置/主角配角/能力魄力)

最近半年、主要聚焦在两个典型“富交互”产品的开发，一个是「架构图设计器」、一个是「日志文档」，虽然也都发布到了线上，但平心而论、产品体验以及发挥的作用都不够好。反思下、抛开诸多“客观因素”，最大问题是自己一开始没有「真正」领会到这类产品巨大的 开发成本和潜藏的复杂度、及其在业务中链路起到多大的作用。这里从后一个日志产品 0-1 的过程，做一下比较详细的回顾总结。

阿里云 GTS 交付技术部 负责了很多中大型客户的众多项目交付。我们的 SA / BA / TM 等各角色同学，在做云平台或数字化转型交付时，需要梳理客户需求、设计产出业务和技术架构、并协同生态及合作伙伴完成交付。这个过程中，不可避免地需要做许多架构图 PPT，而内容上也难免有很多的重复性、并且缺乏结构化的数据来源和数据沉淀。

今年 8 月份，由于机缘巧合、从工作了 5 年半的蚂蚁转到了阿里云交付技术团队。我们知道阿里云由于起步早、持续投入大，目前产品竞争力已经很不错，前几年也基本覆盖了国内绝大多数的“电商、互联网”等典型偏技术的客户群。最近几年数字政府、新金融、新制造等概念的兴起，以前相对传统的行业也普遍需要结合“互联网和云计算”等先进技术和组织理念，因此阿里云客户群行业范围也随之扩大。

前一段时间才看了躺在书单上挺久的《刻意练习》，书中提到的练习方法其实跟以前读书时老师教的也差不多、另外讨论“基因差异的真正作用”的角度也挺好。但自己印象最深刻的是书中讲怎么 “保持动机” 以解决 “新年决心效应” 和相应地 “意志力根本不存在” 这个事情。

SDK 是什么？简单说一般包含一个或多个API、文档、依赖的一些开发调试工具，提供给第三方开发者使用的一些功能集合。可能在上个时代，开发人员最广为熟知的 SDK 应该是各大操作系统提供的开发包、硬件集成工具包等。现在是互联网时代、随着一些平台型企业、用户量很大的 APP 崛起，移动和 Web 平台的 SDK 也变为主流。国内最典型的比如 微信、微博、支付宝的 SDK，已经成为大多数网站或商户的必备依赖。

互联网业务的创新性直观体现在大多产品只有两三年的生命、之后就有新产品替代，一些活下来的也基本隔两年都会改版升级品牌。但还有一些产品、典型例子比如支付宝电脑版网站的 “安全中心”、“收银台”、“安全控件”，由于一些客观原因（2012年的 all in 无线）长久没有重大升级，但因为也是业务主链路、非常重要而不能下线，因此就这样“放”了 10 年在那里。当然平均每隔半年还是会有一些小功能需求的。

背景 - 内驱力

之前三年多的工作、主要围绕 antd / antd-mobile 组件库的建设进行，大多数时间都是投入在组件库本身的编写上，中间穿插一些业务支持、主要目的也是为了实际推动这两个组件库的业务落地试炼。同时这三年里部门的 basement 研发平台、凤蝶活动页制作平台、antv 系列的图表可视化库、umi 和 bigfish 应用脚手架 等也都发展成熟并广泛应用起来，但遗憾的是个人因为一直专注于 UI 方面、这些完全都没有正式使用过，也没有很注重对这些优秀产品发展过程的跟进和学习。之前专注于一个点的“闭关修炼”形成了一方面的深度优势、但更多陷入了工作细节、跳出来思考的习惯也少了很多，逐渐意识到这是很危险的信号。另外以前可能对“专注”这个词有什么误解，“专注”确实会让你形成优势、但专注久了优势也会变成劣势！

前端发展到今天，组件化的概念已经深入人心，特别是 react 得到广泛应用以来，应该没有哪一个从业者会说自己从没写过 component 了！而自己这几年的工作、除了业务支持外主要的技术积淀、也都围绕着 ant design (mobile) 前端组件库。个人早期参与的是 PC 组件的建设、之前也专门针对 Tree / TreeSelect 组件总结了一些开发心得，近两三年主要参与建立起了 mobile 组件库。

这是一篇回顾文、写于 2019-04 月，而标题时间 2018-06-19 是原开发团队完全交接出去不维护的时间点。个人长期作为这个项目的主 owner 也负责了最终的这个交接任务。

说实在的，antd-mobile 是对我个人来说至今做过的“影响最大”/“最成功”的事，也从中拿到了晋升等还不错的结果(个人觉得是因为这个)。但这个事、由于一些技术和非技术的原因，本来是不愿意写到公开的文章上，也确实至今还没写一篇相关文章说这个事。但又想了下，这个事情交接之后就是彻底过去了、而作为主 owner 简单描述一下主要历程，算是对各方做个交代和记忆吧。