一个奇怪的Bug非常感谢小赵同学给我反馈的这个Bug??在开始讲解前先考考你们Javascript基础，单看代码你觉得它会输出什么内容？答案后面揭晓。'Hello'.replace('ello','#$&%')话说某一天我突然收到一封邮件，一位同学跟我说我的站点炸代码了，吓得我突然就从床上翻了个身——感觉充电线有点勒脖子我又翻了回去……一波详询过后我了解到是我的自建博客站点，也就是现在在写文章的这个，它在某个页面上会显示一部分代码在页面的下方。像这样：心情突然就不好了——死去的Bug突然又回来攻击我了。。这个问题其实之前出现过，但我后来给修好了，今天又出现了我第一时间就抓紧复现，但发现我自己访

一个奇怪的Bug非常感谢小赵同学给我反馈的这个Bug??在开始讲解前先考考你们Javascript基础，单看代码你觉得它会输出什么内容？答案后面揭晓。'Hello'.replace('ello','#$&%')话说某一天我突然收到一封邮件，一位同学跟我说我的站点炸代码了，吓得我突然就从床上翻了个身——感觉充电线有点勒脖子我又翻了回去……一波详询过后我了解到是我的自建博客站点，也就是现在在写文章的这个，它在某个页面上会显示一部分代码在页面的下方。像这样：心情突然就不好了——死去的Bug突然又回来攻击我了。。这个问题其实之前出现过，但我后来给修好了，今天又出现了我第一时间就抓紧复现，但发现我自己访

在vue开发的父子组件传值的时候，我们一般都是先封装一个子组件，给他取名字，然后在要用到此组件的页面，也就是所说的父组件中将这个子组件导入、注册、再使用。我们一般都是用驼峰命名导入的组件，在使用时可以直接用驼峰命名的方式使用，也可以将这个驼峰变成小写，中间以-分隔来进行使用，可以用单标签也可以用双标签，一般用的多的一般是双标签，因为有的时候会用到插槽，所以要用双标签进行插槽的传递。父子传值时，我们一般用：名称=“传递的值”进行传递，在子组件中用props进行接受，一般没有什么特殊的数据，就是单个的键值对的时候我们可以直接用一个数组来表示接受的props。但是用的多的还是props用对象表示，要

在vue开发的父子组件传值的时候，我们一般都是先封装一个子组件，给他取名字，然后在要用到此组件的页面，也就是所说的父组件中将这个子组件导入、注册、再使用。我们一般都是用驼峰命名导入的组件，在使用时可以直接用驼峰命名的方式使用，也可以将这个驼峰变成小写，中间以-分隔来进行使用，可以用单标签也可以用双标签，一般用的多的一般是双标签，因为有的时候会用到插槽，所以要用双标签进行插槽的传递。父子传值时，我们一般用：名称=“传递的值”进行传递，在子组件中用props进行接受，一般没有什么特殊的数据，就是单个的键值对的时候我们可以直接用一个数组来表示接受的props。但是用的多的还是props用对象表示，要

摘要：本文从流程上需要改进的地方进行讨论，分四个方面来分析产生这个问题的原因。本文分享自华为云社区《Bug改不完，迭代总延期，咋办？》，作者：华为云PaaS服务小智。前言随着互联网的兴起，版本交付越来越频繁，企业开始了敏捷转型、DevOps落地，项目组雄心勃勃，期望产品能按迭代快速交付。然而常见的现象是，到了迭代的最后一天，还有不少Bug来不及修复，迭代无法产生潜在可交付成果，延期成了必然。然后发现连续几个迭代都是这样，团队没有成就感，士气低落。迭代的无法按期交付，让团队及公司领导又觉得敏捷只是形式化，并没有解决问题，久而久之，就干脆放弃了所采用的敏捷框架，回到老路子上了。迭代总是因为修复不完

摘要：本文从流程上需要改进的地方进行讨论，分四个方面来分析产生这个问题的原因。本文分享自华为云社区《Bug改不完，迭代总延期，咋办？》，作者：华为云PaaS服务小智。前言随着互联网的兴起，版本交付越来越频繁，企业开始了敏捷转型、DevOps落地，项目组雄心勃勃，期望产品能按迭代快速交付。然而常见的现象是，到了迭代的最后一天，还有不少Bug来不及修复，迭代无法产生潜在可交付成果，延期成了必然。然后发现连续几个迭代都是这样，团队没有成就感，士气低落。迭代的无法按期交付，让团队及公司领导又觉得敏捷只是形式化，并没有解决问题，久而久之，就干脆放弃了所采用的敏捷框架，回到老路子上了。迭代总是因为修复不完

我们开发的过程中，一般都是将axios封装后，简单的设置一下基地址、请求时间、请求拦截器中的请求头，响应拦截器中对能连通的接口的错误抛出处理、响应返回的数据的剥离处理等。以此便于快捷的开发，然后在我们根据后端给的接口，一般会通过swagger来给你接口、请求方法、请求参数等，后端通过postman可以进行接口的测试然后再写入swagger，但是他会给你get请求携带body参数来进行请求，应该是postman能支持，而我们开发用的axios不支持，想要axios变的支持我们得改axios的源码，很麻烦我也没去了解。我们的了解中get请求一般请求时都是直接将请求的参数拼接到url地址后面再进行请

我们开发的过程中，一般都是将axios封装后，简单的设置一下基地址、请求时间、请求拦截器中的请求头，响应拦截器中对能连通的接口的错误抛出处理、响应返回的数据的剥离处理等。以此便于快捷的开发，然后在我们根据后端给的接口，一般会通过swagger来给你接口、请求方法、请求参数等，后端通过postman可以进行接口的测试然后再写入swagger，但是他会给你get请求携带body参数来进行请求，应该是postman能支持，而我们开发用的axios不支持，想要axios变的支持我们得改axios的源码，很麻烦我也没去了解。我们的了解中get请求一般请求时都是直接将请求的参数拼接到url地址后面再进行请

hello，大家好呀，我是小楼。最近我又双叒叕写了个BUG，一个线上服务死锁了，不过幸亏是个新服务，没有什么大影响。出问题的是Go的读写锁，如果你是写Java的，不必划走，更要看看本文，本文的重点在于Java和Go的读写锁对比，甚至看完后你会有一个隐隐的感觉：Go的读写锁是不是有BUG？故障回放背景简单抽象一下：一个server服务（Go语言实现），提供了一个http接口，另有一个client服务来调用这个接口，整体架构非常简单，甚至都不用画架构图你也能够理解。这两个服务上线运行了一段时间都没什么问题，突然有一天client调用这个server的接口全都超时了。碰到这种问题，第一时间去查看日志

hello，大家好呀，我是小楼。最近我又双叒叕写了个BUG，一个线上服务死锁了，不过幸亏是个新服务，没有什么大影响。出问题的是Go的读写锁，如果你是写Java的，不必划走，更要看看本文，本文的重点在于Java和Go的读写锁对比，甚至看完后你会有一个隐隐的感觉：Go的读写锁是不是有BUG？故障回放背景简单抽象一下：一个server服务（Go语言实现），提供了一个http接口，另有一个client服务来调用这个接口，整体架构非常简单，甚至都不用画架构图你也能够理解。这两个服务上线运行了一段时间都没什么问题，突然有一天client调用这个server的接口全都超时了。碰到这种问题，第一时间去查看日志