暂时未有相关云产品技术能力~
每天进步一点点 研磨生活的香甜
当前我们组管理着一套审核系统,除了数据源是服务端提供的,其余后台管理都是由我们组在维护。 这个系统就是将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方面研究颇深,读后非常受益,特在此做记录。
经常在工作时被人小窗,这里的计算有问题,那里的表格没内容了等等,一开始肯定是懵逼状态,然后是根据症状一步步的摸索代码逻辑。
公司目前在线上运行着一款小程序,为了能监控小程序的运行情况,自行开发了一个参数搜集的SDK,名称为 shin.js,放置在 utils 目录中。
在将监控日志的服务独立部署后,还是发现CPU会在不特定时间段(例如21~22、23~02等)飙到70%,内存也是一路飙升不会下降,明显是出现了内存泄漏。
前端性能监控是个老话题了,各个团队都会对其有所关注,因为关注性能是工程师的本分。
在将数据传送到后台之前,已经做了一轮清洗工作,如果有需要还可以再做一次清洗。 日志表如下所示,自增的 id 直接偷懒使用了 bigint,没有采用分表等其他技术。
目前市面上有许多成熟的前端监控系统,但我们没有选择成品,而是自己动手研发。这里面包括多个原因: 填补H5日志的空白 节约公司费用支出 可灵活地根据业务自定义监控 回溯时间能更长久 反哺运营和产品,从而优化产品质量 一次难得的练兵机会
前端会与公司的所有部门有协作,若在某一环出现问题,就会发生不必要的时间开销,降低开发效率。所以有必要制订一套完善的协作流程。
对所有引用都使用 const,不要使用 var。原因:这样做可以确保你无法重新分配引用,以避免出现错误和难以理解的代码。 如果引用是可变动的,使用 let 代替 var。原因:let 是块级作用域的,而不像 var 属于函数级作用域。 坚持使用全等 === 摒弃相等 ==,原因:相等会进行隐式的类型转换。 使用浏览器全局变量时加上 window 前缀,document 和 navigator 除外。
近日读了一本名为《精通模块化JavaScript》的书,并记录了其中的精髓。
shin 的读音是[ʃɪn],谐音就是行,寓意可行的后端系统服务,shin-server 的特点是:
shin 的读音是[ʃɪn],谐音就是行,寓意可行的后台管理系统,shin-admin 的特点是:
短链顾名思义是一种很短的地址,应用广泛,例如页面中有一张二维码图片,包含的是一个原始地址(如下所示),如果二维码中的链接需要修改,那么就得发代码替换掉。
由于公司规模并不大,因此一有事情就会拉个会议,例如需要大会、技术评审、汇报周会、突发会议等。一周中大概有20%~30%的时间会花在大大小小的会议上。
最近在读一本名为《凤凰项目:一个IT运维的传奇故事》的书,读后颇有感触,从业这么多年,的确碰到过书中的很多场景,书中描绘的故事其实就是现实工作中的各类缩影。
最近做一个活动,需要用到定时任务,于是使用了 node-schedule 库。
最近跳槽到一家创业多年的小公司,带一个前端小团队。 在这一个多月中,主要是熟悉业务,维护老代码,编写新业务等,期间也发现了当前团队出现的种种问题,打算在接下来的日子里好好改造。
《安全攻防技能30讲》是极客时间上的一个关于Web安全的专栏,在学习之后特在此做记录和总结。
《设计模式之美》是极客时间上的一个代码学习系列,在学习之后特在此做记录和总结。
《设计模式之美》是极客时间上的一个代码学习系列,在学习之后特在此做记录和总结。
动态规划(Dynamic Programming,DP)是指在给定的约束条件下求最优值的算法,在解决问题的过程,需要经历多个决策阶段,每个决策阶段都对应着一组状态。
分治算法(Divide-and-Conquer Algorithm),就是分而治之,把一个复杂问题分成两个或更多个相同或相似的子问题,直到最后子问题可以简单的直接求解,原问题的解即子问题的解的合并。
贪心算法(Greedy Algorithm)会在每一步选择中都采取当前状态下最好或最优(即最有利)的选择,不能回退,从而希望结果是最好或最优的算法。它是动态规划的一种特例,需要满足更多的限制条件。
回溯算法(backtracking)是一个类似枚举的搜索尝试过程,在寻找问题解的过程中,当发现不满足求解条件时,就退回一步,尝试其它路径,该算法的时间复杂度都不会低于 O(N!),复杂的例题包括正则表达式匹配、解数独等。
二分查找(Binary Search)是对一种针对有序数据集合的查找算法,依赖数组,适合静态数据。通过 n/2^k=1(k 是比较次数),可以求得 k=log2^n,因此时间复杂度为高效地 O(logn)。
栈(stack)是一种操作受限的线性表数据结构,基于后进先出(LIFO)策略的集合类型,例如函数中的临时变量符合后进先出的特性,因此用栈保存最合适。
链表(Linked List)是不同于数组的另一种数据结构,它的存储单元(即结点或元素)除了包含任意类型的数据之外,还需要包含指向另一个结点的引用,后文会用术语链接表示对结点的引用。
《浏览器工作原理与实践》是极客时间上的一个浏览器学习系列,在学习之后特在此做记录和总结。
《浏览器工作原理与实践》是极客时间上的一个浏览器学习系列,在学习之后特在此做记录和总结。
《浏览器工作原理与实践》是极客时间上的一个浏览器学习系列,在学习之后特在此做记录和总结。
《浏览器工作原理与实践》是极客时间上的一个浏览器学习系列,在学习之后特在此做记录和总结。
用户体验(UE/UX)是指一个人使用一个特定产品、系统或服务时的行为、情绪与态度,还包含用户对于系统的功能、易用和效率的感受,因此用户体验在本质上可以视为一个人对于系统的主观感受与主观想法。