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