simplefeel / blog

日常的一些思考与总结，可能是某个对技术知识点的总结，抑或是对某个事件的看法，总之啥都会写

Hi, I'm shangjin, a Developer 🚀 from China.

Talking about Personal Stuffs:

• 👨🏽‍💻 I’m currently working on weidian;
• 🙍‍♂️ Full developer | 💻 Accept remote｜🏀 Like play basketball
• 💬 Ask me about anything, I am happy to help;
• ⚡️ Fun-Fact: I have a degree in Jiangxi Agricultural University;
• 📫 How to reach me: [email protected];

Personal application

• Keepo: A product that records habits and helps develop a good lifestyle.
• Podify : A Podcast Transcribe Tool

Languages and Tools:

blog's Issues

一些神奇的数学理论在编码中的运用

TODO

cache promise

cache promise

有如下代码

const usersCache = new Map<string, User>();

const getUserById = async (userId: string): Promise<User> => {
  if (!usersCache.has(userId)) {
    const user = await request.get(`https://users-service/${userId}`);
    usersCache.set(userId, user);
  }

  return usersCache.get(userId);
};

这段代码用来获取用户的信息，但是加入了缓存处理，如果缓存有值的话直接从缓存获取，不用再去调用接口获取，对于提升代码性能，提高响应速度很有帮助。但是也有另外一个问题，比如我重复调用这个方法

await Promise.all([
  getUserById('user1'),
  getUserById('user1')
]);

这样使用，还是会调用两次接口，缓存无法命中，原因是我们缓存的是一个异步请求的响应值，当连续调用这个方法时，上一个异步请求的结果还没响应，下一个异步请求就发出去了。那该怎么解决呢？可以通过缓存Promise的方式进行解决，代码如下

const userPromisesCache = new Map<string, Promise<User>>();

const getUserById = (userId: string): Promise<User> => {
  if (!userPromisesCache.has(userId)) {
    const userPromise = request.get(`https://users-service/v1/${userId}`);
    userPromisesCache.set(userId, userPromise);
  }

  return userPromisesCache.get(userId)!;
};

我们不再是缓存异步请求的响应结果，而是直接缓存这个异步请求返回的Promise，这样处理的好处是我们不用再等待请求响应成功，当连续连续getUserById时，可以立即返回上一个已经缓存的promise，从而实现最终发送一个http请求。但这样处理还有点缺陷，就是如果上一个promise``reject了，就会导致后面的调用始终是reject，我们需要修改一下，将reject``promise从缓存中去掉，代码修改如下

const getUserById = (userId: string): Promise<User> => {
  if (!userPromisesCache.has(userId)) {
    const userPromise = request.get(`https://users-service/v1/${userId}`);
    userPromisesCache.set(userId, userPromise);
  }

  const cachePromise = userPromisesCache.get(userId)!;

  cachePromise.catch((err)=>{
    userPromisesCache.delete(userId)
  })

  return cachePromise
};

github上也有专门处理缓存相关的库，例如Memoizee，针对上述场景修改代码如下

import memoize from 'memoizee';

const getUserById = memoize(async (userId: string): Promise<User> => {
  const user = await request.get(`https://users-service/${userId}`);
  return user;
}, { promise: true});

除了缓存promise，日常工作中，对于处理比较慢的操作，例如请求、耗时长的数据处理等我们应该充分利于缓存来提升二次处理的效率。

depcheck and madge

地址

madge

depcheck

node.js调试的几种方式

第一种

1. 打开 vscode 内置终端，右上角选择 JavaScript Debug Terminal

2. 在代码里面打断点（需要断点处输入 debugger 或者 打标 Breakpoint）
3. 终端运行执行命令即可

第二种

1. mac 通过快捷键 选择 Debug: Toggle Auto Attach ，开启 Auto Attach (该方式要去 node 版本要大于 12)
2. 在代码里面打断点（需要断点处输入 debugger 或者 打标 Breakpoint）
3. 终端通过命令 node --inspect index.js 执行代码

第三种

有些时候在看一些开源库的时候，想通过断点方式查看源代码，可以通过配置 launch.json 指定运行时执行环境

比如，package.json 有 scripts

vscode 调试时 ，配置 launch.json 如下

其中，runtimeExecutable 指定运行时的执行环境 ，这里指定为 npm，runtimeArgs 指定运行时执行环境对应的执行参数，这里指定运行 run dev。

配置好之后，按 F5 开启调试，实际执行的就是 npm run dev ，这样我们就可以在源代码打断点进行查看代码的执行过程了

更多调试技巧可以查看 vscode 官网 ，地址

第四种

ndb is an improved debugging experience for Node.js, enabled by Chrome DevTools

借助 ndb ，正如它自己在官网上描述一样，ndb 提升了调试 nodejs 的体验，它是通过启用一个 Chrome Devtools 来进行调试的。

在使用它前，你需要安装，可以通过 npm install -g ndb ，安装完之后在代码里面需要断点的地方输入输入 debugger ，然后运行 ndb index.js ，会发现打开了一个 Chrome Devtools 并且已经断点

nodejs调试当然不仅仅这几种，阮老师之前也写过一篇关于 nodejs debugger 的文章，感兴趣可以点击查看 地址

前端研发生态建设的一些思考

目标

提高前端研发效率、质量与稳定性

背景

一个完整的项目开发生命周期主要包含以下三个阶段：立项、开发、发布，其中立项主要包含需求评审、技术方案评审、视觉评审；开发阶段事项较多，包含了搭建项目、使用组件开发、交互场景开发（无法使用现成组件）、埋点添加、联调、测试，以及和产品经理、运营斗智斗勇；发布阶段主要就是项目部署、发布上线、上线前的自我检测验证，保证上线的页面效果符合预期。

在和一些开发者聊过和结合自我开发经验，大概得出了一个项目开发完整生命周期内，开发者大概的时间分配。立项占比20%，开发占比70%，发布占比10%。

对症下药

结合上图，具体到提效思路就清晰了，主要解决70%的开发时间，寻找合适的方式提升这部分的开发效率。质量与稳定性这部分，不仅仅是保证项目正常运行，而且要保证项目高效运行，具体就是保证项目的运行性能，重点链路出现问题能及时监控并解决。

效率

效率提升是个千人千面的问题，不同开发者能力不同导致开发效率也不一致。但一些标准化的东西是可以通过工具的方式或者工程化的方案进行解决的。
具体到开发的各个阶段的流程节点解决方案可以如下：

搭建项目

统一的项目创建工具，例如vue-cli，create-react-app，项目初始化完成之后就包括了项目的开发、调试、测试、部署等相关的工具库和环境配置，开发者可以直接开始业务开发

使用组件开发

“组件”是一种通俗的叫法，大公司一般喜欢称之为“物料或者资产”，具体主要包含以下几类：

• 基础组件和库，例如 antd / vant / vui / spider / login / pecker
• 业务组件，基于基础组件和实际业务场景封装的组件
• 代码片段，可以直接拿来急用的代码，例如一个动画的实现，一种特定交互场景的实现，和业务组件最大的不同就是，代码片段一般通过拷贝进行使用，可以直接在原有代码上进行修改，不依赖于代码片段的升级
• 页面，由组件、代码片段组合成的特定通用型页面，例如空页面、404页面、个人信息页、设置页等等

承载组件的一般都是通过 npm 或者 在线 ide 等方式达到复用目的

交互场景开发

交互场景指的就是实际业务开发过程中的一些具体业务场景，例如CRUD / 分页 / 上拉加载、下拉刷新 / 回到顶部 等等，这种可以通过封装成通用的工具方法或者 hooks 进行实现

引用自蚂蚁前端研发最佳实践

添加埋点

埋点就是需要收集页面访问的一些日志信息，一般有无埋点和手动埋点，这里不讨论那种埋点方式更好，就拿我公司举例，采用的是通过在业务代码里面添加特定的采集脚本进行手动埋点的方式，对一些需要日志种类非常多的页面，添加埋点也是耗费开发者时间的一环，结合社区的一些方案可以通过例如可视化埋点、自动分析dom结构自动埋点等方式解决

联调

和服务端进行联调，好的开发方式是技术方案评审完之后，由服务端根据需求编写接口文档，前端在开发阶段就可以通过本地mock进行测试，待服务端开发完之后切换到正式的环境进行联调测试，但其中接口文档容易变动，很多时候服务端来不及去更新接口文档，导致实际联调的时候会花费很大精力去核对字段或者修改已写好的业务逻辑。由于nodejs的蓬勃发展，现在一些大厂会将一些通用的数据服务封装成函数（serverless）前端开发者可以直接调用，这样就直接省去了服务端编写文档、频繁开发、重复性开发等问题。然而面对一些非通用性的服务还是需要开发的，这部分可以考虑通过mock平台来承载前端mock以及服务端生成api和文档的方式。

和产品、运营斗智斗勇

这个环节，我觉得一句话：“合理的需求尽量满足，不合理或者有非议需求尽量拒绝，实在不行缴械投降”

测试

在充分理解业务需求以及统一的视觉、交互规范之后，搭配上丰富的组件市场，我相信你写出的代码bug率肯定会下降

上下游的链路打通

从生成-消费的角度看，前端开发、设计都是既属于生成者又属于消费者，前端开发拿到设计输出的视觉稿，如果能有现成的组件可以复用，生产的提效是显而易见的，同时设计师也得知道前端开发都有哪些组件，能否从现有组件进行设计对于满足前端开发使用也是至关重要的。因而，打通开发的上下游也很关键

质量与稳定性

项目的开发质量高不高，首先要保证项目功能都能够正常运行，其次再考虑编码规范、类库组件的使用规范等，常用的方式有在项目脚手架里面统一 eslint / tslint 的配置 ，统一常用的类库组件等，还可以考虑在部署发布前进行预检测，例如 前置检测平台 可以在部署前就能发现一些业务代码中的错误以及编码是否规范等，另外，上线之后通过全链路的监控平台对业务中的一些关键节点建立告警监控等

最佳实践

可以看到在整个生命周期内流程节点特别多，尤其期开发阶段的每个节点都能牵扯出各种各样的方案，那如何找到最适合自己团队的实践方案呢？总的来讲，不外乎就是自研还是利用社区成熟方案的问题。
自研的话成本相对较高，但后期维护、定期、扩展性更强；而利用开源方案的话就是成本较低、上手快、但个性化定制、是否贴合团队业务等方面就有所不足，所以一般团队都是采用两种结合的方式，感兴趣的话可以看下蚂蚁前端研发最佳实践这篇文章。这里就不展开探讨了

参考资料

蚂蚁前端研发最佳实践
前端框架体系建设
揭秘：让阿里前端提效 50% 是如何计算的 ？