-
\ No newline at end of file
diff --git a/github-roam.md b/github-roam.md
index b3c4aa9..a9762be 100644
--- a/github-roam.md
+++ b/github-roam.md
@@ -400,7 +400,7 @@ C | 2
### 我的第一个PR
-我的第一个PR是给一个小的Node的CoAP相关的库的Pull Request。原因比较简单，是因为它的README.md写错了，导致我无法办法进行下一步。
+我的第一个PR是给一个小的Node的CoAP相关的库的Pull Request。原因比较简单，是因为它的README.md写错了，导致我无法进行下一步。
const dgram = require('dgram')
- , coapPacket = require('coap-packet')
@@ -1035,7 +1035,7 @@ Git 提交信息及几种不同的规范
与我们日常工作稍有不同的是：工作中的 Release 计划一般都是事先安排好的，不需要一些 CHANGELOG 什么的。而开源应用、开源库需要有对应的 CHANELOG，则添加了什么功能、修改了什么等等。毕竟有很多东西是由社区来维护的。
-因此，这里以做得比较好的开源项目 Angular 中为例展示。Angular 团队建议采用以下的形式：
+因此，这里以做得比较好的开源项目 Angular 为例展示。Angular 团队建议采用以下的形式：
```
():
@@ -1147,21 +1147,19 @@ React.render(
有一天，我发现当我需要我一次又一次地重复讲述某些内容，于是我就计划着把这些应该掌握的技能放到GitHub上，也就有了[Artisan Stack](https://github.com/phodal-archive/artisanstack.github.io) 计划。
-每个程序员都不可避免地是一个Coder，一个没有掌握好技能的Coder，算不上是手工艺人，但是是手工人。
-
-艺，需要有创造性的方法。
+每个程序员都不可避免地是一个Coder，一个没有掌握好技能的Coder，算不上是手工艺人，但是手工艺人，需要有创造性的方法。
## 为什么重构?
> 为了更好的代码。
-在经历了一年多的工作之后，我平时的主要工作就是修Bug。刚开始的时候觉得无聊，后来才发现修Bug需要更好的技术。有时候你可能要面对着一坨一坨的代码，有时候你可能要花几天的时间去阅读代码。而，你重写那几十代码可能只会花上你不到一天的时间。但是如果你没办法理解当时为什么这么做，你的修改只会带来更多的bug。修Bug，更多的是维护代码。还是前人总结的那句话对:
+在经历了一年多的工作之后，我平时的主要工作就是修Bug。刚开始的时候觉得无聊，后来才发现修Bug需要更好的技术。有时候你可能要面对着一坨一坨的代码，有时候你可能要花几天的时间去阅读代码。而你重写那几十行代码可能只会花上你不到一天的时间。但是如果你没办法理解当时为什么这么做，你的修改只会带来更多的Bug。修Bug，更多的是维护代码。还是前人总结的那句话对:
> 写代码容易，读代码难。
假设我们写这些代码只要半天，而别人读起来要一天。为什么不试着用一天的时候去写这些代码，让别人花半天或者更少的时间来理解。
-如果你的代码已经上线，虽然是一坨坨的。但是不要轻易尝试，``没有测试的重构``。
+如果你的代码已经上线，虽然是一坨坨的。但是不要轻易尝试``没有测试的重构``。
从前端开始的原因在于，写得一坨坨且最不容易测试的代码都在前端。
@@ -1193,7 +1191,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``模式(架构模式)。
@@ -1895,7 +1893,7 @@ numbers, objects, strings, etc. Lodash’s modular methods are great for:
-当然了，这种事不能太过，要不是会招来一堆黑。
+当然了，这种事不能太过，要不然会招来一堆黑。
### 安装及hello, world 示例
@@ -2952,19 +2950,21 @@ Lettuce.send = function (url, method, callback, data) {
表格源自一本书叫《Linux内核0.11(0.95)完全注释》，简单地再介绍一下：
+
- 版本0.00是一个hello,world程序
- 版本0.01包含了可以工作的代码
- 版本0.11是基本可以正常的版本
这里就要扯到《GNU 风格的版本号管理策略》：
-1．项目初版本时，版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0，如果你为人很低调，我想你会选择那个主版本号为 0 的方式；
-2．当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
+1. 项目初版本时，版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0，如果你为人很低调，我想你会选择那个主版本号为 0 的方式；
+2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0，因而可以被忽略掉；
-4．当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1；
-5．另外，编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。
+4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1；
+5. 另外，编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。
因此，我们可以得到几个简单的结论：
+
- 我们需要阅读最早的有核心代码的版本
- 我们需要阅读1.0版本的Release
- 往后每一次大的Release我们都需要了解一下
@@ -3521,7 +3521,7 @@ GitHub 里程碑
一年前，稍微改变了下策略：暂时以**培养人为主**，同时想着做一个合适的开源框架——只是在今年看来，前端领域已经没有合适的地方可以造轮子了。
-在 GitHub 上有一个很常见的问题是，**大多部分项目的维护者就是发起人**——如果这个发起人发生意外了，那么这个项目怎么办。如果这是一个很火的项目，它就存在着巨大的风险；同时这可能也说明了，缺乏一套合理的机制。
+在 GitHub 上有一个很常见的问题是，**大多数项目的维护者就是发起人**——如果这个发起人发生意外了，那么这个项目怎么办。如果这是一个很火的项目，它就存在着巨大的风险；同时这可能也说明了，缺乏一套合理的机制。
你的开源项目不仅仅需要一个使用文档，还需要一个相关设计思想的文档、路线图、未来计划等等。
@@ -3551,9 +3551,9 @@ GitHub 里程碑
**家居智能中心**。我仍然对于大学学的知识有点念念不忘，虽然已经写了一本书，但是硬件还是相当的刺激。唯一的问题是：连房子都没有，怎么做智能家居。
-**图形框架**。这是我之前在做一个图形界面的时候，发生没有一个合适的框架可以满足我的要求。然后我就在想，还是自己做一个吧。
+**图形框架**。这是我之前在做一个图形界面的时候，发现没有一个合适的框架可以满足我的要求。然后我就在想，还是自己做一个吧。
-不过，最好的开源项目就是自己平时用的。于是，我开始将写各种工作来提自己使用——如现在在用的这篇微信编辑工具：[mdpub](https://github.com/phodal/mdpub)。
+不过，最好的开源项目就是自己平时用的。于是，我开始将写各种工具来给自己使用——如现在在用的这篇微信编辑工具：[mdpub](https://github.com/phodal/mdpub)。
最后，我做了一个简单的 HTML 5 动画来记录这一时刻，作为这一个里程碑的记念：
@@ -3573,7 +3573,7 @@ FAQ
在这种时候，也没有法律来保护这些开源软件作者。你只能从道德上谴责他们，然后指望他们的领导来做出一些什么事。如之前的《[知名公司（努比亚/中兴）拿我的开源软件（ XXL-JOB）申请国家知识专利，我该怎么办？](https://link.zhihu.com/?target=https%3A//www.v2ex.com/t/367424%3Fp%3D1)》事件。
-并且对于大部分的开源软件作者来说，都不大可像 OpenResty、Vue、emqtt 等软件的作者一样，可以从开源软件获得收益来支撑他们开发。还有一些少数人，还能从开源软件中获得一些利益，提高他们今年的 KPI。然后明年的工资，又会多涨一点点。
+并且对于大部分的开源软件作者来说，都不大可能像 OpenResty、Vue、emqtt 等软件的作者一样，可以从开源软件获得收益来支撑他们开发。还有一些少数人，还能从开源软件中获得一些利益，提高他们今年的 KPI。然后明年的工资，又会多涨一点点。
可多数人，并没有这样的可能性。我在 GitHub 上有接近 30k 的 star（笑，有接近 20k 是属于电子书的，毕竟思想改变世界），它一点儿也不影响我涨工资。反而多了一个 GitHub “网红” 的称号，要知道在技术领域，“网红” 并不是一个好词。我观察过的大量开源爱好者，怕是比我还惨一些。明明做了很好的工作，因为宣传工作没有做好，连几个 star 都没有，后来就弃坑了。
+