当使用HTTP请求中的Authorization头时，表示传入的是认证信息。具体的认证类型由凭证前缀指明。以下是Authorization头中常见的几种认证机制：

以上的使用的scheme，如Basic，Bearer,Digest,ApiKey是约定俗成的，大家都这样使用，具体认证类型取决于服务器的要求和实现的协议，针对自己的业务也可以自定义scheme。也可以参考正在与之交互的服务或API的文档，以确定Authorization头的正确格式。

背景

cron service 在执行定时任务时，需要能够实时查看该任务的执行日志以确保程序正确的工作。为了能够在尽可能短的时间内实现该功能，我们需要一个足够简单的方案。

方案如何选择？

我相信大多数开发者第一个想到的就是 WebSocket ，然后是 HTTP/SSE 。WebSocket 在很多情况下是实至名归的万金油选择。但这这里他太重了，对服务端和客户端具有侵入性需要花费额外的时间来集成到项目中。

那么 SSE 呢，为什么不是他？
虽然 SSE 即轻量又实时，但 SSE 无法设置请求头。这导致无法使用缓存和通过请求头设置的 Token。而且作为长链接他还一直占用并发额度。

• WebSocket：❌
  
  
  
  • 优势：
    
    
    
    • 实时性高
    
    
    • 不会占用 HTTP 并发额度
    
    
    
    
  
  
  • 劣势：
    
    
    
    • 复杂度较高，需要在客户端和服务器端都进行特殊的处理
    
    
    • 消耗更多的服务器资源。
    
    
    
    
  
  
  
  


• SSE(Server-Sent Events)：❌
  
  
  
  • 优势：
    
    
    
    • 基于HTTP协议，不需要在服务端和客户端做额外的处理
    
    
    • 实时性高
    
    
    
    
  
  
  • 劣势：
    
    
    
    • 无法设置请求头
    
    
    • 占用 HTTP 并发额度
    
    
    
    
  
  
  
  


• HTTP：✅
  
  
  
  • 优势：
    
    
    
    • 简单易用，不需要在服务端和客户端做额外的处理。
    
    
    • 支持的功能丰富，如缓存，压缩，认证等功能。
    
    
    
    
  
  
  • 劣势：
    
    
    
    • 实时性差，取决于轮询时间间隔。
    
    
    • 每次HTTP请求都需要建立新的连接（仅针对 HTTP/0.x 而言）并可能阻塞同源的其他请求而导致性能问题。¹²
      
      
      
      • HTTP/1.x 支持持久连接以避免每次请求都重新建立 TCP 连接，但数据通信是串行的。
      
      
      • HTTP/2.x 支持持久连接且支持并行的数据通信。
      
      
      
      
    
    
    
    
  
  
  
  

以上列出的优缺点是仅对于本文所讨论的场景（即Web 端的实时日志）而言，这三种数据交互技术在其他场景中的优缺点不在本文讨论范围内。

实现

HTTP 轮询已经是老熟人了，不再做介绍。本文的着重于实时日志的实现及优化。

sequenceDiagram



participant 浏览器



participant 服务器



Note right of 浏览器: 首先，获取日志文件最后 X bytes 的内容



浏览器->>服务器: 最新的日志文件有多大？



服务器->>浏览器: 日志文件大小: Y bytes



浏览器->>服务器: 从 Y - X bytes 处返回内容



服务器->>浏览器: 日志文件大小: Y1 bytes, 日志内容: XXXX



  



loop 持续轮询获取最新的日志



浏览器->>服务器: 从 Y1 bytes 处返回内容



服务器->>浏览器: 日志文件大小: Y2 bytes, 日志内容: XXXX



end

上方是基本工作原理的流程图。
实现的关键点在于

• 前端如何知道日志文件当前的大小


• 服务端如何从指定位置获取日志文件内容

这两点都可以通过 HTTP Header 来解决。Content-Range HTTP 响应头会包含完整文件的大小，而 Range HTTP 请求头可以指示服务器返回指定位置的文件内容。

因此在服务端不需要额外的逻辑，仅通过 Web 端代码就可以实现实时日志功能。

代码实现

篇幅限制，代码不会处理异常情况

首先，根据上述流程图。我们需要获取日志文件的大小。

const res = await fetch(URL, {  

  method: "GET",  

  headers: {  Range: "bytes=0-0"  }

});



const contentRange = res.headers.get("Content-Range") || "";  

const match = /bytes (\d+)-(\d+)\/(\d+)/.exec(contentRange);  



// 日志文件大小

const total = Number.parseInt(match[3], 10);

Range: "bytes=0-0" 指定仅获取第一个字节的内容，以免较大的日志文件导致响应时间过长。

我们发起了一个 GET 请求并将 Range 请求头设置为 bytes=0-0 如果服务器能够正确处理 Range 请求头，响应中将包含一个 Content-Range 列其中将包含日志文件的完整大小，可以通过正则解析拿到。

现在我们已经拿到了日志文件的大小并存储在名为 total 的变量中。然后根据 total 获取到最后 10 KB 的日志内容。

const res = await fetch(url, {  

  method: "GET",  

  headers: {  

    Range: `bytes=${total - 1000 * 10}-`

  }

});



const contentRange = res.headers.get("Content-Range") || "";

const match = /bytes (\d+)-(\d+)\/(\d+)/.exec(contentRange);



// 下一次请求的起始位置

const start = Number.parseInt(match[2], 10) + 1;



// 日志内容

const content = await res.text();

现在我们发起了一个 GET 请求并将 Range 请求头设置为 bytes=${total - 1000 * 10}- 以获取最后 10 KB 的日志内容。并且通过正则解析拿到了下一次请求的起始位置。

现在我们已经拿到了日志文件的大小和最后 10 KB 的日志内容。接下来就是持续轮询去获取最新的日志。轮询代码区别仅在于将 Range 标头设置为 bytes=${start}- 以便获取最新的日志。

const res = await fetch(url, {  

  method: "GET",  

  headers: {  

    Range: `bytes=${start}-`

  }

});



const contentRange = res.headers.get("Content-Range") || "";

const match = /bytes (\d+)-(\d+)\/(\d+)/.exec(contentRange);



// 下一次请求的起始位置

start = Number.parseInt(match[2], 10) + 1;



// 日志内容

const content = await res.text();

以上，基本的功能已经实现了。日志内容保存在名为 content 的变量中。

优化

HTTP 轮询常因其高延迟为人诟病，我们可以通过指数退避的方式来尽可能的降低延时且不会显著的增加服务器负担。

指数退避是一种常见的网络重试策略，它会在每次重试时将等待时间乘以一个固定的倍数。这样做的好处是，当网络出现问题时，重试的时间间隔会逐渐增加，直到达到最大值。

一个简单的实现如下：

/**

 * 使用指数退避策略获取日志.

 */

export class ExponentialBackoff {

  private readonly base: number;

  private readonly max: number;

  private readonly factor: number;

  private retries: number;



  /**

   * @param base 基础延迟时间 默认 1000ms (1秒)

   * @param max 最大延迟时间 默认 60000ms (1分钟)

   * @param factor 延迟时间增长因子 默认 2

   */

  constructor(base: number = 1000, max: number = 60000, factor: number = 2) {

    this.base = base;

    this.max = max;

    this.factor = factor;

    this.retries = 0;

  }



	/**

	 * 获取下一次重试的延迟时间.

	 */

	next() {

    const delay = Math.min(this.base * Math.pow(this.factor, this.retries), this.max);

    this.retries++;

    return delay;

  }



  /**

	 * 重置重试次数.

	 */

  reset() {

    this.retries = 0;

  }

}

值得一提的是带有 Range 标头的请求成功时会返回 206 Partial Content 状态码。而在请求的范围超出文件大小时会返回 416 Range Not Satisfiable 状态码。我们可以通过这两个状态码来判断请求是否成功。

成功时调用 reset 方法重置重试次数，失败时调用 next 方法获取下一次重试的延迟时间。

总结

即使再优秀的方案也不是银弹，真正合适的方案需要考虑的不仅仅是技术本身，还有业务场景，团队技术栈，团队技术水平等等。在选择技术方案时，我们需要权衡各种因素，而不是盲目的选择最流行的技术。

当我们责备现有的技术方案为何如此糟糕时，或许在那个时间点上，这个方案是最合适的。

感谢以下网友的帮助和建议：齐洛格德

Footnotes

大家好，我是云舒编程。

马斯克接手Twitter的一年后，在10.27其官方团队发布了一条推文展示这一年的工程成果。

有点国内那味了，论工作量化的重要性。

这一年里，我们在工程技术上取得了许多出色的成就，除了大家在应用中看到的明显变化之外，在幕后我们还做了一系列重要的优化和改进。

• 将「为你推荐」、「关注」、「搜索」、「个人主页」、「列表」、「社区」和「探索」等功能的技术栈整合到了一个统一的产品框架中。


• 彻底重建了「为你推荐」的服务和排名系统，代码行数从700K减少到70k，减少了90%；同时计算资源减少了50%，处理相同请求的能力提升了80%。


• 统一了「为你推荐」和视频的个性化、排名模型，显著提高了视频推荐质量。


• 重构了API中间层的架构，删除了超过10万行代码和数千个未使用的内部废弃接口，同时删除了一些没人用的客户端服务。


• 将获取帖子元数据的时间减半，全局API超时错误减少90%。


• 对外部机器人、爬虫的屏蔽，相比2022年，增长了37%。平均每天，阻止了超过100万次机器人注册，并将私信中的无用信息减少了95%。


• 关闭了位于萨克拉门托的数据中心，重新调配了5200台机架和148000台服务器，每年为公司节约了超1亿美元，总的来说，节约了48兆瓦的电量，60000磅的网络机架。


• 优化了对云服务厂商的使用，开始在本地进行更多的工作，这一转变使得每月的云服务成本降低60%，同时我们还将所有的媒体和大文件从云端迁出，减少了60%的云端存储空间，除此之外，还成功将云数据处理成本减少了75%。


• 构建本地GPU超级计算集群，并设计、交付了43.2Tbps 的高性能网络架构。


• 提升网络主干的容量和冗余性，每年节省1390万美元。


• 开展了自动化峰值流量故障转移测试，以持续验证平台的可扩展性和可用性。

一、前言

在我们面试过程中，面试官经常会提及到深浅拷贝的问题。想必大多数小伙伴会说到JSON.parse(JSON.stringify(obj))。正好今天我就和大家好好唠一唠这个JSON.stringify。

二、概念

JSON.stringify对于我们不陌生，一般用来处理序列化（深拷贝）。就是把我们的对象转换为JSON字符串，此方法确实很方便在我们的工作中，但是，这个方法也会有一些弊端，只是我们不怎么遇到。

let obj = {

    name: 'iyongbao'

}



console.log(JSON.stringify(obj)); // {"name":"iyongbao"}

三、弊端

1. 对函数不友好

如果我们的对象属性是一个函数，那么在序列化的时候该属性会丢失。

let obj = {

    name: 'iyongbao',

    foo: function () {

        console.log(`${ this.name }是一个小菜鸟！`)

    }

}



console.log(JSON.stringify(obj)); // {"name":"iyongbao"}

2. 对undefined不友好

如果对象的属性值是undefined，转换后会丢失。

let obj = {

    name: undefined

}



console.log(JSON.stringify(obj)); // {}

3. 对正则表达式不友好

如果对象的属性是一个正则表达式，转换后就会变成一个空的Object

let obj = {

    name: 'iyongbao',

    zoo: /^i/ig,

    foo: function () {

        console.log(`${ this.name }是一个小菜鸟！`)

    }

}



console.log(JSON.stringify(obj)); // {"name":"iyongbao","zoo":{}}

4. 数组对象

如果是一个数组对象，以上的情况也会发生。

let arr = [

    {

        name: undefined

    }

]



console.log(JSON.stringify(arr)); // [{}]

四、JSON.stringify拓展

说完了JSON.stringify的不足，下面我们来说一下你可能没有接触过的其他特性，希望看完会对你有所帮助。

1. 接收一个数组（过滤）

其实JSON.stringify有第二个参数，可能我们不经常用到。我们可以传入一个数组，值就是对应我们对象的key，我称之为过滤。

let obj = {

    name: 'iyongbao',

    age: 25,

    hobby: ['JavaScript', 'Vue']

}



let res = JSON.stringify(obj, ['name']);



console.log(res); // {"name":"iyongbao"}

2. 接收一个函数

第二个参数也可以是一个函数，也是类似过滤的效果。

let obj = {

    name: 'iyongbao',

    age: 25,

    hobby: ['JavaScript', 'Vue']

}



let res = JSON.stringify(obj, (key, value) => {

    if (key === 'age') return undefined;

    return value;

});



console.log(res); // {"name":"iyongbao","hobby":["JavaScript","Vue"]}

3. 缩进

第三个参数可以接收一个数字，表示缩进多少字符。

let obj = {

    name: 'iyongbao',

    age: 25,

    hobby: ['JavaScript', 'Vue']

}



let res = JSON.stringify(obj, null, 2);



console.log(res);

4. 自身toJSON方法

对象可以有一个自身的toJSON属性，是一个有返回值的方法，用来输出我们自定义的数据样式。

let obj = {

    name: 'iyongbao',

    age: 25,

    toJSON: function () {

        return {

            message: `${ this.name }的年龄为${ this.age }`

        }

    }

}



let res = JSON.stringify(obj);



console.log(res); // {"message":"iyongbao的年龄为25"}

五、总结

好了，今天就和大家分享到这吧。一般如果真涉及到深拷贝，我还是首选自己封装一个方法或者是使用第三方的插件库来做深拷贝，这样最保险，避免不必要的麻烦。

大概是我刚上小学时候，村子里流行起来出门打工，每个家庭里面的壮年男人都会去湖北挖桩，组团去。他们过完年出发，先走路下山，坐车再坐船。

出门一段时间后，他们会寄钱回家，那时寄钱的方式我不清楚也还从没有问过，只记得家里女人们听到对门肉嗓子大喊“xxx，来拿汇票”时，她们是很开心的。

快过年，男人们从外面回家，背着或挑着大件的行李，行李中是破旧的棉穗，小孩的新衣与不常见的水果糖。

挖桩需要两个人配合，一人在井里往下挖，一人在上面接桶转移土石，隔一段时间换人。有想法的男人认为他可以一直待在井里，女人提桶倒土是完全没有问题的，如果与自己的女人组团，工钱不用与别人分，挣钱的速度便会快上一倍。

于是，到我上初中时候，出门打工的规模更加扩大，家中的男人女人一起出门，小孩交给父母带着。

男人女人外出打工的时间是一样的，过完年出门，快过年时回家。

男人女人年龄渐长，他们的小孩长成大人，成人都外出打工，过完年出门，快过年时回家。

男人女人与小孩的目的地并不相同。于是过年，成为一家团圆的日子。

家家张灯结彩，人人喜笑颜开。

初一的早餐，是可以很简单的，汤圆或是包面；也可以是复杂的，蒸米饭，炸鱼、牛肉干、猪耳朵、凉拌鸡脚等许多凉菜，昨天的猪脚炖鸡汤，再配几个新鲜炒菜，满满一桌。复杂与简单的差异，来自于当天行程的安排，马上要走亲戚就简单些，家中要来客人便复杂点。

午饭，必然是丰盛的，一锅必不可少的鲜炖的猪脚炖鸡汤（是的，猪脚与鸡年三十只炖四分之一，留着客人来后能炖新的猪脚汤），一盆小孩儿最是欢迎的洋芋片，一锅人人喜爱的猪头汤清炖萝卜，两盘肥腻多汁男人们热衷的辣椒炒三线儿，一盘香肠、两碗扣肉，再来一盘炸豆腐……凉菜有猪肝、猪耳朵、鸡脚、炸鱼、牛肉干、萝卜干儿、折耳根……炒一个青菜，或是再加一碗青菜猪血汤。

男人们大都是会喝点酒的，他们互相劝着，你敬我一口酒，我回你两句话：“这酒好甜啊！”女人们偶尔也喝些酒，但更多是和小孩一起喝饮料。主妇是最后上桌吃饭的，大家吃饭时，她为桌上换热汤，为客人盛热饭。

吃过午饭，晒晒太阳烤烤火，嗑嗑瓜子吹吹牛。客人准备回家，临出发告诫主人：“你们明天一定要来啊，都要来。”

初二初三初四初五初六，是初一的重复。

隔得近，午饭的重复便是晚饭。吃过晚饭，今日不用再做饭，男人女人们围着炉子说过去说现在，说去年说当下，那“哈哈”大笑声，是时常能传到地坝的。

地坝里，孩子们的游戏一个接一个的切换。老鹰抓小鸡、三个字（一个人追众人跑，快被抓到时喊出随便的三个字，被抓者定住等待救援，抓人者切换目标；待所有人都被定住，便问“桃花开了没？”）、跳绳、打沙包……四岁五岁的，大多数游戏还玩不太明白，但他们的参与感该是最强的，因为哥哥姐姐叔叔阿姨都护着他们。

地坝里的叽叽喳喳，盖过屋子里哈哈哈哈。

年，是团圆！

大家好，我是老三，大家新年好，我在朋友圈看到有朋友已经在大张旗鼓地“内卷”，为年后的面试做准备。

成功的面试常常是源于实力+运气，失败的面试可能会有各种各样的原因，知识点的盲区、和面试官不对眼、经验不匹配……很多东西我们是没法控制的，只能尽量做好自己能做的——八股更熟一点、算法多刷一刷，硬技能相关的暂且不多聊，我们今天聊一聊，心态相关的，哪些心态，是求职面试中最好不要有的。

我得找个特别完美的工作

“钱多事少干的爽”，几乎是所有打工人的终极梦想，但是回归现实，真有这样的工作，凭什么流转到普通人身上呢？

有人可能会说，某某在XX公司，你看干的轻松，年终还发的贼多，真爽啊。这其实可以算幸存者偏差，我们有时候只能看到经过某种筛选而产生的结果，比如今年微信视频发了十几个月的年终，一度在各个公众号刷屏——我们可能觉得微信给的钱真多啊！但其实想想，哪怕同属WXG，除了微信视频，其它的部门也有这么“钱多”吗？

“钱多”、“事少”、“干的爽”，三者里面能满足一个就很不错了，钱多一般事也多，事少一般钱也少，”干的爽“更是一个非常主观的因素，自己不去干一干真不知道，干了也可以调整。

老三经历了几次跳槽，找工作的心理预期没那么高，为什么呢？我过去的工作经历基本上从低位到高位跳的一个过程，但是有的同学比较优秀，可能一出道就是在高位，刚工作就是大厂SSP。

这些有实力的同学，也许也会面临一个幸福的烦恼，就像谈恋爱，如果一个女生的初恋特别优秀，她后面可能会单身很久，因为她发现很难找到比初恋更优秀的男朋友。“曾经沧海难为水，除却巫山不是云”。

经济学上有一个“锚定效应”：

人们需要对某个事件做定量估测时，会将某些特定数值作为起始值，起始值像锚一样制约着估测值。在做决策的时候，会不自觉地给予最初获得的信息过多的重视。

有这么好的“初恋”，一般他们都不会轻易“分手”，但是假如遇到了一些波动，主观或者客观的原因，导致“分手”，那么在找下一份工作的时候，可能需要正视“锚定”的因素。

我们找工作的时候，也会去“锚定”，和现在的工作去比，和其它人的工作去比，但其实，相比评估价值，可能找准自己的需求更加重要，钱多、发展、职级、大厂背书、业务匹配、稳定、工作生活平衡 ……可以像排工作任务一样，排一下需求的优先级，哪些是必须的，哪些是可以妥协的。

找工作也和找对象类似，我有一个哥们，特别喜欢古力娜扎，可能很多人的女神也是迪丽热巴、古力娜扎、马尔扎哈……但是应该没有普通人会把自己找对象的目标定在这些女神头上。这就涉及到“吸引力”和“可得性”的平衡，很多时候，一份好的工作，对我们的“吸引力”是巨大的，但是我们也不得不承认它的“可得性”是极低的。

外包，是互联网软件行业一个比较普遍，而且越来越普遍的用工方式，有的朋友在外包——“你为什么要做外包呢？”，我觉得一般人也不会问这个问题，这就像之前有个主持人：“为什么不吃肉呢？因为肉不好吃吗？”生活所迫嘛，我们很多时候，只是在可选的选择里选一个相对最优的。

尤其是在现在整体行情不景气，如果真的没有办法，比如空窗了很久，妥协也是可以接受的，华为进不去OD也能凑合。

在经济学上，资源的配置常常达不到最优，找工作也是一样，能在一定可达性的基础上，通过努力获取次优的选择，已经很不错了。

“幻想不是理想”，这个世界上少有完美的工作，也少有完美的人生，我们很多时候，都要接受这些不完美，做一些适当的取舍。

留下还是跑路，好纠结

45度的人生最难受。

我去年经历了很纠结的时刻，当时的工作满足不了我的需求，但是我又不敢跑路，因为市场的寒气实在让人望而却步，就在这种纠结中，我错过了最好的面试备战和简历投递的时机，当时的第一目标快手，等我十月份觉得可以面一面的时候，HC已经锁了一个月了。

最怕的就是这种纠结的心态，工作投入不进去，面试也准备不好。还是那句话，找准现在的问题和需求。

第一，我现在的工作是不是已经非常让我难以接受了？有哪些点让我难以接受？是客观的原因还是主观的原因？我有没有尝试最大的努力去解决？我有没有寻求别人的帮助？

第二，现在这份工作的问题解决不了，我能通过跳槽解决吗？是不是换一个公司，换一个环境，就能解决或者缓解我的问题？什么样的公司能解决或者缓解我的问题？这样的公司对我的可得性大概有多少？

想清楚这两点，就能确认自己离开的意向，留下就好好干，努力去解决问题；要走就做好规划，挤出时间准备。

第三，工作和面试，不是绝对冲突的。只要有想离开的想法，再忙每天也能抽点时间出来准备的，把刷抖音，打游戏的时间拿一部分出来准备面试，做好规划，每天时间充足就拉短周期，每天时间少就拉长周期。

其实很多的时候的纠结，只是给自己找放纵的借口，“其实，我不是特别想走”，“外面现在行情很差，没什么机会”，这样一来，就可以心安理得地玩游戏、刷抖音，至于面试准备，后面再说吧。

我也经历了这样当鸵鸟的时期，直到一些关系比较好的同事因为各种原因离开，再加上一些裁员的传言，才彻底打醒了我。

打破纠结的最好办法就是行动，最怕的就是找个借口，让自己停在了原地。

这个面试没啥，随便面面

面试有自信是一件好事，比如老三，可能会觉得自己的八股比较熟；有的朋友，可能会觉得，自己的算法比较溜；有的觉得自己的项目比较亮眼。

自信，不是轻敌。我有个朋友吃了这样的亏，面飞猪的时候，随便约了个时间，当时那个时间是在旅行中，感觉的时候觉得很简单，结果挂了，事后一问，面试官说根本听不清；后面他面快手，也吃了同样的亏，因为没怎么准备，一面挂在了自己最擅长的算法上。

同样，面试，难和简单，也是一个很主观的感觉，别人感觉简单的，自己未必简单，还是那个朋友，他面飞猪，相对简单，我面飞猪，写了两道题，几乎问到了所有知识点的八股，足足面了九十多分钟。

认真对待每一场面试，现在这个环境，每一个机会都是非常难得的，很多面试机会，错过了就不再有。每一场面试，都尽量拿比较好的状态去面。

有的人说，我不咋想去，只是练手，练手也要认真一点，就像模拟考，也得好好考。而且现在不想去，可能只是了解不多，后面如果了解多了，未必不是完全不想去。

完全准备好了再面

面试，永远没有完全准备好的时候。很多时候，觉得准备个七八成的时候，就可以去面了。

第一，很多岗位的窗口期是很短的，在现在这种僧多粥少的局面下，一个岗位可能很短的时间就关闭了，如果不及时地去面，可能就会失去这个机会。

第二，面试永远会有答不上来的问题，面试本身就是个非对称的场景，以面试官之长，攻己之短，面试，也有一些运气的成分在里面。

第三，准备六个月，未必效果比三个月好，人的投入，是有边际递减的效应的，短时间高效率的准备，也许比拉长战线更有效果。

机会来了，估计着差不多就冲，我有个同事，很短的时间准备，但是因为年底的机会很好，也认真地准备了，一年多的经验，拿下了美团和京东的Offer。

我和面试官是对立的

面试是一场交流，一头是面试官，一头是候选人，有这么一个段子，面试是”三分天注定，七分靠打拼，九十分看面试官心情“，我和这样一个能一票否决我的人，我应该怎么打交道呢？

对立情绪是不可取的，在考试这个逻辑的下面，其实我们和面试官还有合作的逻辑。我以前作为面试官，面了几十个人，面到后面，我的感受是什么呢？赶紧招一个合适的人选吧，别让我面试了。

在这种关系里，面试官也是有需求的，面试官希望尽快招到合适的人，让自己早点摆脱面试对自己的干扰。面试官也是有投入的，毕竟面试的时间，基本都不会算进工作排期。

既然双方都有需求和投入，当然候选人的需求和投入会更多，那么这段关系就不是完全从上到下俯视的，我觉得最好的面对面试官的心态，就是萍水相逢的路人，尊重但不谄媚、存异但是和谐、热情但有边界，如果有缘份的话，我们可能会成为真正的朋友，如果没有缘分那就相忘江湖。

很多人说，程序员都不太擅长交流，但至少请保持礼貌，“您好”，“谢谢”，“不好意思”，“感谢你的时间”，我觉得这些礼貌用语，应该小孩子都会吧。

面试，不仅有硬实力的碰撞，也有人情世故的交融。

面试官让我不爽

我在之前，某个博主的文章里，看到他在某个公司的三面挂了，因为感觉和面试官不太对味。根据我的经验，其实三面很少挂人，这种，就是和面试官的”碰撞“激烈了一些。

我们应该明白一个道理：在面试的流程中，我们是没有挑选的权利的，只有拿到Offer后，我们才是真正有挑选的权利。

这个世界我们不认同的东西多了，要么改变它，要么适应它，这句话不太好听，既然选择了打工，那大概率是只能适应的。

面试里，面试官说的东西，我们可能不认同，面试官的态度甚至可能不友好，我觉得我们能做的，就是保持礼貌：

“对对，你是对的。”

我去年面西二旗某厂，三面面试官给我的感觉是无知且蛮横，她的很多问题都让我无言以对，但是我还是全程保持了微笑，努力保持了风度，没想到最后面试过了。

如果你真的看面试官不爽，在Offer后拒绝他们，不比在面试阶段，闹得不欢而散，最后只能心里默默骂着傻叉要痛快？

面的不好，放弃吧

面试永远有我们不会的问题，这是正常的。可能在某个问题卡壳之后，心态就慢慢崩掉，破罐子破摔。这时候，一定要给自己一些积极的心理暗示，面试直接发生在面试官和候选人之间，间接发生在候选人和候选人之间。

“我这种八股文职业选手都答不好，其他人更不行了。”

而且，答的不好，未必就是没戏，很多时候，面试官可能通过一些开放性的问题或者压力面的方式，考察候选人的广度深度，思维方式。

所以，哪怕偶有一个点答不好，也一定要绷住心态，我之前作为面试官，面试实习生，一个候选人，坦白说，她面的不好，同事的实习生，他觉得可以，那就通过吧，结果告知她面试通过后，那个候选人心态崩了，放弃了后面的面试。

最差不过挂了，最坏的结果都能接受，那就朝最好的方向尝试努力。

失败了好几次，没信心了

我们经常在网上，刷到一些“Offer收割机”“吊打面试官”，但是经过我本人的实践，反正我是做不到，比如美团，我面了四个岗位才拿到Offer。

面试失败，是一件很正常的事情，“面了不一定能过，过了不一定能Offer”，我们可能因为各种原因挂掉。但是，千万不能因为失败几次，就灰心丧气，面一次总结一次，查缺补漏，面的多了，自然会面了，就能面过了。

而且面试也有运气的成分，此路不通，未必别路也不通。

很多人恐惧面试，其实我也怕面试，每次面试前，都很忐忑，但是想一想，最差不过挂了，越淡定的面试发挥地越好，越紧张的面试发挥地越差。

在挫折里不断进步，保持心态，才有机会拿到好的结果。

​

​

工作是为了更好地生活，生活是为了快乐和幸福，每个人的快乐和幸福都是自己定义的，祝大家既能找到好的工作，也能享受生活的快乐和幸福。

​

​

参考：

[1].《长的好看，能当饭吃吗：提升认知的33个经济学常识》

[2].《经济学原理》

​

​

最近两年我不知道你是否和我拥有同样的感受，编程容易了许多，同时乐趣也少了许多

一

最近有两个契机让我写这篇文章，一是过去一年我陆续把我所有 side project 后端从 Azure App Service 迁移到 Digital Ocean（以下简称 DC） 的 Droplet（Virtual Machine），再迁移到 DC 的 K8S，目的是剥离应用内托管型（managed）资源；前端顺便也从 Azure Static Web Apps 迁移到 Vercel；二是最近读完《Competing in the Age of AI》，其中关于于 operation model 的论述与近期迁移应用的感受不谋而合

书中把公司价值划分为两部分，首先是商业模型（business model），即为消费者带来了何种价值；其次是运营模型（operation model），即如何将价值传递到消费者手中。运营的难点不在交付本身，而在于如何大规模（scale）、大范围（scope）交付，并且持续对交付方法改进和创新（learning）

同样，如果代码的价值在于上线（通俗说派上用场），无论是对自己还是客户还是用户，那么交付对我们来说同样重要，以上所说的大规模、大范围、以及保证持续改进的交付难点也同样成立。

先上线，剩下的以后再说

二

你们有没有想过 Netlify 和 Vercel 究竟是做什么生意的？如果你的答案依然是 JAM stack，只能说明你已经 out 了。不妨去看看 Netlify 官网的 slogan，甚至不用是 slogan，看看网站首页的 title 写的是什么：

Scale & Ship Faster with a Composable Web Architecture

Netlify 所做的正如上述所标榜的，帮助代码更快的交付上线。换而言之，它们售卖的的是一站式 web 应用的部署解决方案，除 host 和流水线外，还提供免费的用户行为分析、页面性能监控、日志等工具，以及 Redis/SQL/Blob 数据库。

Azure 不是也提供类似的服务吗？问题的关键在于不同平台间的开发者体验，Vercel 能够真正做到上述服务一键集成，你会明显感觉到 Vercel 在加速你的交付，让你更快得到对于产品的反馈。而在 Azure 下开发更像是赤裸裸的买卖，Azure 团队按照他们的理解提供一个最低限度可以使用产品，至于多好用，多大程度能和其它 Azure 服务契合则不在他们的考虑范围内。如下图所示在 Vercel 的 dashboard 上，你可以纵览所有从部署状态到线上监测一系列信息。试想一下如果在 Azure 上集成所有对应的功能并呈现类似的 dashboard 需要付出多少外的精力

三

再简单聊聊 DevSpace。这里的 DevSpace，也可以是 tilt，可以是 skaffold、telepresence

GitOps 无疑是伟大的，但这种伟大里依然充满了“一板一眼”——我的一次上线需要经过 push 代码、创建 release、推送镜像到GHCR、更新 yaml、通过 ArgoCD 部署。我理解它们是 necessay evil。

相比之下 DevSpace 看上去是反流程的，它可以帮助你在本地直接创建镜像并执行部署，还允许热更新容器内文件。即便是创建镜像，我发现它利用也非是既有的 pipeline，而是借助 buildkit 在我的集群上创建一个 local registry 并将镜像储存在此。

别搞糊涂了，生产环境和开发环境具有完全相反的气质，我们希望生产环境稳定、可追溯，这是 GitOps 的优势所在，但开发过程具有破坏性、需要不停试错，DevSpace 着重解决的则是开发体验问题，对于代码修改它可以带来高效的反馈。

上图已经流传了很多年，图中的 compiling 可以替换成 uploading, deploying，running test 等等。过去十年它是事实，现在应该只是一个笑话

四

在 Vercel 和 DevSapce上我们看到了一类区别于传统的开发方式，这里没有 pipeline，没有 IaC，没有手动的统计埋点，无需申请第三方资源，从 GitHub 上导入 repo 的那一刻起，它自动为你匹配部署脚本，寻找项目入口。开发者所需要做的，就是专心编写他所需要的业务代码

模板化的项目是带来这些便利的主要原因，继续往上追溯，主流前端框架自带 CLI 工具的流行功不可没，从大到创建一个新项目小到执行编译，命令行一键即可完成。无论是 React，Vue 还是 Angular，你都不会在官方的教程里找到专门的章节教你为项目编写 webpack 或者 vite 的配置。也许是因为习惯了早年间凡事都需要自己动手的工作方式，我花了很长时间才想通并接受这件事：传统从0到1搭建项目的能力已不再重要。

越来越多的环节像一个个黑盒出现在开发流程中，在此之前如果我对 pipeline 感兴趣，我可以阅读 .github 文件夹中的代码看 action 是如何定义的，而现在我连机会都没有了。连同代码被一同干掉的还有程序员的编程乐趣。站在交付的角度上来说这种乐趣并没有什么道理：为什么我要花上几天的时间只为了研究如何写一段 yaml 把代码送上线运行，更何况这段代码带来不了任何产品收益。

最近另一个类似的体验是，Next.js 编写起来太无趣了，不是说它不够好，而是问题在于它太好到你只能这么写。说起来有些贱，我很怀念那个一种功能有十几个写法，然后这十几个写法还有鄙视链的“坏”时光

当我们再度审视代码的生命周期，你会发现所有人努力的目标，是想让程序员尽可能少的关心核心业务代码以外的事情。一切一切都在想方设法优化运营模型。很明显个性化配置和重复劳动在规模化前是不受欢迎的

五

也许换个思路会好受一些：当你加入一家公司之后，发现同等体量的应用利用市面上的工具可以做到随时上线；而你们的产品却只能选择在每个周六凌晨部署，并需要若干人值班守候，这听上去让人有些失望是不是。

Nicholas C. Zakas 是全世界最著名的 JavaScript 程序员之一。

今天突然看到大神在13年写的一篇长文，回顾自己的职业生涯，提到七个对他来说最重要的建议

个人觉得每一条都很受益；所以决定翻写出来；做一个学习记录。

一、Don’t be a short-order cook 不要做一个点菜厨师

你要别人点什么；你就做什么。积极表达自己的见解

我的第一份工作持续了8个月，因为公司倒闭了。当我和我的经理谈论我下一步该怎么做时，他给了我这样的建议：

尼古拉斯，你的价值不仅仅在于你的代码。无论你的下一个工作是什么，一定要确保你不是一个按需制作的厨师。不要接受那种你被告知要构建什么以及如何构建的工作。你需要在一个既欣赏你对产品的见解，又欣赏你构建能力的地方工作。

这是我在整个职业生涯中一直牢记的事情。仅仅做一个实现者是不够的--你需要参与到实现的过程中。优秀的工程师不只是服从命令，他们会给产品负责人给予反馈，并与他们合作，使产品更好。幸运的是，我明智地选择了我的工作，从来没有在人们不尊重或不重视我的见解的情况下结束。

个人反思：在选择一份工作的时候，一定要有自主权；这个自主权可以是自己争取的；通过表达意见以及个人反馈来进行争取。侧面也说明需要自己对相关系统有更深的理解。

二、Self-promote 自我推销

推销自己

进入雅虎后；有一天，我在雅虎的团队经理把我拉到一边，给予我一些建议。他一直在看我的代码和产出内容，告诉我，觉得我有点缺失：

你做得很好。我是说真的很棒。我喜欢你的代码，它很少有bug。但是; 问题是别人看不到这一点。为了让你的工作得到认可，你必须让别人知道。你需要做一些自我推销来引起注意。

我花了一点时间来消化他说的话，但我终于弄明白了。如果你做了很好的工作，但没有人知道你做了很好的工作，那么它并没有真正帮助你。你的经理可以支持你，但不能为你辩护。组织内部的人需要了解你的价值，最好的方法就是告诉人们你做了什么。

个人反思：做一个角落里静静编码的工程师，并不可取。你的主管会支持你，但是他没法替你宣传。公司的其他人需要明白你的价值，最好的办法就是告诉别人你做了什么。一封简单的Email："嗨，我完成了XXX，欢迎将你的想法告诉我"，就很管用。

三、It’s about people 关注人员，学会团队相处

学会带领团队

在我职业生涯的早期，我非常注重头衔。我一直想知道我必须做些什么才能得到晋升。在雅虎主页上与我的新经理进行第一次一对一的交谈时，我问我需要什么才能获得晋升。他的话至今仍在我耳边回响：

当你的技术能力过关以后，就要考验你与他人相处的能力了。

从那时起，我不确定我是否对软件工程专业有了更好的了解。他是完全正确的。那时，没有人质疑我的技术能力。众所周知，我是一个写出优秀、高质量代码的人，很少有错误。我缺乏的是领导能力

从那时起，我看到无数工程师在他们的职业生涯中被困在一个层面上。聪明的人，优秀的代码，但无法与他人有效合作，使他们留在原地。每当有人觉得自己被困在软件工程生涯中时，我都会讲述这个建议，而且它总是在金钱上是正确的。

个人反思：在团队工作中，除了完成自己的工作后；更多需要学会与团队成员的相处，这决定了你是否能够走向管理；当然；领导能力也是自己需要认真培养和学习的。

四、 of this matters 这些都不重要

生活才是最重要的

我在雅虎度过了一段令人沮丧的时期。也许沮丧不是正确的词，更像是生气。我愤怒地爆发，经常与人争吵。事情出了问题，我不喜欢这样。在一个特别艰难的一天，我问我的一位导师，当很多事情出错时，他是如何保持冷静的。他的回答是：

这很简单。你看，这些都不重要。所以一些蹩脚的代码被签入了，所以网站宕机了。那又怎样？工作不可能是你的全部生活。这些不是真正的问题，而是工作问题。真正重要的是工作之外发生的事情。我回家，我的妻子在等我。这真是太好了

我从马萨诸塞州搬到加利福尼亚，很难交到朋友。工作是我的生命，它让我保持理智，所以当它不顺利时，这意味着我的生活不顺利。这次谈话让我意识到我的生活中必须有其他事情发生，我可以回去忘记我在工作中遇到的麻烦。

他是对的，一旦我改变了思维方式，将工作中烦人的事情重新归类为“工作事情”，我就能够更清楚地思考。我能够在工作中冷静下来，与人进行更愉快的互动。

个人反思：把工作和生活分开，工作不是你的全部；学会分清楚这个是工作问题；不要把工作问题带出来的情绪带入到生活中。

五、Authority, your way 自主，自己决策

找到自己道路

当我第一次被提升为雅虎的首席工程师时，我和我的主管坐下来，以更好地了解这个角色的含义。我知道我必须更像一个领导者，但我很难自主决策。我寻求帮助。他是这样说的：

以前都是我们告诉你做什么，从现在开始，你必须自己回答这个问题了，我期待你来告诉我，什么事情需要做。

很多工程师都没有完成这个转变，如果能够做到，可能就说明你成熟了，学会了取舍。你不可能把时间花在所有事情上面，必须找到一个重点。

个人反思：你需要慢慢的学会自主决策，成为专家。找到自己的风格；并显现出来。

六、Act like you’re in charge 把自己当成主人

我每天要开很多会，有些会议我根本无话可说。我对一个朋友说，我不知道自己为什么要参加这个会，也没有什么可以贡献，他说：

"不要再去开这样的会了。你参加一个会，那是因为你参与了某件事。如果不确定自己为什么要在场，就停下来问。如果这件事不需要你，就离开。不要从头到尾都静静地参加一个会，要把自己当成负责人，大家会相信你的。"

从那时起，我从没有一声不发地参加会议。我确保只参加那些需要我参加的会议。

七、找到水平更高的人

最后，让我从自己的经历出发，给我的读者一个建议。

"找到那些比你水平更高、更聪明的人，尽量和他们在一起，吃饭或者喝咖啡，向他们讨教，了解他们拥有的知识。你的职业，甚至你的生活，都会因此变得更好。"

大家好，我是拭心。

最近看到一个很可惜的事：有个阿姨在深圳缴纳了 12 年社保，第 13 年家里突然有事不得不回老家，回去后没再缴纳社保，结果退休后无法领退休工资，还得出来打工赚钱。

之所以这样，是因为阿姨及其家人对退休的相关知识了解不多，痛失一笔收入。

吸取教训，作为在上海工作多年的打工人，为了老有所依，我花了些时间学习了养老金相基本知识，并且估算了一下退休后每月能拿到的钱，这篇文章来聊聊。

文章主要内容：

如何能在上海领退休工资

上海作为全国 GDP 第一的城市，居民的收入也是很可观的。平均工资在 2023 年达到了 12183，平均退休工资在全国也位列前茅：

从上图可以看到，上海的平均退休工资居然有五千多！不用早起不用挤地铁，躺在家里每月就能领五千多，花不完，根本花不完啊！

那么问题来了，我们如何能领到上海的退休工资？

主要有 2 个条件：

第二点很关键：在上海需要缴满社保 10 年，上海 + 其他地方累计需要缴满 15 年。 比如小张在上海工作并缴纳社保满 10 年，然后去青岛缴纳 5 年，最后可以在上海领退休工资；但如果在青岛缴纳了 10 年，在上海缴纳了 5 年，就无法在上海领退休工资了。

需要强调的是，这里说的是「累计缴满」，即使中间有断开也没关系。

还有一个细节是，发工资不等于缴纳社保，个别不正规公司会漏缴社保，这需要我们打工人自己多关注。 身边有朋友遇到过：刚毕业加入的公司规模很小，人力资源不靠谱，干了半年多只缴纳了两个月社保。

怎么看公司有没有给自己缴社保呢？我们可以从随申办上查询：

OK，这就是在上海领退休工资的条件。

退休后大概能领多少钱

掐指一算，社保缴满 15 年的任务我已经完成了一半，但还有二十九年才能领钱，心里苦啊😭。

虽然拿不到，但我对能领多少钱还是非常好奇的，究竟比平均退休工资高还是被平均？🤔

经过一番搜索，我终于发现了退休工资的计算方法。

在国家社会保险公共服务平台网站中，有一个「企业职工养老保险待遇测算」的功能：

国家社会保险公共服务平台 -> 养老保险 -> 企业职工养老保险待遇测算

链接：si.12333.gov.cn/157569.jhtm…

我们只需要输入年龄、预计退休年龄、当前缴纳年限、目前及之前平均工资、养老保险个人账户余额及未来大概工资即可测算退休工资。

如果不知道你的「养老保险个人账户余额」有多少，可以从随申办 app 搜索「养老金」查询余额：

在填完所有需要的信息后，我的预算结果是这样的：

我的天，个十百千万，居然有两万五？这还花的完？？

几秒后冷静下来，我才发现算错了。。。

两万五应该是这样算的：按照当前收入，再连续缴纳 29 年。 😂

对于我们程序员，保持收入 29 年基本是不可能的，我还是重新调整参数再看看吧。

我现在社保缴纳了七年半，如果缴够 15 年社保，退休后我能领多少钱呢？

答案是一万四！看着还不错哈，每天能有 480 元左右，就是不知道 30 年后的物价怎么样了😂。

如果再悲观一点，社保缴纳到 35 岁（然后最低标准缴够 15 年），退休后大概能领多少呢？

答案是一万元！

看了下人民币的贬值率，30 年后的一万元不知道有没有今天三千块钱的购买力😷。

OK，这就是我退休后大概能领到的工资范围。

退休工资的组成

从上面的预算结果中我们可以看到，养老金由三部分组成：基础养老金、个人账户养老金和过渡性养老金，它们都是什么意思呢？

1.基础养老金 = 退休时平均工资 ×（1+平均缴费指数）÷ 2 × 累计缴费年限 × 1%。

退休时平均工资指的是退休时所在地区上年度的社会平均工资。也就是说经济发达地区的基础养老保险金，要高于欠发达地区。

平均缴费指数指的参保人选择的缴纳比例（一般在0.6-3之间）。每个月社保的缴费比例越高，相应的基础养老金越高。

例如，小张退休时，上年度的社会平均工资是 12000。虎虎的缴费指数平均值是 1，累计缴存了15年，他的基础养老金约为：12000*(1+1)/2 * 15 * 1% = 1800。

2.个人账户养老金 = 养老保险个人账户累计金额 ÷ 养老金计发月数。

我们缴纳社保时，一部分会进入个人社保账户，一部分会进入国家统筹账户。个人账户的部分，直接影响退休养老金的计算。

计发月数和我们退休的年龄有直接的关系，退休的越晚，计发月数越少；退休的时间越早，计发月数越多。一般来说，按照 60岁 退休，计发月数是 139 个月。

退休金的计发月数只是用来计算退休金，而不是说只能领这么久的退休金。

例如，小张社保的个人缴纳比例为 8%，社保的计算基数是 9339，他选择在 60 岁退休，那他的个人账户养老金约为：9339 * 8% * 12 * 15 / 139 = 967.49。

3.过渡性养老金 = 退休时平均工资 × 建立个人账户前的缴费年限 × 1.3% × 平均缴费指数

过渡性养老金，是指在养老保险制度发生变化（比如缴费标准提高、计算方法改变、退休年龄调整）的时候，给予受影响群体的资金补充。

这个奖金的计算规则说法不一，一种比较广泛的计算方法是：退休时所在地区的平均工资 x 缴费指数 x 缴费年限 x 过渡系数，其中过渡系数大概在 1% 到 1.4% 之间。

OK，这就是养老金三部分组成的含义。

总结

好了，这篇文章到这里就结束了，主要讲了：

通过写这篇文章，我对养老金的认识更多了一些，希望国家繁荣昌盛，让我退休的时候能多领点钱!

打工人写代码写到晚上十点😭
匆匆忙忙赶上地铁，累的手机也不想玩，因为眼睛累，也不想坐因为坐了一天了，闲的蛋疼，也不知道怎么的，脑子里就出了这么个想法😓

我发现了一个奇怪的现象，无论是大学生，还是普通的上班族，或者城市写字楼里的白领，现在很多人，包括年轻人，脚上穿的大部分都是运动鞋，很少有人穿皮鞋了，年轻人好像只有在结婚的当天，才会去穿皮鞋。

我记得，以前穿皮鞋才叫时尚，出门的时候，一个阳光的年轻人，为了给人一个好的形象，都会把皮鞋擦的增明透亮，上面再配上西装、西裤，走起路来，咔咔地响，那才叫一个酷，女孩子穿皮鞋的更多，上身穿什么的都有，脚上穿的基本上都是高跟皮鞋，走起路来，左扭一下，右扭一下，在大街上会很吸人眼球的。

不知从何时起,皮鞋突然失宠了,人们都喜欢穿运动鞋了，商场里售卖的鞋子，大部分也都是运动鞋，基本上看不到皮鞋的影子了。

前几天，我就去了一趟卖鞋的商场，里面销售的鞋子，品牌很多，但几乎全是运动鞋，包括特步、鸿星尔克、李宁、安踏等等，还有一些叫不出名字洋品牌。

我自己也已经有十多年没有穿皮鞋的习惯了,穿的也都是运动鞋，这是为什么呢

前言

最近学习部署的时候，发现前端部署可以通过多种方式来进行部署，web服务器,Docker,静态部署:Github page,网站托管平台:Vercel,还有一些自动化部署的东西目前还没有学到...

Docker开始

简介

Docker是一个应用打包，分发，部署的工具，它就相当于一个容器，将你想要的一些依赖、第三方库、环境啥的和代码进行一块打包为镜像，并上传到镜像仓库里面，这样别人可以直接从镜像仓库里面直接拉去这个代码来进行运行，可以适应不同的电脑环境，打造了一个完全封闭的环境。

• 打包：将软件运行所需要的依赖、第三方库、软件打包到一起，变成一个安装包


• 分发：将你打包好的安装包上传到一个镜像 仓库，其他人可以很方便的获取安装


• 部署：拿着安装包就可以一个命令运行起来你的应用，自动模拟出一摸一样的运行环境

为什么使用Docker

Docker 的出现主要是为了解决以下问题：“在我的机器上运行正常，但为什么到你的机器上就运行不正常了？”。

平常开发的时候，项目在本地跑的好好的，但是其他人想要在他的电脑上去跑你的应用程序，但是却跑不起来，他得配置数据库，Web 服务器，插件啥的，非常不方便。Docker的出现解决了这些问题。

基本术语

镜像：理解为软件安装包，可以方便的进行传播和安装,它包含了运行应用程序所需的所有元素，包括代码、运行时环境、库、环境变量和配置文件。

• 镜像可以通过Dockerfile来进行创建


• Dockerfile就相当于一个脚本，编写一些命令，他会识别这些命令并且执行

容器：软件安装后的状态，每个软件运行的环境都是独立的、隔离的，称之为容器。

仓库:仓库是存放 Docker 镜像的地方。仓库允许你分享你的镜像，你可以将你的镜像推送（push）到仓库，也可以从仓库拉取（pull）其他人分享的镜像。

• Docker 提供了一个公共的仓库 Docker Hub，你可以在上面上传你的镜像，或者寻找你需要的镜像。

常见命令

• docker run: 用于从 Docker 镜像启动一个容器。例如，docker run -p 8080:80 -d my-app 将从名为 "my-app" 的 Docker 镜像启动一个新的容器，并将容器的 8080 端口映射到主机的 80 端口。


• docker build: 用于从 Dockerfile 构建 Docker 镜像。例如，docker build -t my-app . 将使用当前目录中的 Dockerfile 构建一个名为 "my-app" 的 Docker 镜像。


• docker pull: 用于从 Docker Hub 或其他 Docker 注册服务器下载 Docker 镜像。例如，docker pull nginx 将从 Docker Hub 下载官方的 Nginx 镜像。


• docker push: 用于将 Docker 镜像推送到 Docker Hub 或其他 Docker 注册服务器。例如，docker push my-app 将名为 "my-app" 的 Docker 镜像推送到你的 Docker Hub 账户。


• docker ps: 用于列出正在运行的 Docker 容器。添加 -a 选项（docker ps -a）可以列出所有容器，包括已停止的。


• docker stop: 用于停止正在运行的 Docker 容器。例如，docker stop my-container 将停止名为 "my-container" 的 Docker 容器。


• docker rm: 用于删除 Docker 容器。例如，docker rm my-container 将删除名为 "my-container" 的 Docker 容器。


• docker rmi: 用于删除 Docker 镜像。例如，docker rmi my-app 将删除名为 "my-app" 的 Docker 镜像。


• docker logs: 用于查看 Docker 容器的日志。例如，docker logs my-container 将显示名为 "my-container" 的 Docker 容器的日志。


• docker exec: 用于在正在运行的 Docker 容器中执行命令。例如，docker exec -it my-container bash 将在名为 "my-container" 的 Docker 容器中启动一个 bash shell。
  

ps:不会使用就:docker load --help

编写Dockerfile

FROM nginx:latest

# 定义作者

MAINTAINER Merikle



#删除目录下的default.conf文件

#RUN rm /etc/nginx/conf.d/default.conf

#设置时区

RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo 'Asia/Shanghai' >/etc/timezone



#将本地nginx.conf配置覆盖nginx配置

COPY nginx.conf /etc/nginx/nginx.conf

# 将dist文件中的内容复制到 /usr/share/nginx/html/ 这个目录下面

COPY dist/  /usr/share/nginx/html/

#声名端口

EXPOSE 8748



RUN echo 'web project build  success!!'

FROM:指定基础镜像

RUN:一般指安装的过程

COPY:拷贝本地文件到镜像的指定目录

ENV:环境变量

EXPOSE:指定容器运行时监听到的端口，是给镜像的使用者看的

ENTRYPOINT：镜像中应用的启动命令，容器运行时调用

编写完Dockerfile生成镜像:

docker build -t test:v1 .

运行镜像:

docker run -p 8080:8080 --name test-hello test:v1

意思:跑在8080端口将test:v1命名为text-hello

之后你可以发布到上面说的仓库里面

• 首先你要先 注册一个账号


• 创建一个镜像库
  

• 命令行登录账号： docker login -u username


• 新建一个tag，名字必须跟你注册账号一样 docker tag test:v1 username/test:v1


• 推上去 docker push username/test:v1


• 部署试下 docker run -dp 8080:8080 username/test:v1

实践一下Docker部署前端项目

核心思想:

将前端打包的dist放到nginx里面，然后添加一个nginx.conf文件。

docker的话就是多了一个Dockerfile文件来构建镜像而已。

nginx.conf文件的编写

#nginx.conf文件编写

#user  nobody;

worker_processes  1;



#error_log  logs/error.log;

#error_log  logs/error.log  notice;

#error_log  logs/error.log  info;



#pid        logs/nginx.pid;





events {

    worker_connections  1024;

}





http {

    include       mime.types;

    default_type  application/octet-stream;



    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '

    #                  '$status $body_bytes_sent "$http_referer" '

    #                  '"$http_user_agent" "$http_x_forwarded_for"';



    #access_log  logs/access.log  main;



    sendfile        on;

    #tcp_nopush     on;



    #keepalive_timeout  0;

    keepalive_timeout  65;



    #gzip  on;



    server {

        #监听的端口

        listen       8748;

        #请填写绑定证书的域名或者IP

        server_name  121.199.29.3;

		

		gzip on;

		gzip_min_length 1k;

		gzip_comp_level 9;

		gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;

		gzip_vary on;

		gzip_disable "MSIE [1-6]\.";



        #charset koi8-r;



        #access_log  logs/host.access.log  main;



        location / {

            root   /usr/share/nginx/html;

        	index  index.html index.htm;

        	try_files $uri $uri/ /index.html;

        }



        #error_page  404              /404.html;



        # redirect server error pages to the static page /50x.html

        #

        error_page   500 502 503 504  /50x.html;

        location = /50x.html {

            root   html;

        }



        # proxy the PHP scripts to Apache listening on 127.0.0.1:80

        #

        #location ~ \.php$ {

        #    proxy_pass   http://127.0.0.1;

        #}



        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000

        #

        #location ~ \.php$ {

        #    root           html;

        #    fastcgi_pass   127.0.0.1:9000;

        #    fastcgi_index  index.php;

        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;

        #    include        fastcgi_params;

        #}



        # deny access to .htaccess files, if Apache's document root

        # concurs with nginx's one

        #

        #location ~ /\.ht {

        #    deny  all;

        #}

    }





    # another virtual host using mix of IP-, name-, and port-based configuration

    #

    #server {

    #    listen       8000;

    #    listen       somename:8080;

    #    server_name  somename  alias  another.alias;



    #    location / {

    #        root   html;

    #        index  index.html index.htm;

    #    }

    #}





    # HTTPS server

    #

    #server {

    #    listen       443 ssl;

    #    server_name  localhost;



    #    ssl_certificate      cert.pem;

    #    ssl_certificate_key  cert.key;



    #    ssl_session_cache    shared:SSL:1m;

    #    ssl_session_timeout  5m;



    #    ssl_ciphers  HIGH:!aNULL:!MD5;

    #    ssl_prefer_server_ciphers  on;



    #    location / {

    #        root   html;

    #        index  index.html index.htm;

    #    }

    #}



}

Dockerfile文件的编写

# Dockerfile文件



FROM nginx:latest

# 定义作者

MAINTAINER Merikle



#删除目录下的default.conf文件

#RUN rm /etc/nginx/conf.d/default.conf

#设置时区

RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo 'Asia/Shanghai' >/etc/timezone



#将本地nginx.conf配置覆盖nginx配置

COPY nginx.conf /etc/nginx/nginx.conf

# 将dist文件中的内容复制到 /usr/share/nginx/html/ 这个目录下面

COPY dist/  /usr/share/nginx/html/

#声名端口

EXPOSE 8748



RUN echo 'web project build  success!!'

然后将这些压缩成zip(或者本地打包为镜像，然后上传到镜像仓库里面，在服务器里面拉取镜像就可以了)，然后传到服务器中，进行解压，构建镜像并且运行镜像来进行前端部署。

部署node项目

Dockerfile的编写

FROM node:11

MAINTAINER Merikle



# 复制代码

ADD . /mongo-server



# 设置容器启动后的默认运行目录

WORKDIR  /mongo-server



# 运行命令，安装依赖

# RUN 命令可以有多个，但是可以用 && 连接多个命令来减少层级。

# 例如 RUN npm install && cd /app && mkdir logs

RUN npm install --registry=https://registry.npm.taobao.org



# CMD 指令只能一个，是容器启动后执行的命令，算是程序的入口。

# 如果还需要运行其他命令可以用 && 连接，也可以写成一个shell脚本去执行。

# 例如 CMD cd /app && ./start.sh

CMD node app.js

然后构建镜像

发布镜像到hub上面

在服务器上面进行拉取镜像并且运行镜像。

部署mongodb

这个还没有部署，之后再说啦。

说在前面

🎈对数字进行千分位分隔应该是大部分同学都做过的功能了吧，常规的做法通常是编写一个工具函数来对数据进行转换，那么我们可不可以通过vue指令来实现这一功能呢？

效果展示

实现原理

非输入框

非输入框我们只需要对其展示进行处理，我们可以判断绑定元素的innerHTML是否不为空，不为空的话则直接对其innerHTML内容进行格式化。

export default {

    bind: function (el, binding) {

        const separator = binding.value || ",";

        if (el.innerHTML) {

            el.innerHTML = addThousandSeparator(el.innerText, separator);

        }

    },

};

输入框

对于输入框，我们希望其有以下功能：

1、输入的时候去掉分隔符

这里我们只需要监听元素的聚焦(focus)事件即可，取到元素的值，将其分隔符去掉后重新赋值。

el.addEventListener("focus", (event) => {

    const value = event.target.value;

    event.target.value = deleteThousandSeparator(value, separator);

});

2、输入完成后添加分隔符

这里我们只需要监听元素的失焦(blur)事件即可，取到元素的值，对其进行添加分隔符处理后重新赋值。

el.addEventListener("blur", (event) => {

    const value = event.target.value;

    event.target.value = addThousandSeparator(value, separator);

});

千分位分隔函数

function addThousandSeparator(num, separator = ",") {

    return num.toString().replace(/\B(?=(\d{3})+(?!\d))/g, separator);

}

• num.toString(): 将输入的数字 num 转换为字符串，以便后续处理。


• .replace(/\B(?=(\d{3})+(?!\d))/g, separator): 这里使用了正则表达式进行替换操作。具体解释如下：
  
  
  
  
  • \B: 表示非单词边界，用于匹配不在单词边界处的位置。
  
  
  • (?=(\d{3})+(?!\d)): 使用正向预查来匹配每三位数字的位置，但不匹配末尾不足三位的数字。
  
  
  • (\d{3})+: 匹配连续的三位数字。
  
  
  • separator: 作为参数传入的分隔符，默认为 ,。
  
  
  • g: 表示全局匹配，即匹配所有满足条件的位置。
  
  
  
  

这样，通过正则表达式的替换功能，在数字字符串中的每三位数字之间插入指定的千位分隔符，从而实现千位分隔符的添加。

去掉千分位分隔

function deleteThousandSeparator(numberString, separator = ",") {

    return numberString.replace(new RegExp(separator, "g"), "");

}

直接将字符串中的分隔符全部替换为空即可。

完整代码

function addThousandSeparator(num, separator = ",") {

    return num.toString().replace(/\B(?=(\d{3})+(?!\d))/g, separator);

}

function deleteThousandSeparator(numberString, separator = ",") {

    return numberString.replace(new RegExp(separator, "g"), "");

}

export default {

    bind: function (el, binding) {

        const separator = binding.value || ",";

        if (el.innerHTML) {

            el.innerHTML = addThousandSeparator(el.innerText, separator);

        }

        el.addEventListener("focus", (event) => {

            const value = event.target.value;

            event.target.value = deleteThousandSeparator(value, separator);

        });

        el.addEventListener("blur", (event) => {

            const value = event.target.value;

            event.target.value = addThousandSeparator(value, separator);

        });

    },

};

组件库

组件文档

目前该组件也已经收录到我的组件库，组件文档地址如下：
jyeontu.xyz/jvuewheel/#…

组件内容

组件库中还有许多好玩有趣的组件，如：

• 悬浮按钮


• 评论组件


• 词云


• 瀑布流照片容器


• 视频动态封面


• 3D轮播图


• web桌宠


• 贡献度面板


• 拖拽上传


• 自动补全输入框


• 图片滑块验证

等等……

组件库源码

组件库已开源到gitee，有兴趣的也可以到这里看看：gitee.com/zheng_yongt…

最近看几个老项目的SQL条件中使用了1=1，想想自己也曾经这样写过，略有感触，特别拿出来说道说道。

编写SQL语句就像炒菜，每一种调料的使用都会影响菜品的最终味道，每一个SQL条件的加入也会影响查询的执行效率。那么 1=1 存在什么样的问题呢？为什么又会使用呢？

为什么会使用 1=1？

在动态构建SQL查询时，开发者可能会不确定最终需要哪些条件。这时候，他们就会使用“1=1”作为一个始终为真的条件，让接下来的所有条件都可以方便地用“AND”连接起来，就像是搭积木的时候先放一个基座，其他的积木块都可以在这个基座上叠加。

就像下边这样：

SELECT * FROM table WHERE 1=1

<if test="username != null">

    AND username = #{username}

</if>

<if test="age > 0">

    AND age = #{age}

</if>

这样就不用在增加每个条件之前先判断是否需要添加“AND”。

1=1 带来的问题

性能问题

我们先来了解一下数据库查询优化器的工作原理。查询优化器就像是一个聪明的图书管理员，它知道如何最快地找到你需要的书籍。当你告诉它所需书籍的特征时，它会根据这些信息选择最快的检索路径。比如你要查询作者是“谭浩强”的书籍，它就选择先通过作者索引找到书籍索引，再通过书籍索引找到对应的书籍，而不是费力的把所有的书籍遍历一遍。

但是，如果我们告诉它一些无关紧要的信息，比如“我要一本书，它是一本书”，这并不会帮助管理员更快地找到书，反而可能会让他觉得困惑。一个带有“1=1”的查询可能会让数据库去检查每一条记录是否满足这个始终为真的条件，这就像是图书管理员不得不检查每一本书来确认它们都是书一样，显然是一种浪费。

不过这实际上可能也不会产生问题，因为现代数据库的查询优化器已经非常智能，它们通常能够识别出像 1=1 这样的恒真条件，并在执行查询计划时优化掉它们。在许多情况下，即使查询中包含了1=1，数据库的性能也不会受到太大影响，优化器会在实际执行查询时将其忽略。

代码质量

不过，我们仍然需要避免在查询中包含 1=1，有以下几点考虑：

编写尽可能高效、清晰和准确的SQL语句，不仅有助于保持代码的质量，也让代码具有更好的可维护性和可扩展性。

替代 1=1 的更佳做法

现在开发者普遍使用ORM框架来操作数据库了，还在完全手写拼SQL的同学可能需要反思下了，这里给两个不同ORM框架下替代1=1的方法。

假设我们有一个用户信息表 user，并希望根据传入的参数动态地过滤用户。

首先是Mybatis：

<!-- MyBatis映射文件片段 -->

<select id="selectUsersByConditions" parameterType="map" resultType="com.example.User">

  SELECT * FROM user

  <where>

    <!-- 使用if标签动态添加条件 -->

    <if test="username != null and username != ''">

      AND username = #{username}

    </if>

    <if test="age > 0">

      AND age = #{age}

    </if>

    <!-- 更多条件... -->

  </where>

</select>

在 MyBatis 中，避免使用 WHERE 1=1 的典型方法是利用动态SQL标签（如 ）来构建条件查询。 标签会自动处理首条条件前的 AND 或 OR。当没有满足条件的 或其他条件标签时， 标签内部的所有内容将被忽略，从而不会生成多余的 AND 或 WHERE 子句。

再看看 Entity Framework 的方法：

var query = context.User.AsQueryable();

if (!string.IsNullOrEmpty(username))

{

    query = query.Where(b => b.UserName.Contains(username));

}

if (age>0)

{

    query = query.Where(b => b.Age = age);

}

var users = query.ToList();

这是一种函数式编程的写法，最终生成SQL时，框架会决定是否在条件前增加AND，而不需要人为的增加 1=1。

总结

“1=1”在SQL语句中可能看起来无害，但实际上它是一种不良的编程习惯，可能会导致性能下降。就像在做饭时不会无缘无故地多加调料一样，我们在编写SQL语句时也应该避免添加无意义的条件。

每一行代码都应该有它存在的理由，不要让你的数据库像一个困惑的图书管理员，浪费时间在不必要的事情上。

大家好，这里是大家的林语冰。坚持阅读，自律打卡，每天一次，进步一点。

免责声明

本文属于是语冰的直男翻译了属于是，略有删改，仅供粉丝参考。英文原味版请传送 10 Interview Questions Every JavaScript Developer Should Know in 2024。

本期共享的是 —— 新年里前端面试需要掌握的十大面试题，知识面虽小，但思路清晰。

JS 的世界日新月异，多年来面试趋势也与时俱进。本文科普了新年每个 JS 开发者必知必会十大基本问题，涵盖了从闭包到 TDD（测试驱动开发）的一系列主题，为大家提供应对现代 JS 挑战的知识和信心。

1. 闭包到底是什么鬼物？

闭包让我们有权从内部函数访问外部函数的作用域。当函数嵌套时，内部函数可以访问外部函数作用域中声明的变量，即使外部函数返回后也是如此：

const createCat = cat => {

  return {

    getCat: () => cat,

    setCat: newCat => {

      cat = newCat

    }

  }

}



const myCat = createCat('薛定谔')

console.log(myCat.getCat()) // 薛定谔



myCat.setCat('龙猫')

console.log(myCat.getCat()) // 龙猫

闭包变量是对外部作用域变量的实时引用，而不是拷贝。这意味着，如果变更外部作用域变量，那么变更会反映在闭包变量中，反之亦然，这意味着，在同一外部函数中声明的其他函数将可以访问这些变更。

闭包的常见用例包括但不限于：

• 数据隐藏


• 柯里化和偏函数（经常用于改进函数组合，比如形参化 Express 中间件或 React 高阶组件）


• 与事件处理程序和回调共享数据

数据隐藏

封装是面向对象编程的一个重要特征。封装允许我们向外界隐藏类的实现细节。JS 中的闭包允许我们声明对象的私有变量：

// 数据隐藏

const createGirlFans = () => {

  let fans = 0

  return {

    increment: () => ++fans,

    decrement: () => --fans,

    getFans: () => fans

  }

}

柯里化函数和偏函数：

// 一个柯里化函数一次接受多个参数。

const add = a => b => a + b



// 偏函数是已经应用了某些参数的函数，

// 但没有完全应用所有参数。

const increment = add(1) // 偏函数



increment(2) // 3

2. 纯函数是什么鬼物？

纯函数在函数式编程中兹事体大。纯函数是可预测的，这使得它们比非纯函数更易理解、调试和测试。纯函数遵循两个规则：

非确定性函数依赖于以下各项的函数，包括但不限于：

• 随机数生成器


• 可以改变状态的全局变量


• 可以改变状态的参数


• 当前系统时间

副作用包括但不限于：

• 修改任何外部变量或对象属性（比如全局变量或父函数作用域链中的变量）


• 打印到控制台


• 写入屏幕、文件或网络


• 报错。相反，该函数应该返回表明错误的结果


• 触发任何外部进程

在 Redux 中，所有 reducer 都必须是纯函数。如果不是，App 的状态不可预测，且时间旅行调试等功能无法奏效。reducer 函数中的杂质还可能导致难以追踪的错误，包括过时的 React 组件状态。

3. 函数组合是什么鬼物？

函数组合是组合两个或多个函数，产生新函数或执行某些计算的过程：(f ∘ g)(x) = f(g(x))。

const compose = (f, g) => x => f(g(x))



const g = num => num + 1

const f = num => num * 2



const h = compose(f, g)



h(20) // 42

React 开发者可通过函数组合来清理大型组件树。我们可以将它们组合，创建一个新的高阶组件，而不是嵌套组件，该组件可以通过附加功能强化传递给它的任何组件。

4. 函数式编程是什么鬼物？

函数式编程是一种使用纯函数作为主要组合单元的编程范式。组合在软件开发中兹事体大，几乎所有编程范式都是根据它们使用的组合单元来命名的：

• 面向对象编程使用对象作为组合单元


• 过程式编程使用过程作为组合单元


• 函数式编程使用函数作为组合单元

函数式编程是一种声明式编程范式，这意味着，程序是根据它们做什么，而不是如何做来编写的。这使得函数式程序比命令式程序更容理解、调试和测试。它们往往更加简洁，这降低了代码复杂性，并使其更易维护。

函数式编程的其他关键方面包括但不限于：

• 不变性 —— 不可变数据结构比可变数据结构更易推理


• 高阶函数 —— 将其他函数作为参数或返回函数作为结果的函数


• 避免共享可变状态 —— 共享可变状态使程序难以理解、调试和测试。这也使得推断程序的正确性更加头大

5. Promise 是什么鬼物？

JS 中的 Promise 是一个表示异步操作最终完成或失败的对象，它充当最初未知值的占位符，通常是因为该值的计算尚未完成。

Promise 的主要特征包括但不限于：

• 有状态：Promise 处于以下三种状态之一：
  
  
  
  • 待定：初始状态，既未成功也未失败
  
  
  • 已完成：操作成功完成
  
  
  • 拒绝：操作失败
  
  
  
  


• 不可变：一旦 Promise 被完成或拒绝，其状态就无法改变。它变得不可变，永久保留其结果。这使得 Promise 在异步流控制中变得可靠。


• 链接：Promise 可以链接起来，这意味着，一个 Promise 的输出可以用作另一个 Promise 的输入。这通过使用 .then() 表示成功或使用 .catch() 处理失败来链接，从而允许优雅且可读的顺序异步操作。链接是函数组合的异步等价物。

const promise = new Promise((resolve, reject) => {

  setTimeout(() => {

    resolve('成功!')

    // 我们也可以在失败时 reject 新错误。

  }, 1000)

})



promise

  .then(value => {

    console.log(value) // 成功

  })

  .catch(error => {

    console.log(error)

  })

6. TS 是什么鬼物？

TS 是 JS 的超集，由微软开发和维护。近年来，TS 的人气与日俱增，如果您是一名 JS 工程师，您最终很可能需要使用 TS。它为 JS 添加了静态类型，JS 是一种动态类型语言。静态类型可以辅助开发者在开发过程的早期发现错误，提高代码质量和可维护性。

TS 的主要特点包括但不限于：

• 静态类型：定义变量和函数参数的类型，确保整个代码一致性。


• 给力的 IDE 支持：IDE（集成开发环境）可以提供更好的自动补全、导航和重构，使开发过程更加高效。


• 编译：TS 代码被转译为 JS，使其与任何浏览器或 JS 环境兼容。在此过程中，类型错误会被捕获，使代码更鲁棒。


• 接口：接口允许我们指定对象和函数必须满足的抽象契约。


• 与 JS 的兼容性：Ts 与现有 JS 代码高度兼容。JS 代码可以逐步迁移到 JS，使现有项目能够顺利过渡。

interface User {

  id: number

  name: string

}



type GetUser = (userId: number) => User



const getUser: GetUser = userId => {

  // 从数据库或 API 请求用户数据

  return {

    id: userId,

    name: '人猫神话'

  }

}

防范 bug 的最佳方案是代码审查、TDD 和 lint 工具（比如 ESLint）。TS 并不能替代这些做法，因为类型正确性并无法保证程序的正确性。即使应用了所有其他质量措施后，TS 偶尔也会发现错误。但它的主要好处是通过 IDE 支持，提供改进的开发体验。

7. Web Components 是什么鬼物？

WC（Web 组件）是一组 Web 平台 API，允许我们创建新的自定义、可重用、封装的 HTML 标签，在网页和 Web App 中使用。WC 是使用 HTML、CSS 和 JS 等开放 Web 技术构建的。它们是浏览器的一部分，不需要外部库或框架。

WC 对于拥有一大坨可能使用不同框架的工程师的大型团队特别有用。WC 允许我们创建可在任何框架或根本没有框架中使用的可重用组件。举个栗子，Adobe（PS 那个公司）的某个设计系统是使用 WC 构建的，并与 React 等流行框架顺利集成。

WC 由来已久，但最近人气爆棚，尤其是在大型组织中。它们被所有主要浏览器支持，并且是 W3C 标准。

8. React Hook 是什么鬼物？

Hook 是让我们无需编写类即可使用状态和其他 React 功能的函数。Hook 允许我们通过调用函数而不是编写类方法，来使用状态、上下文、引用和组件生命周期事件。函数的额外灵活性使我们更好地组织代码，将相关功能分组到单个钩子调用中，并通过在单独的函数调用中实现不相关功能，分离不相关的功能。Hook 提供了一种给力且富有表现力的方式来在组件内编写逻辑。

重要的 React Hook 包括但不限于：

• useState —— 允许我们向函数式组件添加状态。状态变量在重新渲染之间保留。


• useEffect —— 允许我们在函数式组件中执行副作用。它将 componentDidMount/componentDidUpdate/componentWillUnmount 的功能组合到单个函数调用中，减少了代码，并创建了比类组件更好的代码组织。


• useContext —— 允许我们使用函数式组件中的上下文。


• useRef —— 允许我们创建在组件的生命周期内持续存在的可变引用。


• 自定义 Hook —— 封装可重用逻辑。这使得在不同组件之间共享逻辑变得容易。

Hook 的规则：Hook 必须在 React 函数的顶层使用（不能在循环、条件或嵌套函数内），且能且只能在 React 函数式组件或自定义 Hook 中使用。

Hook 解决了类组件的若干常见痛点，比如需要在构造函数中绑定方法，以及需要将功能拆分为多个生命周期方法。它们还使得在组件之间共享逻辑以及重用有状态逻辑，而无需更改组件层次结构更容易。

9. 如何在 React 中创建点击计数器？

我们可以使用 useState 钩子在 React 中创建点击计数器，如下所示：

import React, { useState } from 'react'



const ClickCounter = () => {

  const [count, setCount] = useState(0) // 初始化为 0



  return (

    <div>

      <p>You clicked {count} times</p>

      <button onClick={() => setCount(count => count + 1)}>Click me</button>

    </div>

  )

}



export default ClickCounter

粉丝请注意，当我们从现有状态派生新值时，将函数传递给 setCount 是最佳实践，确保我们始终使用最新状态。

10. TDD 是什么鬼物？

TDD（测试驱动开发）是一种软件开发方法，其中测试是在实际代码之前编写的。它围绕一个简短的重复开发周期，旨在确保代码满足指定的要求且没有错误。TDD 在提高代码质量、减少错误和提高开发者生产力方面，可以发挥至关重要的作用。

开发团队生产力最重要的衡量标准之一是部署频率。持续交付的主要障碍之一是对变化的恐惧。TDD 通过确保代码始终处于可部署状态，辅助减少这种恐惧。这使得部署新功能和错误修复更容易，提高了部署频率。

测试先行多了一大坨福利，包括但不限于：

• 更好的代码覆盖率：测试先行更有可能覆盖所有极端情况。


• 改进的 API 设计：测试迫使我们在编写代码之前考虑 API 设计，这有助于避免将实现细节泄漏到 API 中。


• 更少的 bug：测试先行可以辅助在开发过程中尽早发现错误，这样更容易修复。


• 更好的代码质量：测试先行迫使我们编写模块化、松耦合的代码，这样更容易维护和重用。

TDD 的关键步骤包括但不限于：

重复：针对每个功能需求重复该循环，逐步构建软件，同时确保所有测试继续通过。

学习曲线：TDD 是一项需要相当长的时间才能培养的技能和纪律。经过大半年的 TDD 体验后，我们可能仍觉得 TDD 难如脱单，且妨碍了生产力。虽然但是，使用 TDD 两年后，我们可能会发现它已经成为第二天性，并且比以前更有效率。

耗时：为每个小功能编写测试一开始可能会感觉很耗时，但长远来看，这通常会带来回报，减少错误并简化维护。我常常告诫大家，“如果你认为自己没有时间进行 TDD，那么你真的没有时间跳过 TDD。”

本期话题是 —— 你遭遇灵魂拷问的回头率最高的面试题是哪一道？

欢迎在本文下方群聊自由言论，文明共享。谢谢大家的点赞，掰掰~

《前端 9 点半》每日更新，坚持阅读，自律打卡，每天一次，进步一点。

之前看过一篇文章讲代码封装的过程，下面从简述文章的内容开始梳理下自己对代码封装的一点思考.

--- 以下是之前文章内容简述 ---

在业务迭代的初期，代码中有一段业务逻辑A,由于A逻辑在项目中使用比较广泛，于是对A逻辑进行了代码逻辑的封装，包括参数的预设等



随着业务的发展，又出现了B模块，B模块中几乎可以直接使用A逻辑，但是需要对A逻辑进行一些小小的改动，比如入参的调整、逻辑分支的增加



这种通过修改较小范围代码就能实现功能的方式在实际开发中是很常规的操作，它并没有不好，只是当这种修改变的次数多的时候，最开始封装的逻辑A就变成了‘四不像’，它似乎可以服务于A模块，但是确有些冗余，出现了‘我好像看不懂这段代码’，‘这段代码还是别改了’，‘你改吧 我是改不了’的场景。在多次封装之后，逻辑A容易出现以下的问题

• 入参不可控


• 逻辑分支复杂，不清晰，修改范围不确定，容易对其他模块产生影响


• 复用度逐渐下降，解决方法
  
  
  
  
  1. 将就不再继续新增逻辑，变成'老大难'问题，总有爆发的一天
  
  
  2. 重写相关逻辑，功能回测范围大，影响范围不可控，容易出现漏测等
  
  
  
  

--- 以下是正文 ---

提前封装或者过度封装对实际业务的编写都有很大影响，最实际的感受就是这段代码不好写，这个逻辑看不懂。封装的代码逻辑是结果，封装的出发点是因，从出发点去看而不是面向结果的封装似乎更能编写出可维护性的代码。以下是自己对封装的一点思考。

降低复杂度

通过对业务中分散的相似逻辑提取，就能一定程度上降低项目的复杂度和重复度的问题。在修改相应的业务逻辑时候就相对集中和可控。新增逻辑的修改也能做到应用范围的同步。

解耦逻辑

在设计模式中需要设计的模块尽量遵循单一职责，但是在实际编写代码的过程中很容易出现模块功能的耦合，比如常见的:

• 视图层逻辑与数据层逻辑耦合


• 非相关逻辑的入侵 比如视图的逻辑需要感知请求状态的改变做相应的逻辑处理

通过将相关的逻辑都聚合到模块封装的内部，就能较低其他模块对不相关逻辑的感知，也就做到了解耦。在下面的例子中，通过将A逻辑的关联逻辑都封装进A模块中，降低了功能模块对封装逻辑的感知。

相关例子:

• 在ahooks中的useRequest中，就通过对请求状态和数据的操作就行封装，将数据相关操作做到了内聚，减轻了视图层的负担


• Antd pro components的table

分层

在例子中，通过将逻辑A中的相关逻辑提取到上层，分层的方式实现了模块功能的内聚与解耦。在前端的MVC中就通过将相关操作封装成Controller,来完成逻辑的解耦

复用(一致性，可控性)

从降低复杂度、逻辑结构、分层设计最终的目标是达到封装代码的复用。通过复用能控制代码的一致性，实现修改代码行为的可控。

• 在封装的实现上 可以逐渐的从项目内共享 -> 跨项目共享等


• 在分发共享逻辑上，有monorepo、模块联邦、npm包、微前端等方式.

-- 写在最后 --

代码的优化或者设计是应该在理解业务的基础上，从相对大的视角出发来看的。在实际做的时候容易出现缺少全局视角的设计缺失和不完善，也容易出现过度设计，需要仔细去把握这个度量。