• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            O(1) 的小樂

            Job Hunting

            公告

            記錄我的生活和工作。。。
            <2025年7月>
            293012345
            6789101112
            13141516171819
            20212223242526
            272829303112
            3456789

            統計

            • 隨筆 - 182
            • 文章 - 1
            • 評論 - 41
            • 引用 - 0

            留言簿(10)

            隨筆分類(70)

            隨筆檔案(182)

            文章檔案(1)

            如影隨形

            搜索

            •  

            最新隨筆

            最新評論

            閱讀排行榜

            評論排行榜

            Writing Solid Code Steve Marguire

              這是這個這本書的最后一篇讀書筆記,可能比較多又看完一本。。書不在多,從中找到軟件開發的一些方法以及經驗。這本書中大量充斥著C code。。。指針級別的錯誤。。很多細節沒有仔細去考量。

             

            1 不要利用靜態量存儲區傳遞數據。

            2 通常意義上,錯誤消失有三種原因:一是錯誤報告不對;而是錯誤已被別的程序員修改了;三是這個錯誤依然存在但沒有表現出來。也就是說,作為一個專業程序員,其職責之一就是要確定錯誤的消失究竟屬于以上三種情況中的哪一種,從而才去相應的行動,但是決不能因為錯誤不出現就簡單地忽略了它。

               錯誤消失通常是程序員和測試人員使用了不同的版本。如果在程序員使用的代碼中錯誤沒有出現,就采用測試員使用的程序版本,如果錯誤仍為出現,就可通知測試組。

            但是,如果錯誤確實出現了,就要追蹤到它早些的源程序版本中,并決定如何修改它,然后再查看一下為什么在當前的源程序版本中不見了。通常錯誤仍然存在,只是環境有了更改從而掩蓋了錯誤。無論什么原因,為了采取適宜的步驟來改正錯誤。,必須弄明白為什么錯誤消失了。

             

            3 注意聽取程序員向你提出的建議,如:你可以試一試。。。。等,你就會發現大多數建議利用了未定義或者病態定義的副作用。如果程序員提建議時知道怎么求解,他們就不會說試一試。

              在找到正確的解法之前,不要一味的試一試,要花時間尋找正確的解。

            4  測試代碼的責任不在測試員身上,而是程序員自己的責任。

              程序員測試代碼,是由里向外測試,而測試員則是由外向里測試。

              例如,程序員測試代碼時,總是由測試每個函數開始,逐次逐條指令地通過各條代碼路徑,驗證代碼和數據流,逐步向外移動來證實函數能夠在子系統中與其他函數一道正常操作,最后程序員利用單元測試來驗證各個獨立子系統之間能夠正確地相互配合。通過單元測試,還能檢測到內部數據結構的狀態。

             

            5 另一方面,測試員卻把代碼看做是一個黑盒子,從程序的各個輸入處進行測試以尋找錯誤,測試員也可能利用回歸測試來證實所有的錯誤都已派出。然后,測試員逐步向里推進,利用代碼覆蓋工具,來檢查在全局測試中執行了多少內部代碼,隨之獲得的信息產生新的測試,來執行未接觸到的代碼。

              這是兩種不同的測試程序的方法。之所以這樣,因為程序員強調的是代碼而測試人員強調的是特征,兩者從不同的方位考慮問題,這就增加了發現未知錯誤的機會。

             

            6 每當看到程序員向測試人員發火時,我總是把他們拉到一旁并問他們:你們為什么要測試人員為程序員所犯的錯誤負責呢?和測試員發火毫無道理,他們僅僅是執行者。

               每當測試員向你報告你的代碼中有某個錯誤時,你最先的反應是震驚和不相信,你本來就沒想到測試員會在你的代碼中發現錯誤;你的第二個反應是應該感謝,因為測試員幫助你避免交付錯誤。

             

               不要責怪測試員發現了你的錯誤。

             

            有時你會聽到程序員抱怨某個錯誤太荒謬,或者抱怨某個測試員經常報告一些愚蠢的錯誤。如果你聽到這樣的抱怨時,制止并提醒他,測試員并不判斷錯誤的嚴重性,也不說這些錯誤是否值得派出。測試員必須報告所有的錯誤,不管是愚蠢還是不愚蠢的,盡管測試員知道,有些愚蠢的錯誤可能是某個嚴重問題的副作用。

               但是真正的問題是,程序員在測試這個代碼時,為什么沒有捕獲這個錯誤呢?即使這些錯誤很輕微并且不值得派出,但找出錯誤的根源也是非常重要的,以避免將來出現類似的錯誤。

               一個錯誤可能很輕微,但是它的存在本身就很嚴重。

            posted on 2010-09-05 15:13 Sosi 閱讀(241) 評論(0)  編輯 收藏 引用

            統計系統
            久久99精品国产自在现线小黄鸭| 伊人色综合久久| 蜜桃麻豆WWW久久囤产精品| 欧美麻豆久久久久久中文| 国产精品美女久久福利网站| 久久99精品久久久久久久不卡 | 久久国产成人精品国产成人亚洲| 国产成人无码精品久久久免费| 久久国产三级无码一区二区| 亚洲国产成人精品无码久久久久久综合| 久久久久人妻一区二区三区| 97久久精品无码一区二区天美| 久久一区二区三区免费| 精品久久久久中文字幕日本| 久久久久亚洲AV无码专区桃色| 无码AV中文字幕久久专区| 亚洲国产精久久久久久久| 亚洲国产美女精品久久久久∴| 久久国产精品免费一区二区三区| 欧美午夜精品久久久久免费视| 国产日韩久久久精品影院首页| 蜜臀av性久久久久蜜臀aⅴ麻豆| 久久国产成人| 国产精品亚洲综合专区片高清久久久| 中文字幕日本人妻久久久免费 | 久久亚洲熟女cc98cm| 久久综合久久久| 久久精品国产精品亚洲毛片| 一本色道久久综合亚洲精品| 一本色道久久88综合日韩精品| 国产精品青草久久久久福利99 | 久久99精品国产一区二区三区| 久久夜色精品国产欧美乱| 一极黄色视频久久网站| 午夜肉伦伦影院久久精品免费看国产一区二区三区 | 久久一区二区三区免费| 久久精品国产色蜜蜜麻豆| 久久夜色精品国产亚洲| 久久综合九色综合欧美狠狠| 久久精品国产一区| 久久久久久久尹人综合网亚洲|