【第1545期】在淘宝做前端的这三年 — 第二年

前言

第二年主要总结如何评审需求和推进项目，如何理解业务，飞冰项目的起源等。今日早读文章由@于江水授权分享。

正文从这开始～～

内容平台和达人平台

2016 年 5 月份左右，淘宝海外交接之后，老板交给我了新业务就是内容平台和达人平台。顾名思义，内容平台就是管理淘宝内容的平台，可以写文章、发微淘动态、上传视频等。达人就是内容创作者，他们除了在写内容之外，还可以在达人平台上面管理自己的信息、查看等级和权益、查看收益等。

虽然他们很相关，但这却分了两个业务，背后分别对应两个后端团队，加起来 20 多个人，结果老板就让我一个人对接。咨询之后原因如下：

1. 这两个相关业务，最好是一起搞比较高效，后端架构已经成型，但前端可以安排一个或者一拨人。

2. 我们组开始负责中后台技术产品 ICE（飞冰），我们这个产品就是应对这种缺前端的中后台系统开发需求的，所以这块业务正好是最佳落地场景。借助 ICE 模式，我仅作为业务接口人，一些具体组件开发任务可以分散到 ICE 团队里一起开发来解决。

所以我迎来了最忙的几个月，极大的考验了任务规划能力和工作能力。因为两个业务平台有一些子页面，用了 KISSY、KISSY Editor、Vue、自研编辑器还有无线端页面，代码比较乱。此外由于之前就知道要交接，一些业务需求直接 hold 等到交接给我之后再排期开搞，这部分老需求仍然需要在之前代码里改。基本上白天到处评审需求排期，晚上开发的状态。与此同时，内容平台和达人平台都希望将前端直接重构掉，换代升级，这是个相当大的工作量。在这么忙的情况下，淘宝头条还拉我评审一个比较大的需求。

我给淘宝头条一个项目评了一个三个月的工期

2016 年 6 月那会，头条类业务在迅速崛起，淘宝头条也被给予厚望，属于重点业务。它主要是一些头条新闻、导购类内容，因为头条创作者在达人平台进行入驻并进行创作和管理信息，所以属于我们达人平台的业务方。这次头条业务方有一堆增强富文本功能的需求和一个新的入驻填表流程系统的需求提交了过来。

富文本算是前端挺麻烦的东西，这个需求要在老富文本代码上面扩展这些 UI 和功能，特别是还有一项功能：支持 Word 文档复制粘贴，支持里面的多张图片一起上传。这个功能我搜了下技术方案，只有 QQ 空间实现了，实现方式是需要装浏览器插件获取本地文件系统权限，然后扫 Word 文档 Cache 目录发现对应图片文件然后上传。开发这个功能不是前端范畴了，给我半年也够呛搞定的。使劲砍了下需求发现砍不动，挨个评审下来加上现有高优先级需求差不多得开发三个月。跟他们说了之后，一屋子惊讶的叫声，远远超出了他们的预期。

回到工位没过多久，老板很严肃的叫我过去白板墙那边，说是大老板圆心找我有事情，到了一看原来是业务方老板直接一封邮件投诉到我大老板这边了，他们期望月底上线，怎么给他们排了三个月。由于是新交接，对我的技术能力有极大的质疑。

所以老板叫我过去一起评估看看这个需求到底是什么情况。所以我就把需求和现状都描述清楚，经过两位老板的评估，确实少不了开发量。目前淘宝富文本还是老 KISSY 的，没有 React 体系新的富文本，对内容体系的确是缺一套，所以圆心老板就把这个富文本的任务交给我了。

最后的结论就是新加了一个高级前端工程师跟我一起做，优先级调到最高，并对每个需求点评估时间列出来，重新开评审会，让业务方自己对照时长砍需求。 最后砍掉了很多需求，那个需求降级为从网页上支持复制多张图片到编辑器，不懂技术的人可能想不通，都是复制多张图片到编辑器，为什么网页上可以做，Word 就不能做？但其实网页复制解析 HTML 就可以拿到图片 URL 然后调接口上传淘宝 CDN，但是从 Word 文件复制则涉及本地文件读取了，受限于浏览器权限，技术成本完全不一样。

项目开始之后，果然发现了很多风险：

1. 交接混乱期，平台方没有 PD 出面控制需求，完全根据业务方的需求的来开发。业务方只会考虑自身的需求，很可能破坏平台功能的一致性，给其他业务方功能带来一些风险。

2. 没有 PM（一般是后端承担，因为后端技术方案通常会比前端复杂，需要考虑的事情更多），绝大部分人都认为这个项目主要是前端的工作，所以需求都来找我，后端很少参与评审，更没有一个明确的 PM 角色。

我是这样消除风险的：

1. 跟另一个同学合理分工，拆开后互不依赖， 自己选择了比较恶心的富文本和老后台部分（因为以后要负责做新富文本）。

2. 加班没得跑了，需要以最大精力先解决最具风险和不确定性的部分。劳动节前两天，我直接全天在家从早开发到晚上，搞懂原来富文本的代码，开发掉了绝大部分有风险的需求。第三天才放松休息了一天。结合其他积攒需求，这段时间基本每天晚上回家都工作，开发到凌晨两点才睡觉。

3. 主动担任 PM 角色，并发送日报，抄送业务方和老板，指明今天进度，被阻塞的问题和谁来解决，以及当前项目风险。在日报里明确指出了很多后端相关但是没做或者不知道的工作，并给出解决方案。这种方式可以让业务方、老板和项目组成员都及时明确风险点，并盯住对应问题处理人使其尽快完成，减少阻塞。

最后结果：

1. 我们两个人分别开发了一个月搞定上线。如果没砍掉很多需求，一个人开发，的确需要三个月，我评估的工期没有问题。

2. 业务方对我的印象从水平不行转变成了靠谱。因为为了项目进度加班的日报都可以收得到，并且可以很负责的去指出一些风险追踪其他人的进展来保障项目进展。从此之后这个业务方 PD 提过来需要我开发的需求，再也没有质疑过我的排期。

回头来看，如果再回到一开始，即便是冒着被投诉的风险，我还是会如实排期三个月。强行缩短工期只能压死自己同时增加上线风险。当然前提是真有很大工作量，能经得住老板的评审才可以，否则可能会认为你工作能力真的不行。

如何能评估比较准的工期呢？一个很简单的公式送给大家：

• 需求非常明确而且经常这样做：自己评估时间 * 1.5

• 需求不够清晰，有可能变，但是代码和技术方案熟悉：自己评估的时间 * 2

• 需求不够清晰，代码和技术方案也是新的，需要探索：自己评估的时间 * 2.5 or 3

自己评估的时间一般会留点 buffer，自我感觉应该没问题，实际上开发过程可能会有各种会议、需求和技术方案变更或者突发事件。所以多留一点 buffer 会更好，因为这个时间点可能是下游运营活动上线时间点，评估后业务方觉得太长可以砍需求拆成两期或者调整上线预期，但一旦设置了时间点，不应该跳票。如果你比预期早完成上线，皆大欢喜，如果你一次次的告知业务方还需要延期一两天，效果正好相反。

ICE（飞冰） 艰难的落地

开发完淘宝头条项目之后，也快消化完交接时积攒的那些需求，便开始着手新版内容平台和达人平台的开发。这时候 ICE 基础组件 部分也已经通过包装 Fusion Next 完成初始版本，脚手架和命令行工具也已经完成，开始落地业务并抽离业务组件。

ICE 的思路是这样推导的：

1. 后端开发资源要比前端开发资源多。

2. 后端团队自身就有很多后台管理系统、业务运营系统的开发需求，但是在淘宝，这种非对外的内部管理运维系统是不会投入前端资源的。

3. 所以有些后端开发需要学习前端技能，但是受限于精力和寻找资料的能力成本比较大，而且学习到的前端技能也比较乱，从已有的后台系统来看，普遍很丑很难用。有的用 jQuery，有的用 Bootstrap 等，技术方案、用到的组件各异。开发成本大，交接维护成本高。

4. 后端同学并不害怕编写 JavaScript 的业务逻辑，普遍最怕的是写 CSS 调整样式。

5. 在新时代，前后端界限已经模糊，后端也需要具备一些前端开发知识。如果一块功能一个人做好前后端功能，此时效率是最高的，因为不需要沟通接口等。

6. React 的写法相比 jQuery 等更有“编程”的感觉，更符合 Java 开发的习惯，而基于基础组件，开发同学不需要编写大量样式也可以开发出比之前美观一点的效果。

所以 ICE 最初就是基于 React 的一堆基础组件 + 业务组件 + 脚手架 + 前端教学文档 + 前端答疑群。我们的卖点就是：你系统里的复杂组件如果可以被其他系统复用，那么我们来开发；我们提供前端技能培训和答疑，在我们答疑群里问的任何前端问题都可以被我们解答，复杂问题我们提供上门服务。

好像挺正确挺好的，但在后端视角就是：明明是前端领域的工作，现在要给我来做了，平白无故给我加了很多工作量。所以最初的推广十分艰难，尤其是在重构达人平台的这个过程。

这个问题跟人的关系很大，有的开发在之前公司就需要做一部分前端工作，有了 ICE 他们反而会感谢，因为不用自己调很多 CSS 和组装 Copy 来的 jQuery 代码。而没有 Web 开发经验且不愿意学习前端相关知识的同学，则会相当抵触。解决这个问题只能自上而下，通过高层沟通确认这种合作模式，并且传达给下层这是日常工作的一部分，而不是额外的工作。而我们前端能做的，就是尽可能服务好。我们提供的答疑服务是上门的，如果你遇到了不好描述的问题，我们会直接到你工位上解决。而且我们的答疑钉钉群不会设置轮流排期，因为这样可能会产生推脱的情况，我们的规则是谁看到立刻跟进解决。当然这样对我们的成本是很高的，有时候两个人可能同时在排查一个问题。在夏天我们甚至举办了个 ICE 送清凉的活动，拿着我们团队得到的奖金买了很多雪糕分三天免费发放给后端，来提升知名度和好感。

达人平台高层对接沟通好了，愿意尝试这种新模式，但是需要我入驻项目室实时答疑解决问题兜底。项目组成员做好分工之后，就开始分别开发，踩了非常多的坑，苦不堪言。比如：Mac 电脑用 shell 脚本一键配置环境很顺利，但在 Windows 电脑上让开发同学自己手动配置 Node 开发环境就要命了，有的安装错了应用和版本，有的漏装东西，所以后来我用 bat + rar 自解压包裹了稳定版本的必备软件，搞了个 exe 文件方便安装，缓解了这个问题；当时 Fusion Next 的组件也刚开发出来，bug 非常多，我们提了非常多的反馈和 MR 来修，但是给开发的印象就非常不稳定。有一次甚至阻塞了半天，疯狂朝我吐槽，我们作为中间商十分委屈，也曾经冒出过无数次的念头，打算将底层组件从 Next 切回 Ant Design 。但 Fusion Next 项目成员修复还算积极，我们不断开“批斗会”，他们也虚心接受快速调整。站在现在角度来看，用 Fusion 是对的，因为 Ant Design 重 Design，皮肤覆盖、配置十分困难，而各个团队、BU、业务的后台，是有明确主题需求的，而 Fusion 的一大优势就是全链路、体系化的解决了一套组件不同风格定制的功能。（后续我会制作一些相关内容详细介绍）

这段时间各方面压力都很大，ICE 小组忙着开发新组件、脚手架和修 Bug，开发同学用新东西开发不适应、效率低问题很多需要协助，我又接了开发内容平台需要的 ICE 富文本组件的工作。不同于头条项目开发到晚上两点，我调整了作息，基本早上 7 点多到公司赶紧吃饭，开始给内容平台开发富文本组件到 9 点多，然后进达人平台项目室然后开发达人平台到晚上。由于项目室有十个后端，白天基本就是转着圈解决他们的前端问题，晚上拿他们的代码来优化样式补齐需求提测。（站在现在的角度来看，早上而不是晚上开发富文本组件这个安排是十分必要、合理的，因为自控力、精力在早上是最好的，最适合这种逻辑、代码复杂的工作，也比较安静。关于自控力和工作节奏，我将会在第三篇详细讲解。）

即便这样，还是有两个后端同学爆发了，直接开始对我攻击天天吐槽，有一个同学一旦遇到小问题，就直接用电话钉我，搞得我都没法正常工作了。虽然发生了冲突，但是阿里巴巴规定了不能在公司里打架，那么：

跟同事产生了工作冲突应该怎么办？

跟同事产生冲突，显然是不能打架，应该尽早明确问题所在，对事不对人，解决问题。如果有必要就需要找老板来解决。当我跟老板反映这个问题之后，老板和 Winter 叫上他们俩和我就一起找休闲吧沙发开了个小会。

重点聊了下他们的感受和问题，并就问题在高层的角度做了些解答和解释，最后给出了一些我们这边的解决方案和排期。问题就顺利的解决了，他们愿意恢复到正常的开发节奏，后来跟我的关系也变的挺好，合作也挺愉快了，直到离职后还经常朋友圈互动。

很多时候解决不了的问题要赶紧找老板，如果自己硬碰硬可能适得其反，有高 P 出面调解和分析，看问题的角度可能就变了，问题就解了。经常看到前端讨论群里有吐槽跟产品经理冲突硬碰硬的情况，其实没有必要，可以反馈给老板让他给些建议或者让他联系产品的老板解决。工作就是工作，经过协商和调整，找到大家最舒服的工作方式才是正解。因为冲突打架最后被开才是十分悲剧也是毫无必要的。

就比如前段时间那个 “APP 主题需要按照手机壳颜色来更换” 的需求，导致程序员和产品经理大打出手最后双开，其实没必要。完全可以从业务本身来梳理下这个需求，查看这个功能的上线是否可以为当前业务的核心指标带来价值，它的需求来源是什么。如果说希望通过更多变化来增加 APP 的活泼程度，吸引用户，那么完全可以拆两期，第一期先随机改变主题或者支持用户手选，看看业务指标是否可以上涨。如果数据没有上涨也不需要做第二期了，上涨之后可以继续优化。如果是产品经理或者老板强行要做，那么可以按照难度评估个很长的时间，比如需要半年。可以让老板介入评估（开发经验更丰富，更有话语权）并向更上级反馈这个研发成本，如果可以接受这种成本，技术团队就可以开始专注研发相关功能了，完全没必要打架。

阿里基层领导应该是压力最大的一批人

转眼就到了双十一了，原定计划六周的重构项目，结果延期了五周多的时间才上线。里面有各种原因交织在一起，有些是因为遇到了老旧系统历史遗留问题，有的是跨团队协作没沟通好，也肯定有一部分原因是使用 ICE 新方案增加了后端开发工作量。但最终结果就是没有如期上线，而且直接耽误了双十一的需求。

所以业务方组织了一场检讨会，召集各方开发进行这次项目的 Review。我和老板也参加了进行自我批评，老板可能场面见的比较多，自我检讨很自然，轮到我，我只能故作镇静的哆哆嗦嗦自我检讨说：基于这种项目研发资源配比和协作模式，我已经尽了全力了。从此我就挺关注自己需求的时间点，尽可能少延期，因为发生这种事情真是太尴尬了。

不管如何，最终结果是达人平台业务后端交接，原来团队规模缩小了，成员有些离职了有些转岗了，业务方也换了一些新的人进来搞这个业务。

其实淘宝前端团队本身也有过几次不成功的大项目，最后结果基本上是都是团队拆散，一些离职一些转岗。毕竟辛苦做了一年没做成功，都很不甘心，也不愿意留下。

这让我体会到了团队间竞争的残酷，通常以年为单位，做好了，晋升、奖金、扩大规模，做不好，拆散、换人、离职。但正是这种节奏和变化，能让阿里这条大船充满活力，快速试错调整，立于不败之地。

通常做的好的同学，会逐步虚线带领小组处理一条业务线或者一个领域的工作。持续做得好，下一年可能就会得到晋升，组织结构调整会让你实线负责一个团队，来负责一条业务线。这时候就要求就更高一些，而且你要对结果负责。除了做好目标设置、规划和推进项目，还要关心人员流失和晋升情况。有时候项目节奏高压了，人员就流失了，缺人了还要加大精力来给自己团队招聘；项目走偏或者进度落后，就会被认为没达到目标从而被打 3.5 或者 3.25，这样人员得不到晋升看不到希望也没有很多年终奖，很可能离职或者转岗。如果上层认为你没有足够能力，也会将团队拆散重组。

其实最难受的是自己打拼了一年，居然以这种结果收场。

虽然这次业务落地并不算是成功，但是对于 ICE 则是一次全方位的测试和升级。经过各种问题的解决，ICE 直接成熟到可以对其他团队进行推广。在淘宝一般双十一、双十二大促完成之后，团队会进行规划和梳理并着手开发完善自己的运营平台，所以我们 ICE 小组摇身一变成了“地推小分队”，带着我做的教学分享 PPT 和 Demo 开始联系各个淘宝后端团队的 TL 约时间分享推广 ICE，让他们在新一年的平台建设开始使用 ICE，再次有种内部创业的感觉。

如何理解业务

今年也开始关注业务，思考业务。业务能力应该是程序员除了技术之外，最具价值的能力，也是最必要的。因为技术本身很难赚钱，业务落地才能赚钱。当程序员具备了业务和产品能力，才可能选取业务和技术的折中点，又快又好的支撑业务，带来价值和效益。懂产品和业务（甚至交互设计）的技术，更容易跟其他工种进行沟通，用通俗易懂的方式介绍技术实现和难度，可以提升在企业中的自身地位和价值。此外，对于架构师，理解业务也是必备能力。

2016 年 12 月的有一天晚上参加了 HR 组织的一个业务能力培训的会议，分享人是展炎和我的老板元彦，他们都是带领偏业务的团队，所以对业务的分析理解能力也很强。虽然之前也一直关心业务，但总感觉似懂非懂、晕头转向。正是这天晚上的展炎的分享《如何了解业务&产品》，给了我一条分析业务的通用方法论，从此再也没有似懂非懂的感觉。

分析业务最核心的方法和关键点，就是梳理出这条业务的整体链路，并查看是否可以形成闭环。 一个完整的链路闭环包括：业务目标、业务思路、产品方案、跟踪和调整。 简单的说，一个业务靠不靠谱，先要看业务目标是否契合大目标或者有用户需求，其次还要有业务开展的思路，之后产品针对这种思路的具体产品方案，最后就是业务落地、跟踪结果并分析，再来看是否需要调整或者放弃。在这个闭环中最好可以自己产生价值（钱）自己消费持续升级。下面举个具体的例子：

问题：为什么淘宝要大力发展内容业务？内容业务是否是一个可以持续发展的核心业务？

分析：首先从大的闭环来看，阿里巴巴集团的核心目标是让天下没有难做的生意（口号），淘宝在这个闭环中是链接中小卖家和买家的桥梁。所以在淘宝业务中，成交量就是核心指标之一，因为成交量越高越接近生意不难做的目标。 提高成交量有很多途径，对外挂广告（阿里妈妈、优酷、微博）、提高淘宝搜索准确度、相关商品算法推荐、搞活动大促都是一些沿用很多年的方法，但是这些途径用户购物目的明确，快进快出，基于这些方式很难再压榨更多成交。但是内容、视频、直播这种新的内容形态正好弥补了这个领域，这些内容形态不同于商品，好的内容可能吸引用户使用淘宝，用户使用时间增长就意味着有更多商品信息暴露给用户，提升购物的可能性。此外文章、视频、直播等更能让消费者熟悉了解商品，提高转换率，甚至可以凭空为用户创造需求产生购物行为。

所以淘宝内容业务在整个阿里巴巴业务大环中是站得住脚的，也可以推导出淘宝内容业务的核心业务目标是：用高质量的内容吸引用户观看从而提升手淘的用户使用时间，同时通过内容推荐和算法推荐促进成交。从内容业务的小闭环来看，首先在大闭环中站得住脚，之后内容需要创作者创作，创作的导购内容被消费者观看并产生购物行为，创作者可以获得佣金收入，同时平台可以分成创收用来新的发展。整个链路可以形成一个闭环，那么这个业务就是靠谱的。

程序员知道这个之后有什么用的？知道之后你就可以跟产品经理撕逼了，同时也可以安排需求的优先级。我关注产品规划会，也把对接的产品经理的 KPI 要来，当他们提出非常偏离主线目标的需求就可以直接反问这个需求对业务目标有什么帮助来拒掉或者改掉这个需求。

在知乎这个《前端工程师的技术进阶点在哪里?》问题中我也提到了一个具体的 Case：产品的需求是在内容发布页面加入内容质量分的提示，希望当用户编辑内容上传图片或者视频后，可以瞬间按照运营的质量衡量标准（比如图片有牛皮癣扣分）计算得分并显示出来，并且发布时如不满足最低得分，强制弹出提示希望用户优化后发布，产品目标是借此提升内容质量。

这个需求在我看来是有问题的。站在闭环角度来看，提升内容质量的关键是创作者的能力和创作意愿，吸引创作者花大精力创作根本原因是付出得到的收益而不是平台对内容质量要求的规则限制。从整个业务链路来看，应该在运营端突出宣传 优质内容 = 高流量分配和高收益，在内容分发端，增强优质内容判断和流量投放，增强内容收益的确定性（即高质量 = 高收益）。当创作者发现这个规则后，为了高收益自然会专注创作高质量内容而非批量创建大量垃圾内容以量来提升命中率和转换率。强制在发布端以一个固定标准限制用户发布，可以预见会有两个结果：创作者内容发布效率变低，创作成本变高，创作量减少；创作者摸透固定限制规则，通过技巧绕过来恢复自己原有的发布频率，按照以前的模式通过量增加算法命中率进而提升内容商品曝光带来收益。

从技术上来看这个需求，实现也是不现实的，首先计算内容需要后端接口，对图片和视频的运算延迟可能达到几十秒，根本无法实现“秒变”，这样创作者可能看到一个错误的得分，这个 Loading 的交互根本无法设计（开过 4、5 次会议讨论）。再加上算法可能会有误识别的可能，如果因为一个误识别的逻辑导致创作的内容无法发布可能会让创作者有受挫的感觉。所以结合两点我给出的建议是：首先补齐链路其他节点的业务需求并跟进。对于内容质量分这个功能，第一阶段作为辅助性功能，突出功能入口并进行运营宣导，但不会作为强制阻塞。这样如果注重内容质量的用户，自然会点击按钮使用这个功能检测来提升内容质量。同时我们也可以借此获取数据来分析算法准确性和实际内容质量提升效果。这个过程也是培养用户心智的过程，如果效果好第二阶段全部强制开启，也不会给用户很大的“惊喜”。从技术和交互层面，也将复杂度从不可行，降到了点击发送 AJAX 给后端接口，拿到结果弹个浮层展示一下的极低实现成本。由于用户主动触发功能，心智上就接受了可能产生等待时间，所以运算的延迟问题也被淡化。所以最后需求和交互就修改成这种模式。

如果你说太复杂做不了让别人改需求和交互，别人肯定不乐意去做。但从业务链路上做了分析，再从交互和技术实现上给出合适的方案，就更容易说服别人来做调整。同时对自己的工作来说，也降低了工作量和技术复杂度，实现快速上线、看结果快调整的小步快跑节奏。

站在链路角度思考不仅仅适用于业务分析

举一反三，不在单点而在链路上看问题，抓住本质，同样可以解决大量其他问题。

比如之前 Angular、Vue、React 框架拥护者之间争吵优劣和选择的问题，其实站在前端开发这个大环来看根本不是一个问题。前端的目标和本质就是优化用户体验，又快又好的满足偏界面和交互的业务需求。从这个角度来看，对于某些业务特点（例如注重 SEO 和维护成本的企业、店铺介绍网站），jQuery 反而是最快、最佳的框架。相互攻击或者强行为了追赶技术而使用新技术都是走偏了，应该抓住核心点：快速响应业务需求和创造业务价值。除了技术调研项目之外，选择某项技术应该问自己是否熟悉这项技术，这个框架或库是否更适合这种业务模式和团队成员现状，长期维护成本是什么样。而不是因为这个东西很火，或者看到大佬推荐或者批评。当时写了一片文章 《Angular、Vue、React 和前端的未来
》 有兴趣的同学可以看看。

这种方式也很适用于推导未来发展。比如在这篇回答中 《前端未来几年的发展方向是什么？》 也是基于这种链路角度推导出前端未来可能的趋势和需要继续完善的事情。有兴趣的同学可以看看，这里不再赘述。

第二年总结

2016 年 4 月到 2017 年 4 月这一年是写代码做工作最多的一年，尤其是上半个财年，做了很多需求，锻炼了时间管理和项目管理能力，同时开始对业务理解更深刻了，具备了初步的业务分析能力。在 ICE 团队中负责业务组件、培训等工作，站在前线接受用户的反馈，参与设计了很多方案写了很多组件，比较复杂的是富文本组件（基于 draft-js 封装），后期又重构了动态表单组件，对表单和富文本相关业务可以说是非常了解了。得益于这段时间的经验，我陆续回答了如下问题：

• 前端在开发表单相关业务时有哪些麻烦的需求？

• 为什么钉钉和微信发送表情用[]标签而不是直接发图片？

• 现在有个项目表单很多，用什么技术框架合适？

• 贴吧、知乎的的文本编辑器是怎样做到锁定富文本的样式的？

虽然业务结果上看起来并不是特别成功，但 ICE 发展算是不错的，本身也做了比较核心的贡献，所以今年也拿到了很好的绩效，同时在 2017 年 7 月也晋升了 P6。由于 ICE 团队成员艰苦奋斗，ICE 团队最终也获得了淘宝技术部优秀团队（只有两个名额），并拿到了奖金。时任 ICE 的 PM 也直接顺利一年从 P6 晋升 P7。

这个时期也开始思考个人未来要做什么，借助贝索斯的思路，不问未来会变成什么样，而是问什么东西一直没变。想了想人类对知识获取和演进一直没有停止，如果做个应用，用脑图的形式让人去梳理某个领域的知识，再通过内容关联成一张大网，当一个人想要学习新知识时，可以迅速通过知识图谱来找到自己想要学的知识，提升了获取知识的效率，岂不是很好。所以注册了 ohmyknowledge.com 域名，并且学习了下 SVG 看看怎么搞个脑图。

但后来发现互联网之父 Tim Berners-Lee 早在 1998 年就开始试图建设 Semantic Web（语义网）来解决这个问题。在这个网上，互联网就是所谓的脑图链接，相关的概念、标准早都有了，比我所谓的想法高的不能再高了，于是就作罢了。真是你的一个想法，别人不只是想到，很可能都做过而且失败下线了。所以创业时要注意看看之前有没有人做过类似事情（大概率有），跟自己的有什么区别，成功还是失败了，为什么失败了。

这一年身体也明显感觉有点差了，后期再也没法坚持工作到两点，时常半夜三点肚子疼起来坐马桶上站不起来，只能靠喝蒙脱石才能站起来（所以我背包随时备有蒙脱石）。最初还以为是肠胃问题，后来公司组织的例行体检说我前段时间可能得过急性肝炎，居然硬扛过去了。体重也一直在上涨，16 年体检的轻度脂肪肝也升级为中度脂肪肝，如果再继续严重就是重度和肝硬化，之后再无法恢复。在 17 年 10 月租的房子到期之后就搬了住处，正好附近有健身房就办了卡买了私教课，我开始试图通过锻炼来恢复健康。由于需要开车上下班，所以我也尽可能减少加班时间。

除此之外，由于未来会有移民的可能，有时项目间隙不算忙的时候，也会早起抽早上的时间刷多邻国和英语流利说之类的希望可以练练英语。Commit messages 也一直是用英文（Chinglish）写的。

最后，为你推荐