diff --git a/chapters/06-refactor-project.md b/chapters/06-refactor-project.md
index 9979b97..e91b443 100644
--- a/chapters/06-refactor-project.md
+++ b/chapters/06-refactor-project.md
@@ -4,21 +4,19 @@
 
 有一天，我发现当我需要我一次又一次地重复讲述某些内容，于是我就计划着把这些应该掌握的技能放到GitHub上，也就有了[Artisan Stack](https://github.com/phodal-archive/artisanstack.github.io) 计划。
 
-每个程序员都不可避免地是一个Coder，一个没有掌握好技能的Coder，算不上是手工艺人，但是是手工人。
-
-艺，需要有创造性的方法。
+每个程序员都不可避免地是一个Coder，一个没有掌握好技能的Coder，算不上是手工艺人，但是手工艺人，需要有创造性的方法。
 
 ## 为什么重构?
 
 > 为了更好的代码。
 
-在经历了一年多的工作之后，我平时的主要工作就是修Bug。刚开始的时候觉得无聊，后来才发现修Bug需要更好的技术。有时候你可能要面对着一坨一坨的代码，有时候你可能要花几天的时间去阅读代码。而，你重写那几十代码可能只会花上你不到一天的时间。但是如果你没办法理解当时为什么这么做，你的修改只会带来更多的bug。修Bug，更多的是维护代码。还是前人总结的那句话对:
+在经历了一年多的工作之后，我平时的主要工作就是修Bug。刚开始的时候觉得无聊，后来才发现修Bug需要更好的技术。有时候你可能要面对着一坨一坨的代码，有时候你可能要花几天的时间去阅读代码。而你重写那几十行代码可能只会花上你不到一天的时间。但是如果你没办法理解当时为什么这么做，你的修改只会带来更多的Bug。修Bug，更多的是维护代码。还是前人总结的那句话对:
 
 > 写代码容易，读代码难。
 
 假设我们写这些代码只要半天，而别人读起来要一天。为什么不试着用一天的时候去写这些代码，让别人花半天或者更少的时间来理解。
 
-如果你的代码已经上线，虽然是一坨坨的。但是不要轻易尝试，``没有测试的重构``。
+如果你的代码已经上线，虽然是一坨坨的。但是不要轻易尝试``没有测试的重构``。
 
 从前端开始的原因在于，写得一坨坨且最不容易测试的代码都在前端。
 
@@ -50,7 +48,7 @@ while ((stra = micromarkdown.regexobject.mail.exec(str)) !== null) {
 }
 ```
 
-选这个做重构的开始，不仅仅是因为之前在写[EchoesWorks](https://github.com/phodal/echoesworks)的时候进行了很多的重构。而且它更适合于，``重构到设计模式``的理论。让我们在重构完之后，给作者进行pull request吧。
+选这个做重构的开始，不仅仅是因为之前在写[EchoesWorks](https://github.com/phodal/echoesworks)的时候进行了很多的重构。而且它更适合于``重构到设计模式``的理论。让我们在重构完之后，给作者进行pull request吧。
 
 Markdown的解析过程，有点类似于``Pipe and Filters``模式(架构模式)。