暂时未有相关云产品技术能力~
Node.js躬行记(28)——Cypress自动化测试实践
前端性能精进之优化方法论(二)——分析 (下)
前端性能精进之优化方法论(一)——测量 (下)
前端性能精进之优化方法论(一)——测量
Node.js躬行记(26)——接口拦截和页面回放实验
【译】2022 年回顾:Web 性能有哪些新变化?
数据化运营初探
Node.js躬行记(25)——Web自动化测试
HTML躬行记(4)——Web音视频基础
HTML躬行记(3)——WebRTC视频通话
Node.js躬行记(24)——低代码
前端稳定性建设
前端利器躬行记(8)——VSCode插件研发
性能参数和优化手段
量化日常工作指标
Node.js精进(11)——Socket.IO
Node.js精进(10)——性能监控(下)
Node.js精进(8)——错误处理
我们组维护的管理后台会接到很多开发需求,每次新开页面,就会到处复制黏贴相关代码。 并且还会经常性的翻阅文档,先在书签或地址栏输入WIKI地址,然后找到那一份说明文档,再定位到要看的组件位置。 虽然单人损耗的时间并不是非常多,但还是会打断思路,影响开发的流畅性,当把所有人的时间累加起来,那损耗的时间也很可观。
最近有个活动,在提测后的第二天,大家才得知上线时间是后天。但是问各个技术,大家都不知道这个时间,而产品是知道的,运营也知道这个时间。 那这就有点诡异了,为何会出现这个情况呢,进一步了解后,才发现原来在一次会议上,口头说了下上线时间和提测时间。 在那次会议上,大家都说了自己的开发时间,但是,对于提测时间,开发和运营却有不同理解。我的提测时间是11或12,但运营的提测时间是10号,以后对于这种时间截点还是要更敏感一点。 UI给到我们设计稿的时间,晚了一天,其实如果不晚的话,即使我们不知道上线时间,也会按预期进行。
在2020年我刚到公司的时候,公司使用的版本还是1.0,之后为了引入微前端,迫不得已被动升级。
最近在阅读产品相关的一本书,叫《幕后产品》,特在此做记录。
一直想将一些常规活动抽象化,制作成可配置的。原先的计划是做成拖拽的,那种可视化搭建,运营也能自己搭建页面。 这是一个美好的愿景,但是现实不允许我花太多精力去制作这样一个系统。经过权衡后,先设计成一个可配置化的系统。 先对一类常用的打榜活动做定制化的设计,解决当前问题,立竿见影的提升工作效率。 先说说此系统的价值,当它完成后,受益方将包括设计组、Web组、产品组、QA组和数据分析组。
公司是个几十人的创业公司,虽然人数不多,不过有稳定的现金流,去年的业务收益也在持续增长。 现在前端团队的人员数量已经无法满足日益增长的业务需求了,所以需要扩招,再招两个3年左右的前端。 在此背景下,让HR在传统招聘网站上发了招聘信息,自己也没闲着,不仅在一个前端知名公众号中投稿招聘,还在V站上发了个帖子。 虽然转化率并不是很理想,不过还是收到了几份简历。加上HR推来的简历,前前后后也面了十几个人。 虽然人数不多,但还是想做些记录,分享给有需要的朋友。
在日常的业务开发中,会包含许多的业务规则,一般就是用if-else硬编码的方式实现,这样就会增加逻辑的维护成本,若无注释,可能都无法理解规则意图。 因为一旦规则有所改变,那么就需要修改代码再发布代码,而在日常的开发中唯一不变的就是变化,修改规则是很常见的。 规则引擎的作用就是将决策逻辑从业务逻辑中抽离出来,使得两者可以独立于彼此,便于集中管理,减少硬编码的成本和风险,在不重启服务的情况下快速响应需求的变化。
公司的PM(项目经理)采用了轮流制,这次轮到我来做了。 与上一任PM沟通后,发现风险并不在于技术方面,主要还是在于需求和跨组协作方面出现了问题。 具体包括需求评审不够细,有遗漏,导致实际所需时间比预期长;操作变更未通知其他组人员;缺少UI评审环节等。 让我印象最深刻的是一个发送站内信的功能,因为客户端与产品对于兼容程度的理解不同,而导致项目延期了多天。
软件架构指软件系统的顶层结构;框架是面向编程或配置的半成品;组件是从技术维度上的复用;模块是从业务维度上职责的划分;系统是相互协同可运行的实体。 软件开发最本质的挑战有两个:复杂和变更,而软件的价值是保证业务的响应力,与之相对的是开发资源的有限,各种的软件开发方法论,也都是在研究有限的资源下,如何应对着两个挑战,寻找平衡点,实现业务目标。因为是在寻找平衡点,就说明是有取舍的,所以就没有所谓的银弹的存在。
当前我们组管理着一套审核系统,除了数据源是服务端提供的,其余后台管理都是由我们组在维护。 这个系统就是将APP中的各类社交信息送到后台,然后有专门的审核人员来判断信息是否合规,当然在送到后台之前已经让机器审核了一遍。
最近阅读了很多优秀的网站性能优化的文章,所以自己也想总结一些最近优化的手段和方法。 个人感觉性能优化的核心是:减少延迟,加速展现。 本文主要从产品设计、前端、后端和网络四个方面来诉说优化过程。
公司有个匿名聊天的常规H5界面,运营向做一次 50W 的推送,为了能配合她的计划,需要对该界面做一次压力测试。
当前我们组管理着一套审核系统,除了数据源是服务端提供的,其余后台管理都是由我们组在维护。 这个系统就是将APP中的各类社交信息送到后台,然后有专门的审核人员来判断信息是否合规,当然在送到后台之前已经让机器审核了一遍。 在去年8月份上线后,日积月累,有张数据表变得比较庞大,截止到目前将近5800W条,数据容量31.21G,每条记录大概是582B。 由于数据量庞大,在检索时也将模糊查询撤掉,并且为了便于查询,还加了很多索引,目前的索引容量都达到了12.2G,审核人员也经常反馈系统使用起来很卡。
单元测试有助于避免尴尬、耗时的错误,将测试作为安全网只是一部分,更大部分是将测试表达为代码的思考过程。 接下来的内容提炼自《单元测试的艺术(第2版)》和《有效的单元测试》两本书。
他们组没有一个正式的组长,只有一个临时的代理组长,这种情况从我进公司到现在一直是这种情况,也是蛮奇怪的。 前几天,这个代理组长和其中的一个组员爆发了点冲突,我从旁观者对他们对话的理解就是,组员觉得他瞎指挥,他觉得组员无担当。
去年的9月底,我离开呆了5年之久的老东家,撤离舒适区,进入一个全新的环境。到今年的这个时候,已经差不多是一周年了。 这一年过的非常快,与之前很不同,每天都在忙碌着,都会遇到新的状况,想不同的应对策略,不像以前早上倒杯水,坐会儿,然后按部就班的工作。 每周的感觉是周一上班,明天就是周五,每日的感觉是早上上班,一眨眼就是晚上18点30了,又快要下班了。
BFF字面意思是服务于前端的后端,我的理解就是数据聚合层。我们组在维护一个后台管理系统,会频繁的与数据库交互。 过去为了增删改查会写大量的对应接口,并且还需要在Model、Service、Router三层写不同的代码逻辑,吃力不讨好。 为了节约开发时间,构思通用接口,并付诸于实际项目中。虽然简化了Router和Service部分,但其实就是将该部分的代码迁移到了前端页面中。
Cypress是为现代网络构建的前端测试工具,解决了开发人员和 QA 工程师在测试应用程序时面临的关键痛点。 在这个测试框架中包含了E2E测试、集成测试和单元测试(内嵌了Mocha),我们需要的是它的E2E测试的能力。 官网中包含详尽的API接口文档,以及多个视频教程、实例等,只要有耐心,看完文档,上手是不成问题的。 之所以要引入E2E测试,主要是为了保证主流程能够不出错,尤其是在后期做修修补补后,有一个可靠的方式告诉我们当前页面是正常的就行。
当运营向我们上报BUG时,我们第一时间是捕获相关的接口。从监控系统中,就可以查到用户使用时接口的请求和响应数据。 若接口的请求正常,那么就需要深入到接口代码中,查看相关的日志,通常会先浏览数据库查询语句以及内部接口的通信日志。 在本地也可以查看到上述日志,但有个问题,有时候打开某个页面会报错,那是因为本地的数据库没有与测试或正式环境的同步。 可能是有些字段缺失了,也可能是某张表缺失了,情况比较多。所以,最保险的是在测试或正式环境查看。
后台管理系统使用的是umi框架,随着公司业务的发展,目前已经变成了一个巨石应用,越来越难维护,有必要对其进行拆分了。 计划是从市面上挑选一个成熟的微前端框架,首先选择的是 icestark,虽然文档中有说明umi框架的改造,但版本得是 3 以上。 而当前我们自己使用的版本是 1,差了整整两个版本。然后再去搜索,发现另一个微前端框架:qiankun,并且它有一个 umi插件。
这次公司有个五周年的庆典活动,但正好碰到两个APP的版本发布,以及三个测试老员工离职,只进来了两个新成员,其中一个恰好要休陪产假,那么测试组资源异常紧张。 虽然我们提前了整整一周提测,但一直到周五还有很多点没测到。测试组甚至想到了阶段测试,因为多个活动的上线时间不同,所以可以先测最先上线的活动,后面的再往后推,延迟测试,这是他们组的一个对策。
最近看了一篇文章,文章中提到在开发流程中包含一个设计方案的阶段,位于需求评审之后,用于描述自己对于该需求的实现思路、模块划分等相关考虑的点,可供今后自己或他人查阅。 目的就是在编码前理清思路,整体架构,查缺补漏,作为他人或自己的技术参考文档。 自己在项目开发的过程中,也曽有过这样类似的想法,但没有作者那样写的系统,也没有在团队中落地。 基于文章中的设计方案,自己做了点修改。设计方案包括4个部分:需求、调研、实现和复盘。
11年前有幸阅读了《重构——改善既有代码的设计》第一版,当时是一口气读完的,书中的内容直接惊艳到我了。 今年读了该书的第二版,再次震撼到我了,并且这次的示例代码用的JavaScript,让我更有亲切感。 全书共有12章,前面5章是在讲解重构的原则、测试、代码的坏味道等内容,后面7章是各种经验和实践,全书的精髓所在。
最近在阅读《软件工程之美》,特在此做点记录。
最近服务端的同事分享了GraphQL,他分享的目的就是要把我们与他们的数据库隔离,这么做我们也求之不得。 我们组目前维护着一个后台管理系统,会直接读取数据库中的表,如果能隔离的话,就不需要写Model文件了。 后面再进一步了解后,明白了服务端推这个GraphQL的用意,其实就是让我们自己去维护GraphQL服务,包括客户端也去自己维护。
公司主营的是直播业务,会很许多打榜活动,也就是按主播收到的礼物或收益进行排序,排在前面的会有相应奖励。 纯手工时代,每接到一个活动,就重新写一份,第一次写完。之后就是复制黏贴,再修改,每次活动,测试人员测试也蛮苦恼的。 虽然复制的是之前的代码,已经经历过一轮测试,但手工操作难免会有这个那个的细节问题,都得重新测试一遍。
参与制订业务方的BUG规范,业务方最近投诉我们技术部,在飞书群中提出BUG后,技术部没有人响应,认为我们的态度太冷漠。 后面我就提出任何看到的人,只要知道是谁负责的,就@那个人,大家都不要客气,这是第一步。
页面奔溃包含两种场景,第一种是浏览器在加载网页时遇到问题导致的奔溃,另一种是因为脚本渲染出错导致页面空白无内容的奔溃。
在直播间有一个小时榜的Web页面,经常有用户反映点击小时榜,弹出的页面会有蛮长的一段(3秒上下)时间白屏。
核心思想就是越过基础建设,复制黏贴拿起键盘就是干,一把梭。
最近在读一篇关于Redis的专栏,叫做《Redis核心技术与实战》,作者在Redis方面研究颇深,读后非常受益,特在此做记录。
经常在工作时被人小窗,这里的计算有问题,那里的表格没内容了等等,一开始肯定是懵逼状态,然后是根据症状一步步的摸索代码逻辑。