暂时未有相关云产品技术能力~
每天进步一点点 研磨生活的香甜
从零开始搞基建(5)——代码质量
Node.js躬行记(28)——Cypress自动化测试实践
前端性能精进之优化方法论(二)——分析 (下)
前端性能精进之优化方法论(二)——分析 (上)
前端性能精进之优化方法论(一)——测量 (下)
前端性能精进之优化方法论(一)——测量
我好像找到了点学习英文的技巧
带团队后的日常思考(十一)
Node.js躬行记(26)——接口拦截和页面回放实验
【译】2022 年回顾:Web 性能有哪些新变化?
数据化运营初探
Node.js躬行记(25)——Web自动化测试
HTML躬行记(4)——Web音视频基础
HTML躬行记(3)——WebRTC视频通话
HTML躬行记(2)——WebRTC基础实践
Node.js躬行记(24)——低代码
Node.js躬行记(23)——Worker threads
前端稳定性建设
Node.js躬行记(22)——Node环境升级日志
前端利器躬行记(8)——VSCode插件研发
性能参数和优化手段
Web优化躬行记(6)——优化闭环实践
量化日常工作指标
记录两次多端排查问题的过程
Node.js精进(11)——Socket.IO
Node.js精进(10)——性能监控(下)
Node.js精进(9)——性能监控(上)
Node.js精进(8)——错误处理
Node.js精进(7)——日志
Node.js精进(3)——流
Node.js精进(2)——异步编程
Node.js躬行记(21)——花10分钟入门Node.js
CSS躬行记(11)——管理后台响应式改造
我们组维护的管理后台会接到很多开发需求,每次新开页面,就会到处复制黏贴相关代码。 并且还会经常性的翻阅文档,先在书签或地址栏输入WIKI地址,然后找到那一份说明文档,再定位到要看的组件位置。 虽然单人损耗的时间并不是非常多,但还是会打断思路,影响开发的流畅性,当把所有人的时间累加起来,那损耗的时间也很可观。
最近有个活动,在提测后的第二天,大家才得知上线时间是后天。但是问各个技术,大家都不知道这个时间,而产品是知道的,运营也知道这个时间。 那这就有点诡异了,为何会出现这个情况呢,进一步了解后,才发现原来在一次会议上,口头说了下上线时间和提测时间。 在那次会议上,大家都说了自己的开发时间,但是,对于提测时间,开发和运营却有不同理解。我的提测时间是11或12,但运营的提测时间是10号,以后对于这种时间截点还是要更敏感一点。 UI给到我们设计稿的时间,晚了一天,其实如果不晚的话,即使我们不知道上线时间,也会按预期进行。
在2020年我刚到公司的时候,公司使用的版本还是1.0,之后为了引入微前端,迫不得已被动升级。
最近在阅读产品相关的一本书,叫《幕后产品》,特在此做记录。
一直想将一些常规活动抽象化,制作成可配置的。原先的计划是做成拖拽的,那种可视化搭建,运营也能自己搭建页面。 这是一个美好的愿景,但是现实不允许我花太多精力去制作这样一个系统。经过权衡后,先设计成一个可配置化的系统。 先对一类常用的打榜活动做定制化的设计,解决当前问题,立竿见影的提升工作效率。 先说说此系统的价值,当它完成后,受益方将包括设计组、Web组、产品组、QA组和数据分析组。
公司是个几十人的创业公司,虽然人数不多,不过有稳定的现金流,去年的业务收益也在持续增长。 现在前端团队的人员数量已经无法满足日益增长的业务需求了,所以需要扩招,再招两个3年左右的前端。 在此背景下,让HR在传统招聘网站上发了招聘信息,自己也没闲着,不仅在一个前端知名公众号中投稿招聘,还在V站上发了个帖子。 虽然转化率并不是很理想,不过还是收到了几份简历。加上HR推来的简历,前前后后也面了十几个人。 虽然人数不多,但还是想做些记录,分享给有需要的朋友。
在日常的业务开发中,会包含许多的业务规则,一般就是用if-else硬编码的方式实现,这样就会增加逻辑的维护成本,若无注释,可能都无法理解规则意图。 因为一旦规则有所改变,那么就需要修改代码再发布代码,而在日常的开发中唯一不变的就是变化,修改规则是很常见的。 规则引擎的作用就是将决策逻辑从业务逻辑中抽离出来,使得两者可以独立于彼此,便于集中管理,减少硬编码的成本和风险,在不重启服务的情况下快速响应需求的变化。
最近被插入了一个需求,我们组经常会被插入各式各样的需求,因为之前负责的范围非常广。 这次的需求就和一个陈年接口有关,其实要修改的地方并不多,就是为一个请求多加一个参数。 但是比较麻烦的地方就是验证阶段,就是我在加上这个字段后,我得知道发请求的时候真的带上了。 根据URL地址反查到了页面代码,在本地启动项目,访问页面,直接报错。 调试陈年项目,这种情况是经常发生的,涉及的问题很多,例如内部接口不通了,数据库表结构变了,需要的数据记录本地没有等等。
公司的PM(项目经理)采用了轮流制,这次轮到我来做了。 与上一任PM沟通后,发现风险并不在于技术方面,主要还是在于需求和跨组协作方面出现了问题。 具体包括需求评审不够细,有遗漏,导致实际所需时间比预期长;操作变更未通知其他组人员;缺少UI评审环节等。 让我印象最深刻的是一个发送站内信的功能,因为客户端与产品对于兼容程度的理解不同,而导致项目延期了多天。
软件架构指软件系统的顶层结构;框架是面向编程或配置的半成品;组件是从技术维度上的复用;模块是从业务维度上职责的划分;系统是相互协同可运行的实体。 软件开发最本质的挑战有两个:复杂和变更,而软件的价值是保证业务的响应力,与之相对的是开发资源的有限,各种的软件开发方法论,也都是在研究有限的资源下,如何应对着两个挑战,寻找平衡点,实现业务目标。因为是在寻找平衡点,就说明是有取舍的,所以就没有所谓的银弹的存在。
当前我们组管理着一套审核系统,除了数据源是服务端提供的,其余后台管理都是由我们组在维护。 这个系统就是将APP中的各类社交信息送到后台,然后有专门的审核人员来判断信息是否合规,当然在送到后台之前已经让机器审核了一遍。
最近阅读了很多优秀的网站性能优化的文章,所以自己也想总结一些最近优化的手段和方法。 个人感觉性能优化的核心是:减少延迟,加速展现。 本文主要从产品设计、前端、后端和网络四个方面来诉说优化过程。
公司有个匿名聊天的常规H5界面,运营向做一次 50W 的推送,为了能配合她的计划,需要对该界面做一次压力测试。
当前我们组管理着一套审核系统,除了数据源是服务端提供的,其余后台管理都是由我们组在维护。 这个系统就是将APP中的各类社交信息送到后台,然后有专门的审核人员来判断信息是否合规,当然在送到后台之前已经让机器审核了一遍。 在去年8月份上线后,日积月累,有张数据表变得比较庞大,截止到目前将近5800W条,数据容量31.21G,每条记录大概是582B。 由于数据量庞大,在检索时也将模糊查询撤掉,并且为了便于查询,还加了很多索引,目前的索引容量都达到了12.2G,审核人员也经常反馈系统使用起来很卡。
单元测试有助于避免尴尬、耗时的错误,将测试作为安全网只是一部分,更大部分是将测试表达为代码的思考过程。 接下来的内容提炼自《单元测试的艺术(第2版)》和《有效的单元测试》两本书。
他们组没有一个正式的组长,只有一个临时的代理组长,这种情况从我进公司到现在一直是这种情况,也是蛮奇怪的。 前几天,这个代理组长和其中的一个组员爆发了点冲突,我从旁观者对他们对话的理解就是,组员觉得他瞎指挥,他觉得组员无担当。
去年的9月底,我离开呆了5年之久的老东家,撤离舒适区,进入一个全新的环境。到今年的这个时候,已经差不多是一周年了。 这一年过的非常快,与之前很不同,每天都在忙碌着,都会遇到新的状况,想不同的应对策略,不像以前早上倒杯水,坐会儿,然后按部就班的工作。 每周的感觉是周一上班,明天就是周五,每日的感觉是早上上班,一眨眼就是晚上18点30了,又快要下班了。