fix: add space between chinese and number or letter

Author: JimmyLv

前端/2019-05-08-vue-application-unit-test-strategy-and-practice-05-testing-trophy.md

@@ -30,13 +30,13 @@ published: True
 
 ### 测试奖杯🏆：软件测试的分层策略
 
-测试奖杯（[Testing Trophy](https://testingjavascript.com/)）是一种**自下而上**的 Web 应用测试策略。其实这是在说我们需要编写_恰到好处的_测试，给予团队足够的信心 —— 正确的测试，而_不是_仅仅追求达到100％的测试覆盖率而已。
+测试奖杯（[Testing Trophy](https://testingjavascript.com/)）是一种**自下而上**的 Web 应用测试策略。其实这是在说我们需要编写_恰到好处的_测试，给予团队足够的信心 —— 正确的测试，而_不是_仅仅追求达到 100％的测试覆盖率而已。
 
 ![测试奖杯的四个部分](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1539186394/theTestingTrophy_2x.png)
 
 使用测试奖杯策略，我们可以将这些自动化测试技术进行分层：
 
-* **使用静态类型系统和linter** 来捕获拼写或语法之类的基本错误。
+* **使用静态类型系统和 linter** 来捕获拼写或语法之类的基本错误。
 * **编写有效单元测试** 需要特别针对于应用的某些关键行为或功能。
 * **编写集成测试** 以确保 Web 应用各模块之间能够正常协调工作。
 * **创建端到端（e2e）功能测试** 对关键路径进行自动化点击操作，而不是等到最终用户来发现问题。
@@ -60,7 +60,7 @@ published: True
 |  action 层   | 1. 是否获取了正确的参数<br />2. 是否正确地调用了 API<br />3. 是否使用了正确的返回值存取回 Vuex 中<br />4. 业务分支逻辑<br />5. 异常逻辑 | 这五个业务点建议 100% 覆盖                                   | 这个层级主要包含前述 5 大方面的业务逻辑，进行测试很有重构价值 |
 | mutation 层  | 是否正确完成计算                                             | 有逻辑的 mutation 要求 100%覆盖率                            | 这个层级输入输出明确，又包含业务计算，非常适合单元测试       |
 |  getter 层   | 是否正确完成计算                                             | 有逻辑的 getter 要求 100%覆盖率                              | 这个层级输入输出明确，又包含业务计算，非常适合单元测试       |
-| component 层 | 是否渲染了正确的组件                                         | 1.  组件的分支渲染逻辑要求100%覆盖<br/>2.  交互事件的调用参数一般要求100%覆盖<br/>3.  被 connect 过的组件不测<br/> | 这个层级最为复杂，还是以「代价最低，收益最高」为指导原则进行 |
+| component 层 | 是否渲染了正确的组件                                         | 1.  组件的分支渲染逻辑要求 100%覆盖<br/>2.  交互事件的调用参数一般要求 100%覆盖<br/>3.  被 connect 过的组件不测<br/> | 这个层级最为复杂，还是以「代价最低，收益最高」为指导原则进行 |
 |    UI 层     | 组件是否渲染了正确的样式                                     | 1.  纯 UI 不测<br/>2.  CSS 不测                              | 这个层级以我目前理解来说测试较难稳定，成本又较高             |
 |   utils 层   | 各种辅助工具函数                                             | 没有副作用的必须 100% 覆盖                                   |                                                              |
 
@@ -104,13 +104,13 @@ published: True
 单元测试只有在毫秒级别内完成，开发者才会愿意频繁地运行它，将其作为快速反馈的手段也才能成立。那么为了使单元测试更快，我们需要：
 
 * 尽可能地避免依赖。除了恰当设计好对象，关于避免依赖我已知有两种不同的看法：
-    * 使用mock适当隔离掉三方的依赖（如数据库、网络、文件等）
-    * 避免mock，换用更快速的数据库、启动轻量级服务器、重点测试文件内容等来迂回
+    * 使用 mock 适当隔离掉三方的依赖（如数据库、网络、文件等）
+    * 避免 mock，换用更快速的数据库、启动轻量级服务器、重点测试文件内容等来迂回
 * 将依赖、集成等耗时、依赖三方返回的地方放到更高层级的测试中，有策略性地去做
 
 ### **I**ndependent：一次只测一条分支
 
-通常来说，一条分支就是一个业务场景，是做任务分解（Tasking）过程的一个细粒度的task。为什么测试只测一条分支呢？很显然，如此你才能给它一个好的描述，这个测试才能保护这个特定的业务场景，挂了的时候能给你细致到输入输出级别的业务反馈。
+通常来说，一条分支就是一个业务场景，是做任务分解（Tasking）过程的一个细粒度的 task。为什么测试只测一条分支呢？很显然，如此你才能给它一个好的描述，这个测试才能保护这个特定的业务场景，挂了的时候能给你细致到输入输出级别的业务反馈。
 
 常见的反模式是，实现本身就做了太多的事情，不符合[单一职责原则（SRP）](https://zh.wikipedia.org/wiki/%E5%8D%95%E4%B8%80%E5%8A%9F%E8%83%BD%E5%8E%9F%E5%88%99)。如果你发现某个模块的单元测试特别难写的话，那么这个模块的实现本身或输入/输出就足够繁琐，应当作为一种某味道识别出来进行重构。
 
@@ -152,7 +152,7 @@ test.each([
 
 另外，还有一些测试实现代码的执行次序。这也是一种“关注内部实现”的测试，这就使得除了输入输出外，还有“执行次序”这个因素可能使测试挂掉。显然，这样的测试也不利于重构的开展。
 
-此外，对外部依赖采取mock策略，同样是某种程度上的“关注内部实现”，因为mock的失败同样将导致测试的失败，而非真正业务场景的失败。对待mock的态度，肖鹏有篇文章[Mock的七宗罪](https://gitbook.cn/books/58fa1af500a2684bf77511bc/index.html)对此展开了详细描述，应当谨慎使用。
+此外，对外部依赖采取 mock 策略，同样是某种程度上的“关注内部实现”，因为 mock 的失败同样将导致测试的失败，而非真正业务场景的失败。对待 mock 的态度，肖鹏有篇文章[Mock的七宗罪](https://gitbook.cn/books/58fa1af500a2684bf77511bc/index.html)对此展开了详细描述，应当谨慎使用。
 
 ### **T**imely：表达力极强，易于阅读
 
@@ -167,10 +167,10 @@ test.each([
 * **测试数据准备**。无关的测试数据（比如对象中的很多无关字段）不应该写出来，应只准备能体现测试业务的最小数据
 * **输出报告**。选用断言工具时，应注意除了要提供测试结果，还要能准确提供“期望值”与“实际值”的差异
 
-上述第三点有些测试框架提供了反例，比如说chai和sinon提供的断言API就不如jest友好，体现在：
+上述第三点有些测试框架提供了反例，比如说 chai 和 sinon 提供的断言 API 就不如 jest 友好，体现在：
 
 * `expect(array).to.eql(array)`出错的时候，只能报告说`expect [Array (42)] to equal [Array (42)]`，具体是哪个数据不匹配，根本没报告
-* `expect(sinonStub.calledWith(args)).to.be.true`出错的时候，会报告说`expect false to be true`。废话，我还不知道挂了么，但是那个stub究竟被什么参数调用则没有报告
+* `expect(sinonStub.calledWith(args)).to.be.true`出错的时候，会报告说`expect false to be true`。废话，我还不知道挂了么，但是那个 stub 究竟被什么参数调用则没有报告
 
 ## 总结一下
 
@@ -186,7 +186,7 @@ test.each([
 
 ### 「懒惰」是程序员最大的美德
 
-Perl语言的发明人Larry Wall说，好的程序员有3种美德： 懒惰、急躁和傲慢（Laziness, Impatience and hubris）。
+Perl 语言的发明人 Larry Wall 说，好的程序员有 3 种美德： 懒惰、急躁和傲慢（Laziness, Impatience and hubris）。
 
 懒惰：是这样一种品质，它使得你花大力气去避免消耗过多的精力。它敦促你写出节省体力的程序，同时别人也能利用它们。为此你会写出完善的测试或文档，以免别人问你太多问题。
 
@@ -203,7 +203,7 @@ Perl语言的发明人Larry Wall说，好的程序员有3种美德： 懒惰、
 - **我**，还可以如何偷懒？
 - 应该让计算机帮忙测点什么？
 - 计算机该在什么时候进行测试？
-- 需要100％的覆盖率吗？
+- 需要 100％的覆盖率吗？
 - 多少次测试就足够了？
 
 ## 未完待续……
@@ -225,13 +225,13 @@ Perl语言的发明人Larry Wall说，好的程序员有3种美德： 懒惰、
 
 * [x] \### CQRS 与 `Redux-like` 架构
 * [x] \### 如何对 Vuex 进行单元测试
-* [x] \### Vue组件和Vuex store的交互  
+* [x] \### Vue 组件和 Vuex store 的交互  
 
 **\## Vue 应用测试策略**
 
 * [x] \### 单元测试的特点及其位置
 * [x] \### 测试奖杯🏆：软件测试的分层策略
-* [x] \### 单元测试的F.I.R.S.T原则
+* [x] \### 单元测试的 F.I.R.S.T 原则
 
 **\## Vue 单元测试的落地**
 

前端/2019-07-16-vue-application-unit-test-strategy-and-practice-06-execution-suggestion.md

@@ -38,7 +38,7 @@ published: True
 
 ### 3. 真正理解前端数据流的好处
 
-前文在讲测试原则的时候也提到过单一职责原则（SRP），很多同学在遗留代码之上写单元测试的时候，表示特别痛苦。“这都是些啥呀，输入/输出不明确，还各种副作用，一个函数做了7、8件事情，一个类承担5、6种角色。”所以呢，这时候我们要明白 Vue 和 Vuex 诞生的背景是什么，理解它们各自要解决的问题是什么。只有规范好各自的职责，才能够把 UI 和数据流清晰得隔离开来。只有这样，我们作为 vuex store 的使用者，才会变得简单，而不只是把 vuex action 当成一个 API 的简单 wrapper，所有数据处理逻辑全部都还是放在 UI 组件里面。
+前文在讲测试原则的时候也提到过单一职责原则（SRP），很多同学在遗留代码之上写单元测试的时候，表示特别痛苦。“这都是些啥呀，输入/输出不明确，还各种副作用，一个函数做了 7、8 件事情，一个类承担 5、6 种角色。”所以呢，这时候我们要明白 Vue 和 Vuex 诞生的背景是什么，理解它们各自要解决的问题是什么。只有规范好各自的职责，才能够把 UI 和数据流清晰得隔离开来。只有这样，我们作为 vuex store 的使用者，才会变得简单，而不只是把 vuex action 当成一个 API 的简单 wrapper，所有数据处理逻辑全部都还是放在 UI 组件里面。
 
 **什么是架构，其实架构就是把代码放到该放的地方。**不写代码的架构师们当然就不会知道，也不会知道代码写烂之后，该如何去补测试。那可能就不只是一种“补测试就像吃剩饭”的感觉了，那只能是一种在不明排泄物之上堆💩的体验。
 
@@ -87,7 +87,7 @@ it('should return summed up total amount 1000 when there are three products pric
 
 ![](https://camo.githubusercontent.com/7992f05135785019d3696e57aca343ee8e376f52/68747470733a2f2f776f756e6465726f2e66696c65732e776f726470726573732e636f6d2f323031332f30322f6536616638666535613461396539383362646536616639346535383938646534623838306535613461396539383062326536616461356534623838306539626239656539626239652e6a7067)
 
-👆上图的道理我们都明白，哪怕每天只进步 1%，那么一年 365 天的效果也是无比非凡的。我们可以给项目添加一个单元测试覆盖率提升的hook，即每次push都会检查并更新测试覆盖率的阈值，每次提交都不能少于上一次提交，这样我们就可以持续进步、持续改进，持续提高测试覆盖率啦。
+👆上图的道理我们都明白，哪怕每天只进步 1%，那么一年 365 天的效果也是无比非凡的。我们可以给项目添加一个单元测试覆盖率提升的 hook，即每次 push 都会检查并更新测试覆盖率的阈值，每次提交都不能少于上一次提交，这样我们就可以持续进步、持续改进，持续提高测试覆盖率啦。
 
 平时的工作日常，我们还会有一个电视作为 CI Monitor，所以我们可以把团队项目的测试覆盖率放上去，每次提交之后测试覆盖率都会高一点点，给每位同学一个即时的反馈，鼓励大家坚持下去。
 
@@ -157,13 +157,13 @@ TDD（测试驱动开发）的步骤如下，能够时刻给予开发者反馈
 
 * [x] \### CQRS 与 `Redux-like` 架构
 * [x] \### 如何对 Vuex 进行单元测试
-* [x] \### Vue组件和Vuex store的交互  
+* [x] \### Vue 组件和 Vuex store 的交互  
 
 **\## Vue 应用测试策略**
 
 * [x] \### 单元测试的特点及其位置
 * [x] \### 测试奖杯🏆：软件测试的分层策略
-* [x] \### 单元测试的F.I.R.S.T原则
+* [x] \### 单元测试的 F.I.R.S.T 原则
 
 **\## Vue 单元测试的落地**
 

编程/2019-06-24-awesome-personal-toolbox-of-10x-developers.md

@@ -15,9 +15,9 @@ published: False
 
 「我这辈子最享受的浪费时间的方式，就是研究各种提高效率的方法。」———Marc Andressen
 
-我也不是说我就是10x程序员，如果是的话，怎么没见我的工资比你们高10倍呢？不过，我的手速是你的……
+我也不是说我就是 10x 程序员，如果是的话，怎么没见我的工资比你们高 10 倍呢？不过，我的手速是你的……
 
-博客大赛又开始了，10x程序员的工具箱， 你觉得我不会比你快10倍？打字速度x2快捷键熟x3方法论x2经验x2，再加上我的工具箱x5，快10倍根本不止好吗？什么？你说你还年轻有的是时间？不好意思，我宁愿成为80岁的自己也不愿变成20岁的你。
+博客大赛又开始了，10x 程序员的工具箱， 你觉得我不会比你快 10 倍？打字速度 x2 快捷键熟 x3 方法论 x2 经验 x2，再加上我的工具箱 x5，快 10 倍根本不止好吗？什么？你说你还年轻有的是时间？不好意思，我宁愿成为 80 岁的自己也不愿变成 20 岁的你。
 更何况他们可不是简单的加法作用，而是互相产生促进作用。正如打字速度会促进我的思考速度一样，而你只能被打字速度限制了思考。
 做的快，有一个好处就是，但你还在想着好与坏，犹豫要不要做的时候，我已经亲手尝试并且得出成果，总结出结论了。
 我的梦想是改变世界，在宝尊，我影响的是世界最顶尖的头部品牌。