這是這個這本書的最后一篇讀書筆記，可能比較多又看完一本。。書不在多，從中找到軟件開發(fā)的一些方法以及經(jīng)驗。這本書中大量充斥著C code。。。指針級別的錯誤。。很多細(xì)節(jié)沒有仔細(xì)去考量。
1 不要利用靜態(tài)量存儲區(qū)傳遞數(shù)據(jù)。
2 通常意義上，錯誤消失有三種原因：一是錯誤報告不對；而是錯誤已被別的程序員修改了；三是這個錯誤依然存在但沒有表現(xiàn)出來。也就是說，作為一個專業(yè)程序員，其職責(zé)之一就是要確定錯誤的消失究竟屬于以上三種情況中的哪一種，從而才去相應(yīng)的行動，但是決不能因為錯誤不出現(xiàn)就簡單地忽略了它。
錯誤消失通常是程序員和測試人員使用了不同的版本。如果在程序員使用的代碼中錯誤沒有出現(xiàn)，就采用測試員使用的程序版本，如果錯誤仍為出現(xiàn)，就可通知測試組。
但是，如果錯誤確實出現(xiàn)了，就要追蹤到它早些的源程序版本中，并決定如何修改它，然后再查看一下為什么在當(dāng)前的源程序版本中不見了。通常錯誤仍然存在，只是環(huán)境有了更改從而掩蓋了錯誤。無論什么原因，為了采取適宜的步驟來改正錯誤。，必須弄明白為什么錯誤消失了。
3 注意聽取程序員向你提出的建議，如：你可以試一試。。。。等，你就會發(fā)現(xiàn)大多數(shù)建議利用了未定義或者病態(tài)定義的副作用。如果程序員提建議時知道怎么求解，他們就不會說試一試。
在找到正確的解法之前，不要一味的試一試，要花時間尋找正確的解。
4 測試代碼的責(zé)任不在測試員身上，而是程序員自己的責(zé)任。
程序員測試代碼，是由里向外測試，而測試員則是由外向里測試。
例如，程序員測試代碼時，總是由測試每個函數(shù)開始，逐次逐條指令地通過各條代碼路徑，驗證代碼和數(shù)據(jù)流，逐步向外移動來證實函數(shù)能夠在子系統(tǒng)中與其他函數(shù)一道正常操作，最后程序員利用單元測試來驗證各個獨立子系統(tǒng)之間能夠正確地相互配合。通過單元測試，還能檢測到內(nèi)部數(shù)據(jù)結(jié)構(gòu)的狀態(tài)。
5 另一方面，測試員卻把代碼看做是一個黑盒子，從程序的各個輸入處進(jìn)行測試以尋找錯誤，測試員也可能利用回歸測試來證實所有的錯誤都已派出。然后，測試員逐步向里推進(jìn)，利用代碼覆蓋工具，來檢查在全局測試中執(zhí)行了多少內(nèi)部代碼，隨之獲得的信息產(chǎn)生新的測試，來執(zhí)行未接觸到的代碼。
這是兩種不同的測試程序的方法。之所以這樣，因為程序員強調(diào)的是代碼而測試人員強調(diào)的是特征，兩者從不同的方位考慮問題，這就增加了發(fā)現(xiàn)未知錯誤的機會。
6 每當(dāng)看到程序員向測試人員發(fā)火時，我總是把他們拉到一旁并問他們：你們?yōu)槭裁匆獪y試人員為程序員所犯的錯誤負(fù)責(zé)呢？和測試員發(fā)火毫無道理，他們僅僅是執(zhí)行者。
每當(dāng)測試員向你報告你的代碼中有某個錯誤時，你最先的反應(yīng)是震驚和不相信，你本來就沒想到測試員會在你的代碼中發(fā)現(xiàn)錯誤；你的第二個反應(yīng)是應(yīng)該感謝，因為測試員幫助你避免交付錯誤。
不要責(zé)怪測試員發(fā)現(xiàn)了你的錯誤。
有時你會聽到程序員抱怨某個錯誤太荒謬，或者抱怨某個測試員經(jīng)常報告一些愚蠢的錯誤。如果你聽到這樣的抱怨時，制止并提醒他，測試員并不判斷錯誤的嚴(yán)重性，也不說這些錯誤是否值得派出。測試員必須報告所有的錯誤，不管是愚蠢還是不愚蠢的，盡管測試員知道，有些愚蠢的錯誤可能是某個嚴(yán)重問題的副作用。
但是真正的問題是，程序員在測試這個代碼時，為什么沒有捕獲這個錯誤呢？即使這些錯誤很輕微并且不值得派出，但找出錯誤的根源也是非常重要的，以避免將來出現(xiàn)類似的錯誤。
一個錯誤可能很輕微，但是它的存在本身就很嚴(yán)重。