Writing Solid Code Steve Marguire

这是这个这本书的最后一篇读书笔记，可能比较多又看完一本。。书不在多，从中找到软件开发的一些方法以及经验。这本书中大量充斥着C code。。。指针级别的错误。。很多细节没有仔细去考量。

1 不要利用静态量存储区传递数据。

2 通常意义上，错误消失有三种原因：一是错误报告不对；而是错误已被别的程序员修改了；三是这个错误依然存在但没有表现出来。也就是说，作为一个专业程序员，其职责之一就是要确定错误的消失究竟属于以上三种情况中的哪一种，从而才去相应的行动，但是决不能因为错误不出现就简单地忽略了它。

错误消失通常是程序员和测试人员使用了不同的版本。如果在程序员使用的代码中错误没有出现，就采用测试员使用的程序版本，如果错误仍为出现，就可通知测试组。

但是，如果错误确实出现了，就要追踪到它早些的源程序版本中，并决定如何修改它，然后再查看一下为什么在当前的源程序版本中不见了。通常错误仍然存在，只是环境有了更改从而掩盖了错误。无论什么原因，为了采取适宜的步骤来改正错误。，必须弄明白为什么错误消失了。

3 注意听取程序员向你提出的建议，如：你可以试一试。。。。等，你就会发现大多数建议利用了未定义或者病态定义的副作用。如果程序员提建议时知道怎么求解，他们就不会说试一试。

在找到正确的解法之前，不要一味的试一试，要花时间寻找正确的解。

4 测试代码的责任不在测试员身上，而是程序员自己的责任。

程序员测试代码，是由里向外测试，而测试员则是由外向里测试。

例如，程序员测试代码时，总是由测试每个函数开始，逐次逐条指令地通过各条代码路径，验证代码和数据流，逐步向外移动来证实函数能够在子系统中与其他函数一道正常操作，最后程序员利用单元测试来验证各个独立子系统之间能够正确地相互配合。通过单元测试，还能检测到内部数据结构的状态。

5 另一方面，测试员却把代码看做是一个黑盒子，从程序的各个输入处进行测试以寻找错误，测试员也可能利用回归测试来证实所有的错误都已派出。然后，测试员逐步向里推进，利用代码覆盖工具，来检查在全局测试中执行了多少内部代码，随之获得的信息产生新的测试，来执行未接触到的代码。

这是两种不同的测试程序的方法。之所以这样，因为程序员强调的是代码而测试人员强调的是特征，两者从不同的方位考虑问题，这就增加了发现未知错误的机会。

6 每当看到程序员向测试人员发火时，我总是把他们拉到一旁并问他们：你们为什么要测试人员为程序员所犯的错误负责呢？和测试员发火毫无道理，他们仅仅是执行者。

每当测试员向你报告你的代码中有某个错误时，你最先的反应是震惊和不相信，你本来就没想到测试员会在你的代码中发现错误；你的第二个反应是应该感谢，因为测试员帮助你避免交付错误。

不要责怪测试员发现了你的错误。

有时你会听到程序员抱怨某个错误太荒谬，或者抱怨某个测试员经常报告一些愚蠢的错误。如果你听到这样的抱怨时，制止并提醒他，测试员并不判断错误的严重性，也不说这些错误是否值得派出。测试员必须报告所有的错误，不管是愚蠢还是不愚蠢的，尽管测试员知道，有些愚蠢的错误可能是某个严重问题的副作用。

但是真正的问题是，程序员在测试这个代码时，为什么没有捕获这个错误呢？即使这些错误很轻微并且不值得派出，但找出错误的根源也是非常重要的，以避免将来出现类似的错误。

一个错误可能很轻微，但是它的存在本身就很严重。