update design doc

doc/abstract.md

@@ -0,0 +1,14 @@
+# 摘要 - 设计原则
+
+goc 的定位是一个专注提升测试体验和项目质量的工具，它不用于生产环境。
+
+当用户从 go 切换为 goc 时，**成本应越小越好**。如果是生产环境无法替代的工具，那使用部署再怎么不便，用户也会趋之若鹜。
+
+因此 v2 版本在如下：
+
+1. goc 命令行使用
+2. goc 部署方式（即 agent <-> server 通信方式）
+
+做了大量重构甚至重写。
+
+得益于重写的通信方式，v2 还提供了 watch 模式，为第三方开发自己的实时代码染色系统提供了接口。

doc/protocol.md

@@ -10,7 +10,7 @@ v1 版本中，被插桩的服务会暴露一个 HTTP 接口，由 goc server
 
 ## 新设计选择
 
-新设计只需要暴露 goc server 的地址，由插桩服务发起链接，然后保持长链接，在该长链接上构建 goc 自己的业务逻辑。
+新设计只需要暴露 goc server 的地址，由插桩服务发起连接，然后保持长连接，在该长连接上构建 goc 自己的业务逻辑。
 
 ### 自行设计 TCP 应用层协议
 

doc/return_error_or_fatal.md

@@ -1,12 +1,16 @@
 # 返回 error 还是原地 fatal
 
-哪种好呢？在一个纯命令行应用中，及时 fatal，并能在 Panic 中打印出堆栈对调试即为有意。
+哪种好呢？在一个纯命令行应用中，及时 fatal，并能在 panic 中打印出堆栈对调试即为有益。
 
 若是返回 error，虽然看起来：
 
 1. 对每种异常处理都定义的很清楚（有明确的错误消息）
 2. 写单测也更容易
 
-但是 Go 的错误处理，导致 error 被一层层返回，以至于在最上层拿到 error 时你都分不清有几层了 -_-，虽然 Go 1.13 的 error wrap 一定程度消减了这个问题，但还是不如 Panic 来的好调试。
+如果函数调用嵌套很深，导致 error 被一层层包裹返回，以至于在最上层拿到 error 时你都分不清到底出错点在哪 -_-，虽然 Go 1.13 的 error wrap 一定程度消减了这个问题，但还是不如 panic 来的好调试。（如果是一个 web 应用，则做法相反，web 的查错主要靠详细的日志，这时候不应鼓励过多的 panic 或 os.Exit(1))
 
-而且 goc 并不是一个供大家使用的库，目前来看 fatal 还是更适合。
+而且 goc 并不是一个供大家使用的库，很多 error 没必要往上抛。
+
+目前来看 fatal 还是更适合。
+
+那如何保障测试质量呢？我们不应被覆盖率所绑架，只要测试用例全面，一样可以保证质量。