注重 效实注重 效实 的偏执的偏执 A Pragmatic Approach

(II)

Horky

28/May,2010http://blog.csdn.net/horkychen

1

Keywords

• 工具放大你的才能• 代 生成器码 • 的思 ：最容易欺 的人是自己调试 维 骗• 断言式 程编• 将 常用于 常的异 异 问题• 按合约设计

2

Enlarge your capability by tool

• find• grep• diff• emacs• sed• M4• python• Perl• ... Thousands more utilities in Unix/Unix like system.

(Windows User also could use them by Cygwin)

3

Sample

• emacs–写个小测试程序，还要动用 VS2005或者 Xcode吗 ?

–试试 emacs或者 vi,然后使用 gcc来编译你的程序。

4

Sample

• sed & m4–自动编译环境的应用

5

Code Generator

• 用模具来提高工作效率！• M4 -> Generate Info.plist• -> Generate HTML/XML file• flex -> Parser

6

Sample

• Info.plist Generator– M4

7

的思调试 维

• 最容易欺 的人是自己骗–恐慌 -> 退一步 -> 任何事情都有可能

• 死程序不说谎

8

Story (I)

Andy曾经参与过一个大型图形应用的开发。快要发布时，测试人员报告说，每次他们用特定的画笔画线，应用都会崩溃。负责该应用的程序员争辩说，这个画笔没有任何问题；他试过用它绘图，它工作得很好。几天里这样的对话来回进行，大家的情绪急速上升。

最后，我们让他们坐到同一个房间里。测试人员选了画笔工具，从右上角到左下角画了一条线。应用程序炸了

”。“噢，程序员用很小的声音说。他随后像绵羊一样承认，他在测试时只测试了从左下角画到右上角的情况，没有暴露出这个 bug。

思考 : 如何克服这样的问题 ?

9

Story (II)• 找到问题的原因的一种非常简单、却又特别有用的技术是向别人解释它。他应该越过你的肩膀看着屏幕，不断点头（像澡盆里上下晃动的橡皮鸭）。他们一个字也不需要说；你只是一步步解释代码要做什么，常常就能让问题从屏幕上跳出来，宣布自己的存在。

• 　　这听起来很简单，但在向他人解释问题时，你必须明确地陈述那些你在自己检查代码时想当然的事情。因为必须详细描述这些假定中的一部分，你可能会突然获得对问题的新洞见。

思考 : 问题该在什么时候拿出来讨论 ?

10

Story (III)

我们参加过一个项目的开发，有位高级工程师确信 select系统调用在 Solaris上有问题。再多的劝说或逻辑也无法改变他的想法（这台机器上的所有其他网络应用都工作良好这一事实也一样无济于事）。他花了数周时间编写绕开这一问题的代码，因为某种奇怪的原因，却好像并没有解决问题。当最后被迫坐下来、阅读关于 select的文档时，他在几分钟之内就发现并纠正了问题。现在每当有人开始因为很可能是我们自己的故障而抱怨系统时，我们就会使用“ select ”没有问题作为温和的提醒。

思考 : 如何理解经验的益处与坏处？

11

No surprise!

• 在发现某个 bug让你吃惊时（也许你在用我们”听不到的声音咕哝说：“那不可能。），你必

”须重新评估你确信不疑的“事实。在那个链表——例程中 你知道它坚固耐用，不可能是这个

bug ——的原因 你是否测试了所有边界条件？另——外一段代码你已经用了好几年 它不可能还

有 bug。可能吗？

思考 :• 两步曲：如何解决 BUG -> 如何预防 BUG• 团队的集体智慧能够破除某个组员的误解吗？

12

Crash Early

• “ ”它不可能发生是不可能发生的！– 检查了打开的文件是否关闭？– 检查了内存分配成功与否？– 检查了不再使用的内存是否已经释放？– 指针定位是否发生了漂移？

• Solution:– 防御式编程

• 如果让你做个瓶子，要考虑哪些问题？瓶子装什么该是首先要考虑的，水、油还是硫酸？

• 尽量提前检测出所有可能的异常！

13

Assertion• 如果它不会发生，就用断言来确保它不会发生！• 断言应用以下各项：

– 输入参数或输出参数的取值处于预期的范围内；– 子程序开始（或者结束）执行时文件或流处于打开（或关闭）的状态；– 子程序开始（或结束）执行时，文件或流的读写位置处于开头（或结尾

）处；– 文件或流已用只读、只写或可读可写方式打卡；– 仅用于输入的变量的值没有被子程序所修改；– 指针或对象非空；– 传入子程序的数组和其他容器至少能容纳 X 个数据元素；– 表已初始化，存储着真实的数值；– 子程序开始（或结束）执行时，某个容器是空的（或满的）；– 一个经过高度优化的复杂子程序的运算结果和相对缓慢但代码清晰的子程序的运算结果相一致；

• 断言用于绝不会发生的状况！

14

Assertion

• 只我们才能确保我们的程序是正确的！• 断言的目的：让你的程序有异常时就早点

死掉！ -> 有效地定位问题发生的位置！

思考 :

编译警告有多少价值？

15

Exception

• 可能 -> 错误检查– 检查传入的文件是否存在

• 不可能 -> 异常处理– 检查系统目录是否存在

• 错误发生与错误处理分割！

• 思考 :– 异常与错误检查是否等效？– 如何抛出异常？是否可以集中管理异常 ?

16

Sample•

try{ 包含可能抛出异常的语句； throw 错误 的对象

}catch( 类型名 [形参名 ]) // 捕获特定类型的异常{

}catch( 类型名 [形参名 ]) // 捕获特定类型的异常{

}catch(...) // 三个点则表示捕获所有类型的异常{}

17

Story

• Donald E. Knuth在 TeX: The Program的前言中说："我相信，在 1985年 11月 27日， TeX代码里面的最后一个 BUG已经被发现和解决了。但是，如果代码中仍旧有 BUG，我很高兴付给任何第一个发现 BUG的人 20.48美元 (这是前一个金额的两倍，而且我计划在一年内把它翻倍。你看，我很自信！ )"

想知道后来发生了什么吗 ?

18

Design By Contracts

• http://en.wikipedia.org/wiki/Design_by_contract

• 确保程序做该做的事，并且把事做好！–前置条件及收尾条件 (Post Condition)

• GNU Nana -> Last updated at 2005!

19

Q&A

20