ehlxr/gopl-zh.github.com
1
0
Fork 0
mirror of https://github.com/gopl-zh/gopl-zh.github.com.git synced 2024-12-25 14:28:58 +00:00
Code Issues Projects Releases Wiki Activity

fix typo

Browse Source
This commit is contained in:
Xargin 2016-04-26 20:52:50 +08:00
parent 9194f5f455
commit ce5648bf33
3 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
ch11/ch11-05.md
View File

@ -1,10 +1,10 @@
## 11.5. 剖析
测量基准对于衡量特定操作的性能是有帮助的，但是当我们视图让程序跑的更快的时候，我们通常并不知道从哪里开始优化。每个码农都应该知道Donald Knuth在1974年的“Structured Programming with go to Statements”上所说的格言。虽然经常被解读为不重视性能的意思，但是从原文我们可以看到不同的含义：
测量基准(Benchmark)对于衡量特定操作的性能是有帮助的，但是当我们试图让程序跑的更快的时候，我们通常并不知道从哪里开始优化。每个码农都应该知道Donald Knuth在1974年的“Structured Programming with go to Statements”上所说的格言。虽然经常被解读为不重视性能的意思，但是从原文我们可以看到不同的含义：
> 毫无疑问，效率会导致各种滥用。程序员需要浪费大量的时间思考或者担心，被部分程序的速度所干扰，实际上这些尝试提升效率的行为可能产生强烈的负面影响，特别是当调试和维护的时候。我们不应该过度纠结于细节的优化，应该说约97%的场景：过早的优化是万恶之源。
>
> 我们当然不应该放弃那关键的3%的机会。一个好的程序员不会因为这个理由而满足，他们会明智地观察和识别哪些是关键的代码；但是只有在关键代码已经被确认的前提下才会进行优化。对于判断哪些部分是关键代码是经常容易犯经验性错误的地方，因此程序员普通使用的测量工具，使得他们的直觉很不靠谱。
> 我们当然不应该放弃那关键的3%的机会。一个好的程序员不会因为这个理由而满足，他们会明智地观察和识别哪些是关键的代码；但是只有在关键代码已经被确认的前提下才会进行优化。对于很多程序员来说，判断哪部分是关键的性能瓶颈，是很容易犯经验上的错误的，因此这种情况下一般都会借助于工具去实现。
当我们想仔细观察我们程序的运行速度的时候，最好的技术是如何识别关键代码。自动化的剖析技术是基于程序执行期间一些抽样数据，然后推断后面的执行状态；最终产生一个运行时间的统计数据文件。

4
ch11/ch11-06.md
View File

@ -18,8 +18,8 @@ func ExampleIsPalindrome() {
示例文档的第二个用处是在`go test`执行测试的时候也运行示例函数测试。如果示例函数内含有类似上面例子中的`// Output:`格式的注释，那么测试工具会执行这个示例函数，然后检测这个示例函数的标准输出和注释是否匹配。
示例函数的第三个目的提供一个真实的演练场。 http://golang.org 就是由godoc提供的文档服务，它使用了Go Playground提高的技术让用户可以在浏览器中在线编辑和运行每个示例函数，就像图11.4所示的那样。这通常是学习函数使用或Go语言特性最快捷的方式。
示例函数的第三个目的提供一个真实的演练场。 http://golang.org 就是由godoc提供的文档服务，它使用了Go Playground让用户可以在浏览器中在线编辑和运行每个示例函数，就像图11.4所示的那样。这通常是学习函数使用或Go语言特性最快捷的方式。
![](../images/ch11-04.png)
本书最后的两掌是讨论reflect和unsafe包，一般的Go用户很少直接使用它们。因此，如果你还没有写过任何真实的Go程序的话，现在可以忽略剩余部分而直接编码了。
本书最后的两章是讨论reflect和unsafe包，一般的Go用户很少直接使用它们。因此，如果你还没有写过任何真实的Go程序的话，现在可以忽略剩余部分而直接编码了。

2
ch11/ch11.md
View File

@ -1,6 +1,6 @@
# 第十一章 测试
Maurice Wilkes，第一个存储程序计算机EDSAC的设计者，1949年他在实验室爬楼梯时有一个顿悟。在《计算机先驱回忆录》（Memoirs of a Computer Pioneer）里，他回忆到：“忽然间有一种醍醐灌顶的感觉，我整个后半生的美好时光都将在寻找程序BUG中度过了”。肯定从那之后的大部分正常的码农都会同情Wilkes过份悲观的想法，虽然也许不是没有人困惑于他对软件开发的难度的天真看法。
Maurice Wilkes，第一个存储程序计算机EDSAC的设计者，1949年他在实验室爬楼梯时有一个顿悟。在《计算机先驱回忆录》（Memoirs of a Computer Pioneer）里，他回忆到：“忽然间有一种醍醐灌顶的感觉，我整个后半生的美好时光都将在寻找程序BUG中度过了”。肯定从那之后的大部分正常的码农都会同情Wilkes过分悲观的想法，虽然也许不是没有人困惑于他对软件开发的难度的天真看法。
现在的程序已经远比Wilkes时代的更大也更复杂，也有许多技术可以让软件的复杂性可得到控制。其中有两种技术在实践中证明是比较有效的。第一种是代码在被正式部署前需要进行代码评审。第二种则是测试，也就是本章的讨论主题。