Merge pull request #277 from lewgun/patch-17

golang -> go & other fix typo

ch5-web/ch5-01-introduction.md

@@ -1,6 +1,6 @@
 # 5.1 web 开发简介
 
-由于 golang 的 `net/http` 提供了基础的路由函数组合，并且也提供了丰富的功能函数。所以在 golang 社区里有一种观点认为用 golang 写 api 不需要框架。其看法也存在一定的道理，如果你的项目路由在个位数，URI 固定且不通过 URI 来传递参数，那么使用官方库也就足够。但在复杂场景下，官方的 http 库还是有些力不从心。例如下面这样的路由：
+因为Go的 `net/http`包提供了基础的路由函数组合与丰富的功能函数。所以在社区里流行一种用Go编写api不需要框架的观点;在我们看来，如果你的项目的路由在个位数、URI 固定且不通过 URI 来传递参数，那么确实使用官方库也就足够。但在复杂场景下，官方的 http 库还是有些力有不逮。例如下面这样的路由：
 
 ```
 GET   /card/:id
@@ -13,14 +13,14 @@ GET   /card/:id/relations
 
 可见是否该用框架还是要具体问题具体分析的。
 
-golang 的 web 框架大致可以分为这么两类：
+Go的Web框架大致可以分为这么两类：
 
-1. router 框架
-2. mvc 类框架
+1. Router框架
+2. MVC类框架
 
-在使用哪种框架上，大多数情况下都是看个人的喜好和公司技术人员的背景。例如公司有很多技术人员是 php 出身，那么他们一定会非常喜欢像 beego 这样的框架，但如果公司有很多 C 程序员，那么他们的想法可能是越简单越好。比如很多大厂的 C 程序员可能甚至都会去用 C 去写很小的 CGI 程序，可能本身并没有什么意愿去学习你的 MVC 或者更复杂的 web 框架，他们需要的只是一个非常简单的路由(甚至连路由都不需要，只需要一个基础的 http 协议处理库来帮他省掉没什么意思的体力劳动)。
+在框架的选择上，大多数情况下都是依照个人的喜好和公司的技术栈。例如公司有很多技术人员是PHP出身，那么他们一定会非常喜欢像beego 这样的框架，但如果公司有很多 C 程序员，那么他们的想法可能是越简单越好。比如很多大厂的 C 程序员甚至可能都会去用 C 去写很小的 CGI 程序，他们可能本身并没有什么意愿去学习MVC或者更复杂的 web 框架，他们需要的只是一个非常简单的路由(甚至连路由都不需要，只需要一个基础的HTTP协议处理库来帮他省掉没什么意思的体力劳动)。
 
-golang 的 net/http 库提供的就是这样基础的功能，写一个 http echo server 只需要三十秒。
+Go的 net/http 包提供的就是这样的基础功能，写一个 http echo server 只需要30s。
 
 ```go
 //brief_intro/echo.go
@@ -50,7 +50,7 @@ func main() {
 
 ```
 
-如果你 30 秒没有完成这个程序，检查一下自己的打字速度是不是慢了。 开个玩笑。这个例子是为了说明如果你想写一个 http 协议的小程序有多么简单。如果你面临的情况比较复杂，例如几十个接口的企业级应用，直接用 net/http 库就显得不太合适了。
+如果你过了30s还没有完成这个程序，请检查一下你自己的打字速度是不是慢了(开个玩笑 :D)。这个例子是为了说明在Go中写一个HTTP协议的小程序有多么简单。如果你面临的情况比较复杂，例如几十个接口的企业级应用，直接用 net/http 库就显得不太合适了。
 
 我们来看看开源社区中一个 kafka 监控项目中的做法：
 
@@ -146,11 +146,11 @@ func handleKafka(app *ApplicationContext, w http.ResponseWriter, r *http.Request
 }
 ```
 
-因为默认的 http 库中的 mux 不支持带参数的路由，Burrow 这个项目使用了非常蹩脚的字符串 Split 和乱七八糟的 switch case 来达到自己的目的，但实际上却让本来应该很集中的路由管理逻辑变得复杂，散落在系统的各处，难以维护和管理。如果读者细心地看过这些代码之后，可能会发现其它的几个 handler 函数逻辑上较简单，最复杂的也就是这个 handleKafka。但实际上我们的系统总是从这样微不足道的混乱开始积少成多，最终变得难以收拾。
+因为默认的net/http包中的 mux 不支持带参数的路由，所以Burrow 这个项目使用了非常蹩脚的字符串 Split 和乱七八糟的 switch case 来达到自己的目的，但实际上却让本来应该很集中的路由管理逻辑变得复杂，散落在系统的各处，难以维护和管理。如果读者细心地看过这些代码之后，可能会发现其它的几个 handler 函数逻辑上较简单，最复杂的也就是这个 handleKafka。但实际上我们的系统总是从这样微不足道的混乱开始积少成多，最终变得难以收拾。
 
-简单地来说，只要你的路由带有参数，并且这个项目的 api 数目超过了 10，就尽量不要使用 net/http 中默认的路由。在 golang 开源圈应用最广泛的 router 是 httpRouter，很多开源的 router 框架都是基于 httpRouter 进行一定程度的改造。关于 httpRouter 路由的原理，会在本章节的 router 一节中进行详细的阐释。
+根据我们的经验，简单地来说，只要你的路由带有参数，并且这个项目的 api 数目超过了 10，就尽量不要使用 net/http 中默认的路由。在Go开源界应用最广泛的 router 是 httpRouter，很多开源的 router 框架都是基于 httpRouter 进行一定程度的改造的结果。关于 httpRouter 路由的原理，会在本章节的 router 一节中进行详细的阐释。
 
 再来回顾一下文章开头说的，开源界有这么几种框架，第一种是对 httpRouter 进行简单的封装，然后提供定制的 middleware 和一些简单的小工具集成比如 gin，主打轻量，易学，高性能。第二种是借鉴其它语言的编程风格的一些 MVC 类框架，例如 beego，方便从其它语言迁移过来的程序员快速上手，快速开发。还有一些框架功能更为强大，除了 db 设计，大部分代码直接生成，例如 goa。不管哪种框架，适合读者背景的就是最好的。
 
-本章的内容除了会展开讲解 router 和 middleware 的原理，还会以现在工程界面临的问题结合 golang 来进行一些实践性的说明。希望没有接触过相关内容的读者能够有所受用。
+本章的内容除了会展开讲解 router 和 middleware 的原理外，还会以现在工程界面临的问题结合 Go 来进行一些实践性的说明。希望能够对没有接触过相关内容的读者有所帮助。