blog
blog copied to clipboard
lcxfs1991
leehey's blog -- 请star或者watch
> 李成熙，腾讯云高级工程师。2014年度毕业加入腾讯AlloyTeam，先后负责过QQ群、花样直播、腾讯文档等项目。2018年加入腾讯云云开发团队。专注于性能优化、工程化和小程序服务。[微博](https://weibo.com/leehkfs/) | [知乎](https://www.zhihu.com/people/leehey/) | [Github](https://github.com/lcxfs1991)   小程序诞生以来，业界关注小程序前端的技术演进较多，因此众多小程序前端的框架、工具也应运而生，前端开发效率大大提高，而后台的开发技术则关注不多，痛点不少，具体痛在哪里呢？ ## 小程序后台开发之痛  第一个是脑袋瓜疼，怎么疼呢？  随着像腾讯云等的云服务商提供的云服务越来越便捷，业务上云已经是大势所趋。但是从简单地在云虚拟机上部署页面，到实现真正全面地上云，还是有很多区别。要真正实现全面的上云，要了解的东西非常多，当你第一次接触这些概念的时候，学的这些东西是一个接一个，让你应接不暇，往往分散了你的对业务的专注力。比如我自己，来腾讯云之后，为了对云服务有更好地了解，就去报了个腾讯云的课程。这课程系列分云架构师、云开发、云运维三门课程，还分初级、中级、高级，需要花费大量时间才能理清这些知识概念，并且还要花大量的时间去上机做实验。所以对于开发来说，要彻底搞清楚，还真的不是件容易事，绝对让你的脑袋疼。 第二是肉疼，尤其是你老板肉疼。  最开始当互联网还没有云服务商的时候，公司都得自己搭服务，不仅花大价钱买机器、买宽带流量，还得请人过来维护。如果在这种情况下要搞小程序开发，公司得请一个维护服务器硬件的、一个维护网络的，一个数据工程师，一个后台还有一个前端，刚好五个人。当云服务商开始进入变革整个市场的时候，我们就不用再自己维护硬件了，由云服务商来维护，因此我们可以少请一个维护硬件的，但还是得有一个运维去维护云服务。当云服务商将数据库、容器服务都抽象出来上云之后，咱们连专业的数据库维护都可以不请了，由后台或者云维兼岗就行。云服务商的不断发展，确实是让云服务的成本不断下降，但投入的钱还是很多呀，要投入的人还是不少，这几年生意难做，作为老板肯定是想投入成本、试错成本越少越好。 第三个是肾疼。  大家都知道，开发是一个走肾的工作。比如，这些年流行的前后端分离，虽然让专人专项，但却引入了联调这个事，所以也增加了肾的负担。  这里列出了三个前后端分离带来的麻烦。 1. 权责往往不清晰，有很多临界的位置，谁管都可以，容易引发扯皮。 2. 沟通时间增多，因为毕竟是两个人工作嘛，需要不少的沟通 3. 除了沟通，还需要两边的代码调试，看看数据、展示通不通，这个时间也很不可控，尤其是如果环境特别复杂，调起来不仅麻烦重重，还很有挫败感。 ##...
> 李成熙，腾讯云高级工程师。2014年度毕业加入腾讯AlloyTeam，先后负责过QQ群、花样直播、腾讯文档等项目。2018年加入腾讯云云开发团队。专注于性能优化、工程化和小程序服务。[微博](https://weibo.com/leehkfs/) | [知乎](https://www.zhihu.com/people/leehey/) | [Github](https://github.com/lcxfs1991) ## 概念回顾 在掘金开发者大会上，在推荐实践那里，我有提到一种云函数的用法，我们可以将相同的一些操作，比如用户管理、支付逻辑，按照业务的相似性，归类到一个云函数里，这样比较方便管理、排查问题以及逻辑的共享。甚至如果你的小程序的后台逻辑不复杂，请求量不是特别大，完全可以在云函数里面做一个单一的微服务，根据路由来处理任务。 用下面三幅图可以概括，我们来回顾一下：  比如这里就是传统的云函数用法，一个云函数处理一个任务，高度解耦。  第二幅架构图就是尝试将请求归类，一个云函数处理某一类的请求，比如有专门负责处理用户的，或者专门处理支付的云函数。  最后一幅图显示这里只有一个云函数，云函数里有一个分派任务的路由管理，将不同的任务分配给不同的本地函数处理。 ## `tcb-router` 介绍及用法 为了方便大家试用，咱们腾讯云 Tencent Cloud Base 团队开发了 [tcb-router](https://github.com/TencentCloudBase/tcb-router)，云函数路由管理库方便大家使用。 那具体怎么使用 `tcb-router` 去实现上面提到的架构呢？下面我会逐一举例子。 **架构一**：一个云函数处理一个任务 这种架构下，其实不需要用到...
[原文地址](https://github.com/lcxfs1991/blog/issues/10) [本文starter kit: steamer-react](https://github.com/SteamerTeam/steamer-react) ## 为什么做直出 就是为了“性能”！！！ 按照经验来说，直出，能够减少20% - 50%不等的首屏时间，因此尽管增加一定维护成本，前端们还是前赴后继地在搞直出。 除此之外，有些特定的业务做直出能够弥补前后端分离带来的SEO问题。像这次选取的腾讯新闻，大多数页面首屏其实都是直出的（但肯定不是React直出）。 ## 性能指标 刚提到的首屏时间，只是单纯内容的渲染，另外还有首屏可交互时间，即除了内容渲染之余，还能够让用户能够对首屏的内容进行交互，如点击、滚动等等。现在市面上有关React的性能报告，尤其是那些截了Chrome渲染映像的，都归到首屏时间。 ## 为什么选择腾讯新闻 - 我并非腾讯新闻的业务相关方，可以比较大胆地作为例子使用 - 腾讯新闻页面更为丰富，可以做更多场景的实践 - 验证全套脱胎手Q家校群react的优化策略、实践方案和开发工具 由于只是实验，数据都是拉取腾讯新闻现网提供的，而样式简单地仿照了一下，做得略粗糙，请见谅。 ## 参考的资料和使用的工具 做这次实践阅读了不少文章，文章提到过的内容我这里就不再赘述了，后文主要是做补充。 这次同构直出实践，我们使用的是脱胎于手Q家校群的react start kit，名曰[steamer-react](https://github.com/SteamerTeam/steamer-react)。目前可以试用。它有2个分支，一个是react分支，目前只是提供纯前端的boilerplate。另一个是react-isomorphic，同时包括前端和后台的boilerplate。有什么问题可以给我提issue。 文章：...
[原文地址](https://github.com/lcxfs1991/blog/issues/27) 2018年暑假，有幸参加了首次腾讯 SNG MINI 项目 的改版试验——导师制 + 定向命题。MINI 项目是在短时间内通过组队、设计并独立完成一个完整产品的培训项目，我觉得除了能通过实习生的实践来验证最近做的技术项目之外，还深感这还是一次独立带队的好机会，于是欣然答应。 ## 出题与组队 以往的 MINI 项目都是由新人们自主想题目，这次是由各位导师预先根据自身任务或者项目，让新人来选择。虽然这次参与，有业务压力在身，但考虑到MINI项目本身的性质，以及希望童鞋都是带着兴趣来的，因此还是花了不少心血认真选材出题。 对所选组的要求是使用最近即将推出的与小程序相关的技术，并可以做出一个准上线级别的小程序。除了这点限制，可以在产品方向上做些发挥。 为了更好地完成任务，必须吸引优秀的人才。吸引人才无非三方面：**钱、理想、兴趣**。MINI项目不谈钱也不谈理想，兴趣便是首要吸引人才的关键。因此产品上，我初步设计了 toB 和 toC 的业务，涵盖两至三个方向的产品。除了可以从不同产品形态检阅腾讯云的技术，也能多给童鞋选择，招揽更多人才。 下图是我制定的两个产品方向，一个是比较实用的家庭相册，一个是紧追热点的偶像粉丝小程序。 待所有导师的产品方案都出来之后，发现其他导师大部份的出题是 toB 的或者是技术类项目，我初步估计可能由于我的选题较丰富，能吸引不少人才。 MINI 项目启动会当天，几大选题讲完之后，报名参加我这边命题的人数远超我的预期。一堆人将我团团围住。可能由于出乎意料以及缺乏经验，在选人的环节处理得不太好。我采用了逐个微信加的办法，然后按顺序筛选，这导致后面分组有些混乱。  后来回顾经负责项目的HR提点，应该让所有人通过微信面对面建群，并给出理想的岗位人数搭配，然后组长组好队伍之后再次申请加入我的战队。 虽然组队方式有些不足，但凭借选题的优势，基本垄断了最优秀的产品、设计、前后台工程师，还意外收获一枚算法特厉害的小鲜肉。 ##...
看到腾讯云提供了这么多 AI 图像服务，跃跃欲试！  结果发现，只有 Java, Python, C++ 几款 SDK。 为了前端工程师的福祉，撸了一款 Node 的 SDK，如下： [image-node-sdk](https://github.com/tencentyun/image-node-sdk) 一共支持6大类（信息认证、人脸识别、文字识别、图片识别、人脸核身和人脸融合），35个接口，有些接口是提供了大量免费调用的机会，而有些可会要收费。 共提供两种调用方式。 1. 外链  2. 读取本地文件  ***欢迎试用以及给我提Issue或PR!***
### 本周内完成 有兴趣的童鞋可先参考 [steamer-kit-library](https://github.com/steamerjs/steamer-kit-library)
[原文地址](https://github.com/lcxfs1991/blog/issues/8) [本文start kit: steamer-react](https://github.com/SteamerTeam/steamer-react/tree/react) PS: 要看效果得将一个QQ群组转换成家校群，可到此网址进行转换（手Q/PC都可以访问）： [http://qun.qq.com/homework/](http://qun.qq.com/homework/)。转换之后，可以通过QQ群的加号面板，或者群资料卡进入。 最近一个季度，我们都在为手Q家校群做重构优化，将原有那套问题不断的框架换掉。经过一些斟酌，决定使用react 进行重构。选择react，其实也主要是因为它具有下面的三大特性。 ## React的特性 ### 1. Learn once, write anywhere 学习React的好处就是，学了一遍之后，能够写web, node直出，以及native，能够适应各种纷繁复杂的业务。需要轻量快捷的，直接可以用Reactjs；需要提升首屏时间的，可以结合React Server Render；需要更好的性能的，可以上React Native。 但是，这其实暗示学习的曲线非常陡峭。单单是Webpack+ React + Redux就已够一个入门者够呛，更何况还要兼顾直出和手机客户端。不是一般人能hold住所有端。 ### 2. Virtual Dom...
[Shared from](https://github.com/lcxfs1991/blog/issues/15) # Introduction For beginners, webpack building performance is sometimes annoying. However, this will not stop webpack from becoming the best web building tool in the world. Once you...
经过一个多月的奋战，[webpack2的中文文档](https://doc.webpack-china.org/)已经翻译好大部份，并且完成了核心内容“概念”和“指南”部份的校对。 这份文档比react, vue之类的文档都要庞大而且复杂。本文带你如何快速读懂这份文档。 首先是[“概念”](https://doc.webpack-china.org/concepts/)。这部份对于菜鸟或者老司机来说，都是值得一读的，由于webpack跟之前的grunt, gulp都有所不同，它是基于模块的配置型构建工具，许多理念对于前端玩家来说都是全新的，例如，什么是[入口(entry)](https://doc.webpack-china.org/concepts/entry-points/)，它有几种配置的方式，如何配置我们需要[输出(output)](https://doc.webpack-china.org/concepts/output/)的位置、文件名，[加载器(loaders)](https://doc.webpack-china.org/concepts/loaders/)，和[插件(plugins)](https://doc.webpack-china.org/concepts/plugins/)是如何帮助我们编译文件和处理各种自动化任务的，webpack要打包的[模块(module)](https://doc.webpack-china.org/concepts/modules/)到底是什么，它去哪里[解析(resolve)](https://doc.webpack-china.org/concepts/module-resolution/)文件等等，这里都会帮你一一解答。 在你了解了webpack的概念之后，接下来，可以看看[“指南”](https://doc.webpack-china.org/guides/)。这里的内容都是实践经验之谈，例如前四篇文章主要是介绍怎么用webpack去初始化一个项目，并进行发布；《从v1迁移到v2》帮助你顺利从webpack1升级至webpack2。其它的文档，主要是介绍webpack一些比较精彩的特性，例如拆包、热替换等等，还有一些比较有趣的，像怎么用typescript写webpack配置，怎么用虚拟机跑webpack等等。 如果你对前两部份都了如指掌，那么恭喜你，你已经具备能力进入webpack的深水区了--更为细致的["文档"](https://doc.webpack-china.org/configuration/)了。 点击”文档“，首先进入的是["配置"](https://doc.webpack-china.org/configuration/)，这里算是完整配置的介绍，要搭建一个更为完善的脚手架或者构建工具，需要仔细阅读这里的配置文档。 [“API”](https://doc.webpack-china.org/api/)主要介绍了像webpack命令行的使用、如何在Node.js中结合webpack来搭建构建工具。对比起webpack1，webpack2的命令行工具变得更为强大，而且可以对你的构建耗时进行分析。 API中另外的两部份，[“加载器API”](https://doc.webpack-china.org/api/loaders/)和[“插件API”](https://doc.webpack-china.org/api/plugins/)，可以结合[“开发”](https://doc.webpack-china.org/development/)部份来看，主要是帮助开发者更好地开发webpack的加载器和插件，借助webpack的能力去解决自身项目中遇到的构建问题。对比webpack1，这是一份更好的加载器和插件开发文档，因为它不仅介绍了推荐的写法，还把内部的事件、内部可调用的一些方法，都展现了出来，赋予了开发者更多的能力。 webpack2的文档，耗费了许多人大量的心血，尤其要感谢最开始启动这个翻译项目的[dear-lizhihua](https://github.com/dear-lizhihua) 还有 [dingyiming](https://github.com/dingyiming)，webpack中文社区的几位筹办成员，还有许多[贡献本项目的热心技术同仁](https://doc.webpack-china.org/about)。 如果想参与我们的翻译项目，请关注我们的[官方文档翻译计划](https://github.com/webpack-china/webpack.js.org)。 如果有webpack相关的技术文章，可以在[awesome-webpack-cn](https://github.com/webpack-china/awesome-webpack-cn)给我们提pull request。 如果有兴趣参与社区筹办，请关注我们的[harpers](https://github.com/webpack-china/harpers)项目。 我们会持续关注webpack，关注前端工程化发展的方方面面。 By AlloyTeam LeeHey, webpack-china首席打杂 于2017.2.25，一个寒冷的春夜
[原文链接](https://github.com/lcxfs1991/blog/issues/13) 本文使用starter-kit：[steamer-react react分支](https://github.com/SteamerTeam/steamer-react/tree/react)。此分支已集成react与preact。 ## 背景 最近接手了互动视频的项目，做了一个月的运营活动。跟基础功能不同，运营活动更为轻量。因此许多同事并不想用那么“重”的React。但同时，大家由于之前度过React的上手痛苦期后，开始体会到React的许多好处，裸写运营活动的时候，又开始对React的好处念念不忘记：良好的组件化、解放js能力的jsx等。 因此，寻找轻量化的类React解决方案便提上日程。 ## Preact的优点 选型的时候，首先有几个考量： - 开源社区有较多star（认可） - 较好的性能和兼容性 - api跟React接近 - 足够的框架周边，配置redux，router等使用 - 团队成员有能力维护的 基本上以上几点，Preact都能够很好的满足，因此最终选定为团队的类React轻量化框架进行使用和研究。 ### 开源社区有较多star（认可） 相比起[react-lite](https://github.com/Lucifier129/react-lite)，[Deku](https://github.com/anthonyshort/deku), [Virtual-DOM](https://github.com/Matt-Esch/virtual-dom)，Preact虽然不是最多的star，但也能排第2，也具备测试用例，且作者开通了gitter chat跟开发者保持联系，某天在上面留言，作者也是回复得很迅速。  ### 较好的性能和兼容性 性能方面，Preact也不俗。加载性能方面，由于本身的bundle在gzip后大概只有3kb，跟React相比小太多，自由就有优势。渲染性能方面，参考了一篇[JS...