blog
blog copied to clipboard
lcxfs1991
leehey's blog -- 请star或者watch
## 前言 React 的开发也已经有2年时间了，先从QQ的家校群，转成做互动直播，主要是花样直播这一块。切换过来的时候，业务非常繁忙，接手过来的业务比较凌乱，也没有任何组件复用可言。 为了提高开发效率，去年10月份也开始有意识地私下封装一些组件，并且于今年年初在项目组里发起了百日效率提升计划，其中就包含组件化开发这一块。 本文并不是要谈如何去写一个 React 组件，这一块已经有不少精彩的文章。例如像这篇[《重新设计 React 组件库》](http://mp.weixin.qq.com/s/8dZV0oKfBKp-jERguNxflw)，里面涉及一个组件设计的各方面，如粒度控制、接口设计、数据处理等等（不排除后续也写一篇介绍组件设计理念哈）。 本文关键词是三个，工程化、快速和可靠。我们是希望利用工程化手段去保障快速地开发可靠的组件，工程化是手段和工具，快速和可靠，是我们希望达到的目标。 前端工程化不外乎两点，规范和自动化。 读文先看此图，能先有个大体概念：  ## 规范 ### 目录与命令规范 规范，主要就是目录规范和代码规范。跟同事合作，经过将近20个的组件开发后，我们大概形成了一定的目录规范，以下是我们大致的目录约定。哪里放源码，哪里放生产代码，哪里是构建工具，哪里是例子等。有了这些的约定，日后开发和使用并一目了然。 ```javascript __tests__ -- 测试用例 | example -- 真实demo | dist --...
## 前言 [《React移动web极致优化》](https://github.com/lcxfs1991/blog/issues/8)也提到了，构建工具是前端优化的重要一环。而React的推荐构建工具则是Webpack。这篇文章我们就来聊聊如何在Webpack构建的过程中如何针对React的应用做一些优化。 如果还没看过[《webpack使用优化（基本篇）》](https://github.com/lcxfs1991/blog/issues/2)这篇文章，建议去看看，因为针对React的优化往往也离不开Webpack那些最基本的优化点。此外，在这里将Webpack视作构建可能招来一些人的反对，他们会将Webpack定位成打包的工具。但实际项目中，除了合图以外，家校群项目已将Webpack将为最核心的构建工具。 本篇文章的成果最终都会转化成一个开源的boilerplate, [steamer-react](https://github.com/lcxfs1991/steamer-react)(暂时设为私有项目)。 ## 目录结构  构建工具离不开目录的设计，我们需要安排号文件存放的位置才便于构建工程的开展。在src目录下一级的文件，除了page文件夹是react的主体逻辑文件之外，其它的像img, js, css, libs，都属于各个页面都会用到的公共文件，如utils, 上报等。 page目录下，common文件夹主要旋转跟React相关的一些公共的文件，如公共的component，中间件等。而其它的文件夹就是每个页面的主体逻辑和资源，另外就是页面对应的html文件。 由于家校群采用的是React+ Redux这套方案，我们文件夹的名字也很能体现这套方案的特色。首先组件Component方面，我们比较认同Redux推崇的smart component(container)和dump component，因此它们分别放置在container和component文件夹下。那container和component文件夹下面放在什么呢？我们放置了组件相关的逻辑js和样式scss文件。我们暂时没将图片放在组件这一层，而是放在页面这一层，是因为我们业务不同组件间共用了不少图片，因此放在更上一层更为合适。 而store, reducer, action, connect都是跟Redux这个数据处理框架相关。像root这样的文件夹则是项目的主入口，里面有root.dev.js和root.prod.js，用于区分开发环境与生产环境对应需要引入的组件。 如果你还用到React-Router，可能你还需要多加一个route的文件夹，里面用存放项目route的配置文件。 这套文件架构比较传统的gulp和grunt复杂，但却更符合React + Redux这套方案的开发思路。 ## 针对React的优化点 ###...
## 背景： 1. 对构建的改造已经完成，目前构建的能力可以较为灵活地支撑进一步的优化 2. 希望进一步减少首屏时间，将首屏时间控制在2秒以内 ## 页面情况： 优化之前，并没有上报首屏时间，页面加载时间约为2.4秒。 研究认为[1]，用户最满意的网页打开时间是2秒以内。作为一个相对简单的页面，我们就应该最可能将首屏时间甚至加载时间控制在2秒以内，让用户体验到最佳的页面体验。 ## 定义页面的首屏与加载时间： 首屏时间，英文称之为above the fold(首屏线之上)。我们以手Q群成员分布的页面作为例子。在iPhone5屏幕下，这个页面在没有往下滚动的时候，如上图。滚动到底部时，如下图。   我们所说的首屏时间，就是指用户在没有滚动时候看到的内容渲染完成并且可以交互的时间。至于加载时间，则是整个页面滚动到底部，所有内容加载完毕并可交互的时间。 在这个页面中，我们可以划分成四个部份，分别是活跃 群成员、男女比例、省市分布及年龄。我们将前三个部份归入首屏渲染时间。剩下的内容加载时间加上首屏加载时间即是页面加载时间。 另外值得一提的是，由于之前项目的开发将动画渲染时间也纳入统计，因此为了方便对比，我也将渲染时间纳入统计。实际上，如果除去动画渲染时间，首屏及加载时间会快300 - 500ms。 ## 已经做好的优化: 除非各种性能优化书籍提出的要点之外，在这篇优化之前已经做到的优化并值得简单提出来的有两点。 1. 活跃群成员头像的懒加载。由于手Q的头像允许gif，因此直接加载头像性能会比较低下。因此之前在完成这块业务的逻辑的时候，已经添加上懒加载，业务渲染的时候显示默认头像，等真实头像加载完成的时候再进行渲染。而且，在这次的优化项目中，我们并不将头像的加载时间也纳入首屏时间内。 2. 其它内容动画的滚动渲染。其它部份的内容是会由滚动渲染效果的（这些逻辑并不由本人写）。感谢前人做比较模块化地做好了这部份逻辑，因此我能够比较容易地进行代码的搬迁与更改。...
# 这是前端最好的时代——论前端的“三化”建设 原文发表于：[CSDN](http://www.csdn.net/article/2015-07-17/2825243-alloy-team-leehey) 作者： 腾讯AlloyTeam， 李成熙LeeHey "每18至24个月，前端都会难一倍"（注：2015深JS大会上，赫门在《前端服务化之路》主题演讲中说的一句话）。难，是前端发展史偶然中的必然。但难，也造就着前端当下的繁荣。 Ryan Dah之所以选择用Javascript作为Node.js的基础语言，主要是因为它是单线程的，没有服务器I/O，没有历史包袱，有较低的门槛和比较良好的社区1。这看似是偶然，但实际上正正是Javascript的这些优秀的特性必然被历史选择，承担推动web技术发展的使命。(注：Node.js Interview: 4 Questions with Creator Ryan Dahl, http://bostinno.streetwise.co/2011/01/31/node-js-interview-4-questions-with-creator-ryan-dahl/) 本届的深JS大会，我们看见的是在Node.js的推动下，前端技术大放异彩，逐渐告别"石器时代"，走向"工业时代"。而通过推动前端"工业时代"的离不开"三化"的建设，分别是自动化、实时化与服务化。 ## 一、前端自动化 前端的自动化技术已经发展了好几年，之前涌现的grunt, gulp都已经帮助前端很好地解决代码压缩，生成md5，合图等的功能。自动化属于"三化"中的基础，它的发展极大释放了前端的手脚，让前端有更多的时候专注于实时化与服务化的发展。大会带来与前端相关的主题是前端的测试自动化。这相信是前端自动化比较棘手的问题。 马逸清给我们展示了七牛存储在前端测试上的一些尝试。但目前来看成果还是相当有限的。其一，他们的做法主要是针对于Javascript的逻辑，或者是一些基本的UI交互的测试，浏览器兼容性的测试、前端页面与设计稿的对齐方面的测试，基本都是空白。其二，即使他们现在可以对Javascript的逻辑进行测试，但比较好的切入条件是对DOM的隔离，所以，如果业务使用的是View与Model的框架如Angular的话，测试是比较友好的。但如果使用到的是web component这种将Javascript, CSS和HTML模块化地放在一起的元素，则比较麻烦。 对于前端页面与设计稿对齐的测试，我们团队AlloyTeam也有一些尝试，曾开发过一个AlloyDesigner的工具。而对于浏览器兼容性测试，在IE流行的时代，为了兼容IE，很多人喜欢用一个叫IE Tester的工具。但这些都只属于测试的工具化，离自动化还有很长的距离。 ...
Bumps [follow-redirects](https://github.com/follow-redirects/follow-redirects) from 1.15.5 to 1.15.6. Commits 35a517c Release version 1.15.6 of the npm package. c4f847f Drop Proxy-Authorization across hosts. 8526b4a Use GitHub for disclosure. See full diff in compare...
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot] avatar"){kind=avatar}
最近公司某业务有个事故，在用户使用高峰的时候页面打开白屏，大概20多分钟才恢复。复盘后发现根本的原因是由于在整个网络链路上云厂商提供的专线网络带宽打满，导致页面静态资源加载过慢或无法加载，进而引发的事故。 有鉴于此，在部门内组织各业务梳理，看看有没有业务有类似的带宽风险。让大家梳理的过程中，发现大家对前端服务中间通过的通路、带宽基本都没什么概念。前端团队如果没人懂网络、懂带宽，感觉是比较危险的，不仅业务的可用性风险无人洞悉，对如何控制成本也没有概念，在现在互联网的大环境来说这是比较难接受的。 # 前端部署架构 一般来说，后台的网络架构论述的较多，实际上前端也有网络的架构，一般的前端网络架构分两种，一种是全部资源部署在服务器，另一种是将部份静态资源放到CDN，架构如下：   上面是常见的两种前端的部署架构，负载均衡到K8S服务的网络要比上面描述的更复杂，这里为了易于理解做了简化。此外，如果没有运维能力或者服务并不需要建设K8S，也可以更换成普通的虚拟机。 你会发现，在K8S和CDN双部署架构中，CDN有可能需要回源。CDN通常将静态资源部署在靠近用户的服务器上，以加快加载速度。但如果靠近用户的服务器尚未缓存这些资源，则这些资源的请求将直接发送到源站，这被称为回源。 源站可以是在云服务厂商处购买的对象存储，也可以是存储在K8s中的资源。至于采用哪种，主要是看诉求和预算。如果预算较低，可以直接部将源站设置到服务的K8S中，与html资源放在一起。如果是预算充足，还需要一些比如鉴黄、自动压缩、自动缩放裁剪等功能，那大可以使用对象存储。 # 带宽会如何影响前端资源 当我们对部署架构有所了解，下一步就需要知道部署架构中所经过的网络带宽的上限是多少了，因为带宽的上限深刻地影响着服务的质量。一般来说，所有的网络通路都会有带宽的限制，但网部的网络由于上限较高，很多时候都会被忽略。 带宽的单位一般用Mbps(每秒Mb)或Gbps（每秒Gb），分为上行与下行，上行会影响资源的上传速度，下行则会影响资源的下载速度，对前端资源来说，下行的带宽影响最为深刻。 那我们在哪里可以获取带宽的信息呢？一种是可以在购买云资源的时候，设备规格的时候获取，比如当你买一台云虚拟机，以下是购买虚拟机时，内网带宽与外网带宽的信息： 也可以在购买的云资源里，找到相应的带宽信息： # 按带宽还是按流量计费 细心的你会发现，无论是购买云服务器，还是CDN，都会有两种经典的收费模式，一种是按带宽计费，一直是按流量计费。如果您不确定如何选择，可以查看云厂商的说明文档。他们通常会根据不同场景提供推荐。譬如他们会推荐有一定访问量但流量较为稳定的个人博客使用按带宽计费，而那些电商的大促活动有一定的性能要求的，大部份时间用按带宽计费，而重大活动为了保证性能而按流量计费。 选择的模式可能并不是最开始就能够选到最优解，可以在相同业务的反复尝试中发现对业务成本最低的计费方式，最终进行选择即可。 # 如何判断业务带宽瓶颈 对于那些按流量计费的云资源而言，主要的瓶颈就是云资源的预算。而对于那些按下行带宽计费的云资源，主要的瓶颈就是业务下行的带宽峰值远超云资源自身的带宽上限。既然我们能够查询到云资源的带宽上限，那如何判断业务目前是否有瓶颈呢？ 第一个办法是可以通过云服务厂商的监控，找到业务带宽的峰值，如下图。如果外网出带宽使用率长时间达到90% - 100%，那表示目前的带宽可能会对业务造成瓶颈，需要适当加大带宽。 如果没有这种监控或者比较难找到，那该怎么办呢？可以通过在Chrome浏览器的Network面板中粗略估算：...
> 李成熙，某大型央企数字化架构师。先后在腾讯文档、腾讯云云开发、Shopee金融团队担任 Leader 和架构师。专注于性能优化、工程化和小程序服务。[微博](https://weibo.com/leehkfs/) | [知乎](https://www.zhihu.com/people/leehey/) | [Github](https://github.com/lcxfs1991) 做数字化转型业务已经有大半年，虽然以前在做智能表格类工具的时候，就有思考过如何通过智能表格类工具解决企业流程的问题，但远不如这大半年深更业务来得更真切。在这过程中也逐步习得了数字化转型的过程，并扫除了以前对数字化转型的一些误区，通过此文给大家分享。 # 第一步：业务线上化 数字化从字面意思看，就是要将业务都数字化，后面基于数据再开展一系列业务的降本增效提质。数据怎么来呢？那必须尽可能将业务线上化了。 初入门者看似很简单，实则深似水。从互联网公司转型过来的从业者会发现以前的经验都失效了，很多时候也难以站在一个用户的角度来审视如何线上化这个问题。譬如以前做社交产品，还能自己站在普通用户的角度，YY出不少看似说得通的需求，到了企业数字化领域，不能一头扎入业务中，多跟业务分析师、一线业务专家沟通，业务这潭深水就可以够呛一肚子水。 业务的线上化并非易事，需要遵循以下的步骤： ## **建立系统之间的关系**  建立系统之间的关系，本质是建立了数据流动的链条。系统主要是承载企业的数据，将系统连接起来即是将他这些数据串联起来，产生1+1>2的价值。 作为数字化专家，比较少见可以在企业成立之初就参与数字化的建设。企业草创阶段更多是企业的负责人担当这一角色。数字化专家半路加入，往往可能是面对一系列外部采购的系统，如：存储员工信息的飞书，存储财务预算的飞书文档和财务经营数据的金蝶，存放客户资料和销售线索的纷享销客等等。如果有研发实力的企业，可能还养着一个小团队，自研搭建了一些简单的业务系统。 企业数字化的过程，就像在下一盘围棋一样，每通过外采/自研建设一个系统，就像在棋盘上下子，并且我们在下子的过程中都会寻求棋子之间的联系，比如每个系统的用户信息，都可以通过飞书获取；生产经营的信息导出成文档，基于这些文档的数据可以在飞书上做财务预算；生产系统可以基于客户资料和销售线索调整生产计划等等。这些系统只有像棋子一样联系起来，整盘棋才能盘货起来，在市场竞争中占据优势。如果所有系统都没有规划，各自为政，一盘散沙，那势必会被竞争对手吞掉。想象一下，如果每建设一个系统的员工信息都需要重新建设，那该多头疼。 至于这些系统是怎么串联起来，一般来说通过数据的导入导出、开放接口等技术手段，采用哪种基于成本考虑，在此就不作赘述。 ## **梳理标准作业流程**  在已有信息输入的基础上，我们建立了系统之间的联系，这些系统有的是已经存在的，有的是亟待规划落地的。良好的系统关系的梳理与建立，能够帮助企业高屋建瓴地做好后续信息化的规划，知道系统建设的优先级，毕竟数字化的资源（预算、人力）是有限的。 确认了规划，我们才好知道下一步该建设哪个系统，这时我们便进入了第二阶段，梳理标准作业流程。这一阶段，可能通过翻阅过往标准作业流程文档、与业务专家进行访谈等手段，全面地梳理清楚这些流程。有了标准作业流程，数字化专家才好去对这些流程做归类，形成系统的功能模块，并规划相应的功能模块将这些标准作业流程线上化。 ## 自研还是采购？ 系统的落地无非是通过自研或者采购。不过这个命题对于那些中小企业来说看来是无需烦恼的，采购只能是唯一划算的出路。 对于有自研能力的公司，这是个头疼的问题。即使自研能较强的互联网公司，也不可能所有的能力都由自己建设。最常见的代码仓库、发布系统等等，往往是“采购”自公司内部的研效团队。选择自研，无非是希望可以更灵活、更可控；选择采购无法是看种成本——资金成本、时间成本。基于这些考虑，公司对那些服务较为核心、战略级业务，且愿意花更多时间等待成长成熟的系统，更多倾向于自研。而那些非核心的，等太久公司会瘫痪的系统（时间成本），也不需要花大价钱（有许多同样采购的客户分摊了成本）购买的，如财税系统、办公软件，则更多倾向于采购。...
Bumps [express](https://github.com/expressjs/express) from 4.18.2 to 4.19.2. Release notes Sourced from express's releases. 4.19.2 What's Changed Improved fix for open redirect allow list bypass Full Changelog: https://github.com/expressjs/express/compare/4.19.1...4.19.2 4.19.1 What's Changed Fix...
Bumps [webpack-dev-middleware](https://github.com/webpack/webpack-dev-middleware) from 5.3.3 to 5.3.4. Release notes Sourced from webpack-dev-middleware's releases. v5.3.4 5.3.4 (2024-03-20) Bug Fixes security: do not allow to read files above (#1779) (189c4ac) Changelog Sourced from...