blog
blog copied to clipboard
lcxfs1991
leehey's blog -- 请star或者watch
> 李成熙，Shopee Airpay 前端 Leader。2014年毕业加入腾讯AlloyTeam，先后负责过QQ群、花样直播、腾讯文档等项目。后于2018年加入腾讯云云开发团队。专注于性能优化、工程化和小程序服务。[微博](https://weibo.com/leehkfs/) | [知乎](https://www.zhihu.com/people/leehey/) | [Github](https://github.com/lcxfs1991) 到了新公司之后，发现居然也是用企业微信。但可惜的是，外部的企业微信居然没有机器人。这对以前在鹅厂里习惯用企业微信做提醒的我觉得很不方便。终于，7月一开始企业微信终于上线机器人功能。 右击群聊天卡片，可以添加群机器人。  悬浮在机器人的头像上，会显示出 Webhook 地址。点击这个地址，会跳到机器人的开发文档。  提醒机器人的开发其实很简单，其实就是向这个webhook地址，按文档提供的格式发送请求，就可以实现消息推送了。最简单的示例，可以用 `Node.js` 的 `axios` 类库： ``` const axios = require('axios') async function bookLunch() {...
一毕业，我就进入鹅厂。在鹅厂经历了最顶峰的日子，也见证了鹅厂发展变慢，寻求变革。在这里有很多光环，大厂，技术牛，工资好。在外面参加各种场合的活动，作为小兵的我也时常被人捧上天。工作第3年的时候，我就开始陷入沉思。究竟这些光环，这些牛B，是鹅厂带给我的，还是我自己实实在在挣来的呢？如果我哪天离开了这里，没有这个大厂的光环，我的技术还能那么牛吗？我推动的事情还能这么顺利吗？招人还那么容易吗？ 我是危机感比较强的人，希望可以挑战一下自己，跟随着一个快速发展的团队，不断打磨自己作为一个软件研发人员的工程能力和生存能力。正好19年5月份碰巧拿到一家腾讯系公司 Shopee 的 offer，有机会可以带团队。Shopee的规模没有鹅厂这么大，虽然全球也有几千人，但在深圳刚加入的时候只有几百人，但发展很迅猛，机会和挑战并存。总括来说，Shopee就是规模相对较小，但发展相当迅猛的公司，非常适合现阶段的自己，于是便希望去尝试挑战一下。 ## 等别人喂还是喂别人？ 在大厂里，一切的流程，工具，系统，都已经有前人搭建好，你只需要做一口听话的螺丝钉，安心执行，等被人喂即可。但在小一点的平台，各方面都未完善，并没有人告诉你该怎么做，需要自己一步一个脚印把路给踩出来。 记得刚到 Shopee 的时候，需要将业务发布到CDN上。但当时一问之下，由于金融业务需要有特殊的合规要求，一直没有将业务发布到已有的CDN服务供应商上，而只能将业务发布到公司自己搭建的IDC上，成本比较高。在这个问题上，似乎并没有人可以帮到我，我只有选择作为喂别人的人，将这整个合规的流程给打通。**搜索资料，拿出理据，说服老板**，这三步很重要。 首先要搜索到市面上主要的CDN厂商的功能、性能以及合规的信息，然后在公司内网，想尽办法了解公司当前以及未来规划的架构策略，无意中发意其中一家符合要求的服务商，有一些海外的业务在试用了，我便把这些信息进行汇总后，誊写一份邮件，争取到老板的支持，把整个流程打通，为后续业务的顺利上线和更多业务接入降低成本铺好路。其实上面提到的这三步，在大公司里也适用，我们开展一个项目，达成一个目标，也需要拿出说服人的理据，来说服老板和同侪的支持。但由于大公司一切都很完善，很容易会养成惯性，自己翘起双手，什么也不管，虽然会慢点，但最后也会有人解决好前面的路障，让你可以坐享其成。但小平台不一样，可能有生存的压力，有盈利的压力，有发布新产品的压力，这个问题不解决，你们团队就可能面临丢饭碗的困境，因此选择喂饱你的战友，你的项目，养成这种意识，才能在不同环境之下都可以生存。 ## 如果合作能解决的问题不要自己单打独斗* 大平台经得起内部赛马，但小平台经不起过多的折腾。以前在鹅厂经常听老板说ROI，也就是所谓的投入产出比。但你会看到其实一起合力更实力，但旧东家还是很喜欢搞赛马——外部投了虎牙和斗鱼，内部一样还有企鹅电竞和NOW直播。大厂钱多人多，经得起消耗，但小一点的平台则不然，合力往往是解决问题的最好方式。 开发几个月后，业务就即将上线了，但对业务的监控还是没有很好的方案。这是每一个项目的技术带头人，都需要的决策，是自己搭一个，还是用别人的？经过询问之后，部门内部是有一套已经在用的Sentry，当时就答应下来，要马上接入。还有一套简单的性能上报平台，但功能还不是太完善，并且正在规划下一个版本的设计，接口可能完全不兼容，看起来不太符合当时的接入条件。在做产品上报的时候，我发现公司的数据平台，其实可以一定程度上充当这个上报的角色，经过简单的开发支持后，不仅可以将性能数据上报，经过打探，还可以做一些实时数据上报的事情。 于是我便决定下来，将我的需求整理成文档，然后花了两三周的时候，耐心地解释这个事情对业务的重要性（能让业务通过不断优化，提升性能，给用户更好地体验；有实时监控PV也可以大体监测业务是否掉量），以及对于数据平台的价值（除了上报产品数据外，还可以兼顾技术的数据，减少内部竞争者）。最终通过**寻找共赢点**，成功游说到数据平台对我们进行支持。这次的合作，看起来我只是一个推动者，但整个合作是由我发起，流程由我推动打通，看似是数据平台的能力在喂我，但其实是我跟数据平台打通了流程和开拓了能力和服务场景后，一起去喂其他的业务，也是对上一节讲解的呼应。 ## 能力一专多长更适应业务的快速多元发展 大平台钱多人多，最喜欢就是某一个领域专精的工程师，所以对某一方面非常专业，即可在大公司混上口饭上。但这样会导致知识面较窄，丧失广泛深习的能力。万一自己熟悉的技术落伍了，公司业绩不好，很容易被淘汰。比如目前鹅厂有些部门，前端再进行细分，就是将HTML和CSS单独列为重构。这样确实可以让重构的工程师专注于做体验，他们往往比同时写JS，HTML和CSS写的页面效果更好更精细。 但对于发展迅猛的业务来说，花60%的精力做到80分，可能比花90%的精力做到90分更符合ROI。并且业务多元快速发展，但人手不够，技术储备不够，便可能要求员工在切换业务的时候，也需要快速适应另一个技术栈，因此**一专多长**在小一点的平台里，显得难能可贵。可能并不是所有小厂都是这样要求的，但我对组内的兄弟的培养，都是这样的要求。譬如你可能写 React Native 是大神中的大神，但 React Native 需要挥快速更新的优势和分包，就需要研发一个热更新的服务，那对Node.js也需要有一些的了解，才可以研发出热更新的服务，而研发热更新的服务，就需要了解CDN技术，K8S技术，才可以将Node.js服务部署好，将React Native的Bundle存放好。在大厂里，这个流程每一小块都可以由一个人自己承担，但在我的项目组，只是由2个兄弟独力承担。他们虽然辛苦，但成长的速度远远要比在大厂快，并且由于将自己培养成一专多长的人才，经过一段时间的磨练，相信每个人都能初步具备当技术leader所需要的技术深度和广度。 ## 小结...
[原文链接](https://github.com/lcxfs1991/blog/issues/36) > 李成熙，腾讯文档前端Leader，负责DOC业务前端研发。2014年度毕业加入腾讯AlloyTeam，先后负责过QQ群、花样直播、腾讯文档等项目。2018年加入腾讯云云开发团队。2019年加入Shopee金融前端团队任一线前端Leader。专注于性能优化、工程化和小程序服务。[微博](https://weibo.com/leehkfs/) | [知乎](https://www.zhihu.com/people/leehey/) | [Github](https://github.com/lcxfs1991) 这是一篇由内部分享转成的文章。因为最近有一些新的感悟，因此加入了一些新的内容。为什么还是想将一次分享铸成这篇文章呢？因为在日常工作中，还是能感受到很多同事一心只扑在技术上，对业务、对产品的关注过少，更有甚者是不想做业务需求，只求做艰涩的技术需求。 这并不是一个技术人正确的产品观。错误的产品观，会让技术人在技术上只求深入，不问业务，业务与技术的脱轨会让钻研的技术前功尽弃，也会让业务发展停滞。在商业公司里面从事技术，离不开商业世界基本的运行逻辑：收入 - 成本 = 利润。技术人就是要做功能将收入做得多多的，成本降得低低的，获得利润。当然你可以选择自己干，像两位马爸爸一样当创始人；或者做开源，像Vue、Redis、Nnginx 等开源应用的作者那样既做开源又做商业。只有通过技术手段获得利润，并且利润可持续，我们作为技术人的职业生涯才是可持续的。君不见，Webpack的作者由于拿不到足够的赞助又去上班了。连自己都养不活，更不要说烧些钱去探索星辰大海了。 那怎么样才是技术人良好的产品观，以及可以怎么树立呢？接下来我从四个常见的反面的思维为阐述。 ## 产品的数据是多少，我不知道  在日常闲聊中，还是有很多同事对自己的产品数据不甚清楚，尤其许多前端的同事。可能后台经常要为机器发愁，生怕服务撑不起用户的并发，所以会经常问产品相关的产品数据。但前端的同事总觉得将页面切完接口调完就完事儿了。许多新的前端同事可能没想到，其实我们的HTML页面、其它静态资源部署，都是要考虑流量问题。一旦用户量很大，还需要要求云服务商给我们的服务、静态资源扩容。 下面列举了一些技术人最关注的数据。这些数据跟我们日常工作都是最息息相关的。有经验的技术人一般都会有所了解，新同事可能并不熟悉，本文只是做一个全面的列举，有兴趣可以专门学习，每一种类都有比较深的学问。 | 英语名称 | 作用 | 平台 | | ----...
## 前言 最近由于用着html-webpack-plugin觉得很不爽，于是乎想自己动手写一个插件。原以为像gulp插件一样半天上手一天写完，但令人郁闷的是完全找不到相关的文章。一进官方文档却是被吓傻了。首先是进入[how to write a plugin](https://webpack.github.io/docs/how-to-write-a-plugin.html)看了一页简单的介绍。然后教程会告诉你，你需要去了解compiler和compilation这两个对象，才能更好地写webpack的插件，然后作者给了github的链接给你，让你去看源代码，我晕。不过幸好最后给了一个[plugins](https://webpack.github.io/docs/plugins.html#the-compiler-instance)的API文档，才让我开发的过程中稍微有点头绪。 how to write a plugin这个教程还是可以好好看看的，尤其是那个simple example，它会教你在compilation的emit事件或之前，将你需要生成的文件放到webpack的compilation.assets里，这样就可以借助webpack的力量帮你生成文件，而不需要自己手动去写fs.writeFileSync。 主要就是这段代码 ``` compilation.assets['filelist.md'] = { source: function() { return filelist; }, size: function() { return filelist.length; }...
# 如何通过 Github Action 薅腾讯云云开发的羊毛 印记中文一直致力于为国内前端开发者提供技术文档的翻译服务，比如 React, Webpack, Node.js 等技术文档，都能有看到印记中文参与的影子。为了让文档的加载速度更好，我们都把文档全数部署在腾讯云国内的 CDN 服务上。不过这也带来了比较大的成本压力，做部署服务买的机器、每几个月要买 TB 级别的 CDN 流量包。 直到最近，腾讯云云开发推出的静态资源部署服务，对于许多文档站、静态个人官网，无论是在部署上，还是价格上，都非常的友好亲民。经过计算发现，比将站点部署在云服务器以及传统的 CDN 更加实惠。这么好的羊毛，不薅天理难容啊！  不过由于印记中文的文档种类多，情况各不相同，经过一番的研究之后，梳理出以下的需求，并且输出了对应的解决方案，希望开放出来给大家针对自身的情况使用。 ## 印记中文的部署需求 - 需求一：文档个数多，希望可以统一发布方案 由于印记中文的文档不少，至少有 10 个以上，部署的方案需要比较整齐划一才比较好地做维护。之前我们是通过 `Node.js` 写了一个部署服务，一定程度上减轻了部署的负担，但还是需要在每个文档里，新加入脚本做构建和触发部署。而...
上次写总结文章，是来 Shopee 刚好半年后，那时刚刚适应从个人贡献者到技术架构师和管理者的身份转变，有一些感悟与心得，拿出来与大家分享。 又一年过去了，来 Shopee 已经一年半，团队从刚开始时的 4 个人，到现在 18 人，公司股价，也从当初的 20 美金，到 180 美金。很有幸，公司在进步，我也在进步。 今天主要想分享三个作为前端，可能经历的瓶颈，然后讲讲我为了突破这些瓶颈，所做的一些思考与努力。这三个突破，分别是 - 从个人贡献者到技术架构师与管理者转变的突破 - 从带领单项技术到带领多项技术的突破 - 从带技术到带业务的突破 ## 瓶颈一：从个人贡献者到技术架构师与管理者转变的突破 其实这个可以从架构能力与管理能力两个层面讲。咱们先来讲一下架构能力。 ### 架构师 所谓架构能力，简单地说就是将不同的模块、组件、系统组装起来，联动发挥作用，解决业务或技术需求的一个过程，网上可能有更详尽的解释，大家可以自行去了解。开发者在个人贡献者阶段，更多只是接受架构师指派的任务，完成自己一个小模块的设计与代码。而在架构师的阶段，要担负起的责任与工作则更多，而且既要兼顾全局，有时也要 Review 细节的落实，有时候是又当建筑设计师，又当工地监工。 作为架构师，首先要对需求的把握非常清晰，一个是需求要落实的功能点，另一个是要考虑一些特性，譬如性能，未来的扩展性等等。以最近我们计划要做的一个产品的官网为例，这个官网比较核心的特性，一个是发布新闻、一些推广活动还有常见问答，另一个是可以提供这些内容的相关搜索，还有对个别商家做一些排行榜。...
[原文链接](https://github.com/lcxfs1991/blog/issues/9) ## 前言 将babel捧作前端一个划时代的工具一定也不为过，它的出现让许多程序员幸福地用上了es6新语法。但你就这么放心地让babel跑在外网？反正我是不放心，我就曾经过被坑过，于是萌生了研究babel代码转换的想法。本文不是分析babel源码，仅仅是看看babel转换的最终产物。 es6在babel中又称为es2015。由于es2015语法众多，本文仅挑选了较为常用的一些语法点，而且主要是分析babel-preset-2015这个插件（react开发的时候，常在webpack中用到这个preset）。 ## babel-preset-2015 打开babel-preset2015插件一看，一共20个插件。熟悉es2015语法的同志一看，多多少少能从字面意思知道某个插件是用于哪种语法的转换 - babel-plugin-transform-es2015-template-literals => es2015模板 - babel-plugin-transform-es2015-literals - babel-plugin-transform-es2015-function-name => 函数name属性 - babel-plugin-transform-es2015-arrow-functions => 箭头函数 - babel-plugin-transform-es2015-block-scoped-functions => 函数块级作用域 - babel-plugin-transform-es2015-classes => class类...
[原文链接](https://github.com/lcxfs1991/blog/issues/31)  互联网的应用，大大小小，不同的场景，都离不开鉴权，从简单的可被用户感知的登录的鉴权，到技术侧不给感知的各种技术参数鉴权，都有着形形色色的鉴权方式和表现形式。其实本质上来讲，鉴权就是要证明你就是你，你可以做哪些事情。 所以鉴权分为两部分，一部分是鉴别身份，一部分是确定权力。而现代网络设计中，权力的分配一般都是预先分配好的，在鉴别身份之后，拿着身份信息，去权限中心确定权力范围，就完成了用户的鉴权过程。 ## 现实生活中的身份鉴权方法  身份证是现代社会用于鉴别身份的一种方式，说起身份证, 据相关史实考证,我国的身份证最早出现在战国时期,在商鞅在秦国变法,发明了照身帖。照身帖由官府发放,是一块打磨光滑细密的竹板, 上面刻有持有人的头像和籍贯信息。 国人必须持有, 如若没有就被认为是黑户, 或者间谍之类的。这可能是早期身份证的雏形, 在隋唐时期，我国出现了最早的“身份证”，当时的朝廷发给官员一种类似身份证的“鱼符”，他是用木头或者金属所作，形状像鱼，分左右两片，上有小孔，并可有官员姓名、任职衙门、官员品级等。那时，凡亲王、三品以上官员“鱼符”用黄金制作；五品以上用白银；六品以下为铜制。五品以上官员，还备有存放鱼符的专用袋子，称为“鱼袋”。 从秦朝到清朝的这个阶段, 出现的这些身份的标识, 形式多样性, 但总体来说,都是属于身份证明的这一范畴。然而,这样的身份证, 在核验其身份的真实性, 只能凭眼观, 造假很容易蒙混过关, 没有人 能真正的证明其真实性。 这种核验身份方法, 是最初级最原始的方法。 现代身份证雏形的阶段。 而身份证这种鉴权方式由如密码鉴权一样，属于一种固定密钥鉴权方式。密钥要不被私有不公开，要不很难伪造。  同样，在武侠小说中的令牌，也是如此。最近热播的倚天屠龙记，明教的圣火令，见之如见教主。而圣火令就是令牌的一种方式，使一种固定的密钥鉴权方式。 ##...
[原文链接](https://github.com/lcxfs1991/blog/issues/24)  最近几个月一直有些事情没有想通，但可幸的是，有些问题的答案逐渐开始明朗起来了。好久没写文章，籍此献上一篇短文。 当初准备毕业的时候，其实并没有想过要当前端工程师，毕竟当时基本都是全栈（PHP + jQuery）。但由于并不是科班出身（大学读Business），自信心不足，以及机缘巧合，就成为了一名前端工程师。 选择这份职业，其实也领略到它所拥有的魅力，更快捷的开发方式，更紧贴时代的发展，跨端的兼容等等，可以算是享受了前端这几年飞速发展的红利。但工作三年之后，也逐渐发现只是围绕前端来发展，有很大的局限性。 大约是有那么两件事触动到我吧。 **第一件事是**， React Native, Weex, Node.js 这事技术的发展，仿佛是给前端铺平了进入客户端和后台的道路。但真正开发过的人才知道，在这些技术里玩得溜的，其实还是从安卓、IOS转过来的客户端开发或者从JAVA, C++转过来的后台工程师。 **第二件事是**，如果未来，需要你带技术团队，只懂前端技术足够吗？其实是不够的，精通前端技术，然后懂点后台、客户端皮毛呢？我觉得也是不够的。就这样，能与后台和客户端达到更良好的技术沟通与理解吗？能在他们给出非最佳方案的时候提出自己的见解吗？万一部门的前端人力富余了，有能力带团队做后台吗？做些客户端的东西呢？能做，但能做得优秀吗？如果没有技术储备，我觉得上述的问题完全解决不了。  所以，未来一两年，希望自己能朝着**软件工程师**方向发展，而不仅仅是将自己局限为**前端工程师**。不过，一个人的精力真的有限，未必能把各方面的技术都学得很透彻。但我对自己的要求是，精通一门端技术和一门后台技术应该是比较好的搭配，这样整个产品的技术开发都基本能 Hold 得住。不过，具体怎么搭配，可能还是跟自己的职业发展和兴趣爱好有关，同时掌握端两门端技术、后台 + AI 技术、等等，我觉得这些搭配也不差。 技术能力拓宽之后，你未必能马上能管理团队、更好地掌握一些跨端技术，尽管如此，你在前端领域的一些想法，可能会有更不一样的转变。  比如说，如果公司内的团队，每个人都至少掌握一门端技术和一门后台技术，好多时候人力都可以动态调配，联调的时候也能减少。某个需求，如果后台人力太紧，导致联调时间滞后，之前前端团队最喜欢的做法是，我们来写个数据Mock平台，自己在上面写一些假数据，调完之后，后台好了，再跟后台调。但如果我本身就会这门技术，我直接把接口写好就行了，在接口传假数据，虽然可能还要跟后台的数据对接，但总体来说，实质上还是少了些Mock的功夫。  由于动态调配带来的好处除了节省开发时间，其实是更有利于技术部门组建 feature team。国内许多大公司主要都是将技术分得很细很细，每个组的成员，几乎就只会一门技术。如果一个部门里缺少了某种技术的组，或者尽管有但人力不足，要孵化的新项目需要这项技术，估计就因找不到合适的人才而难产了。...
> 李成熙，腾讯云高级工程师。2014年度毕业加入腾讯AlloyTeam，先后负责过QQ群、花样直播、腾讯文档等项目。2018年加入腾讯云云开发团队。专注于性能优化、工程化和小程序服务。[微博](https://weibo.com/leehkfs/) | [知乎](https://www.zhihu.com/people/leehey/) | [Github](https://github.com/lcxfs1991) ## 什么是小程序·云开发 小程序·云开发是微信团队和腾讯云团队共同研发的一套小程序基础能力，简言之就是：云能力将会成为小程序的基础能力。整套功能是基于腾讯云全新推出的[云开发(Tencent Cloud Base)](https://cloud.tencent.com/product/tcb)所研发出来的一套完备的小程序后台开发方案。 小程序·云开发为开发者提供完整的云端流程，简化后端开发和运维概念，无需搭建服务器，使用平台提供的 API 进行核心业务开发，即可实现快速上线和迭代。 该解决方案目前提供三大基础能力支持： * 存储：在小程序前端直接上传/下载云端文件，在小程序云控制台可视化管理 * 数据库：一个既可在小程序前端操作，也能在云函数中读写的文档型数据库 * 云函数：在云端运行的代码，微信私有协议天然鉴权，开发者只需编写业务逻辑代码 未来，我们还会集成更多的服务能力，为小程序提供更强有力的云端支持。 ## 如何使用小程序·云开发  上面就是小程序·云开发简单的使用图谱：在小程序端，直接用官方提供的接口，在云函数端，直接用官方提供的 Node SDK，就可以操作你云的资源。以前开发小程序所担忧的数据库搭建、文件系统部署，通通没有。 你只需要有在小程序开发 `IDE`...