第二十一章 協同構建

這一章中的21.2其實上周就有看，因為上周進行了結對編程。不過讀書筆記寫在了一起。

21.1 概要

有一個驚人的數據，設計期間程序員平均每小時會引入1 ~ 3個缺陷，編碼期間平均每小時引入5 ~ 8個缺陷。

有許多同樣驚人的數據顯示，協同構建可以縮短開發周期，通過代碼復查檢查錯誤成本比測試更低，而且可以檢查到一些更隱蔽的風格、注釋等錯誤。另外，開發者考慮到需要經過代碼復查，編寫時便會更加審慎。

21.2 結對編程

這本書對結對編程沒有那么重視，只是將其看做一個有一定意義但不適合大規模項目的實踐方法，因此討論得沒那么詳細。盡管如此，我閱讀時聯想自己結對編程的經歷，還是很有啟發。這里的錯誤幾乎每一個我都有犯過，并在結對編程小結與收獲中描述過。因為不想再抱怨一遍自己犯過的錯誤，下面就不再提了。

結對編程的核心思想在于一個人進行編程，另一個人注意檢查有沒有錯誤，并考慮設計與策略。

結對編程的關鍵：

• 要約定代碼規范。不要將很多無謂的時間花在糾結代碼風格上，而應該嘗試對其標準化。我們就犯了這個問題。
• 不要讓結對變成旁觀。不掌握鍵盤的人應該主動積極地檢查，并且思考下一步應該做什么。不過我們連旁觀都沒有（摔。
• 不要強迫在簡單的問題上使用結對編程。很多問題可以討論之后分別編程，或者對部分工作結對編程，而不需要完全結對。
  我沒有經驗并不知道什么需要結對什么不需要結對，但個人感覺這次作業是需要結對的。
  另外部分結對編程這個想法給了我啟發，也許我們的團隊項目中也可以考慮部分工作采取結對編程的方法（當然前提是隊友同意我的奇思妙想啦）。
• 有規律地進行人員和工作調換。
  對于結對雙方（駕駛員和領航員）的工作調換，目的在于讓雙方都能熟悉系統的不同部分，并且合理地分攤工作量。
  然而，書中還說到，對于采用了結對編程方法的團體項目，不同的結對小組之間的工作安排也應該調換，這點我不太能認同。對于一個大的項目，試圖讓每個人熟悉系統的每個部分在我看來是一個非常低效的做法。
• 鼓勵雙方跟上彼此的步伐。
• 保證雙方都能看到顯示器，而且字體、亮度等應該合適。這是一個emmmm比較瑣碎的建議，只要結對雙方能夠溝通應該很好解決吧。
• 不要強迫關系不好的人結對。也要避免兩個新手結對。我們這次就是新手結對。半學期以來我覺得新手進行軟件工程的工作真的比較刷運氣，運氣好就成功了獲取了成功經驗，大部分時候獲取的都是失敗經驗。
• 如果在團體項目中使用結對方法，也還是需要指定一個組長，來協調工作并對結果負責。

結對編程的好處：

• 結對編程有利于編寫高質量代碼。
• 結對編程能增加代碼的可讀性和可維護性。
• 結對編程效率更高，而且錯誤更少，減少了后期維護需要的投入，從而直接間接地有利于整體進度。

21.3 正式檢查

正式檢查（即詳查）似乎是一個相當正規的存在，有著相當正規的流程。因為我們現在用不到，所以看得半懂不懂、也沒太多感想，先抄寫一下。
一些比較突出的點有：

• 詳查關注檢測錯誤，而非急于對其修正。
• 詳查者和代碼編寫者并非一人。

詳查的優點：
作者同樣給出了數據表明詳查能夠查出很多錯誤。另外，通過詳查，開發者可以更了解自己現有的方法有什么缺陷，如何改善工作。最后詳查還可以用來檢查進度。

詳查中的人員角色：

• 主持人。不一定需要是專家，但應該在技術上能夠理解詳查的各種細節。負責管理協調各方面工作，安排進度，還有一堆雜活。（從這些雜活就能看出來正式檢查真的很正式啊……）
• 作者。相對次要，主要在代碼不夠明晰時講解自己的代碼。
• 評論員。負責進行探討、找出問題。
• 記錄員。
• 經理。沒什么卵用，就是有時候人家想參加而已。

一般步驟：

• 計劃。一些雜活。
• 概述。作者陳述代碼設計及其技術背景。有時候這個階段可以忽略。
• 準備。各個評論員獨立地對代碼進行考察。要求每個評論員關注代碼的不同方面、特性往往能增加效果。
• 詳查會議。挑選某個人閱讀代碼或者順序解釋代碼邏輯，各個評論員提出自己認為的錯誤并進行討論。當確認一個錯誤確實是錯誤是就停止，而不要糾結于如何改正之類的問題。主持人應該把握節奏，不要太快也不要太慢。
• 詳查報告。
• 返工
• 跟進
• 在詳查會議之后，如果有人想討論解決方案，可以召開一個額外的半正式的小會議。

對于詳查，書中給出了一些小的建議。
首先，可以建立一個核對表，詳查過程中提醒評論員尤其注意某些錯誤。
其次，詳查不應該成為代碼的公開處刑。應該避免一些過于苛刻的評論，作者也不應該因為自尊心而袒護自己的代碼。

21.4 其他類型的協同開發

這里的技巧相對不那么正式，比較適合我們用。

走查

其實所有形式的復查都可以叫做走查……不過各種形式的復查都有一些共同點：

• 通常由代碼的作者主持。
• 焦點在于技術問題上。
• 和詳查一樣，重點在于檢測錯誤而非糾正錯誤。

走查的結果：

作者對走查的效果較為悲觀。好的情況下，走查的效果和詳查相近。然而很多情況下，非正式的走查效果很差。
對其原因，作者并沒有作出解釋。不過作者指出，走查盡管非正式，仍然需要很高的成本，所以假如認為復查的需求真的足夠迫切，就應該召開正式檢查而非走查。否則，應該采用閱讀代碼等交互性較低的方式。

代碼閱讀

準備階段：將源代碼交給閱讀人員。一般為1000 ~ 10000行，典型值為4000行。應安排兩個人以上閱讀代碼，以維持一定的競爭。一般要求每天閱讀1000行代碼。
會議階段：閱讀人員指出自己發現的問題并進行討論。
與詳查、走查區別在于，代碼閱讀注意力集中在發現的問題上，而不需要遍歷代碼。有人曾指出詳查會議的作用被高估了，大部分錯誤是在準備過程中發現的，而非討論過程中發現的。這個看法我比較認同，因為在會議上遍歷代碼時注意力可能處于一個較為分散的狀況，不像單獨閱讀時能夠注意思考邏輯。這樣可能更容易發現一些微妙的、有爭議的問題，但我不認為效率能和單獨閱讀代碼一樣高。

私以為這個方法對我們比較合適。

第二十二章 開發者測試

分類：

• 單元測試。通常只涉及單個程序員或開發團隊。
• 組件測試。似乎和單元測試差不多，不過會涉及多個程序員或開發團隊。
• 集成測試。對多個組件進行聯合測試，通常應該在有兩個可供聯合測試的類之后就盡快開始并持續到開發結束。
• 系統測試。主要針對安全、性能、資源消耗、時序、兼容性等問題。

我個人編寫測試時，有一些問題，比如這次結對編程作業中因為需要一定的隨機性，所以很難自動進行測試，而只能人工測試。不知這個問題如何解決。

22.2 測試對軟件質量的作用

事實上，測試檢查錯誤的能力沒有協同構建高，而且修正成本更高。

22.3 推薦方法

要點：

• 對模塊的每個需求進行測試，對常見的疏漏進行測試。如：安全級別、數據存儲、安裝過程、系統可靠性。（但是很多問題除非發生，否則根本想不到需要測試）
• 對每個設計的關注點進行測試。
• 基礎測試、數據流測試。
• 用檢查表記錄此前犯過的錯誤類型。

測試先行還是測試后行？

作者推薦測試先行。理由如下：

• 測試先行可以將需求先暴露出來，迫使開發者思考一下需求和設計。
• 編碼過程中更容易發現缺陷并改正。

開發者測試的局限性

• 開發者往往更傾向于引入會正確運行的測試樣例，而非會出錯的測試樣例。可能是因為受到了編碼思路的限制。
• 開發者容易對覆蓋率估計過于樂觀，忽略一些更復雜的測試類型。

22.3 測試技巧

不完整的測試

沒有測試能夠完整地測試每種情況，所以應該挑選最容易出錯誤的情況。

結構化的基礎測試

對于一個程序，至少應該對每個語句測試一次。如果是if或while，應該根據邏輯結構的復雜度增加測試，保證這個語句完全經歷了測試。

可以如此計算需要的最少測試：

• 順序結構數1。
• 遇if for while repeat and or之類的東西時，加一。也即，不僅各個分支需要進行測試，對于同一個布爾表達式中，若干個布爾值的不同組合方式也要測試。
• 對于case的各個情況，包括可能被省略的缺省狀況，分別加一。

數據流測試

數據有三種狀態：已定義（包括初始化）、已使用、已銷毀。
調用數據的子程序也有兩種狀態：已進入、已退出。

編寫測試前，首先要檢查保證沒有出現異常的數據狀態組合，如先使用后定義、多次定義、多次銷毀、局部變量定義后不使用便退出、使用已銷毀的變量等等。
然后，不同徹底程度的測試如：

• 覆蓋所有的定義。
• 覆蓋所有的定義與使用路徑。

這里書上講得比較模糊、我不太理解，所以我查找了一些別的資料。

我的理解中，數據流判準主要用于這樣的情況：一個子程序中調用其他子程序，或者順序調用若干個子程序時，它們由于共用數據會彼此依賴，而單純的單元測試可能難以發現因為數據上的依賴而形成的錯誤。
因此應該測試覆蓋某個數據從定義到使用到銷毀的各種可能路徑。
可以借助圖標，將數據的定義、調用等可視化，

然而個人看來，這樣的工作量非常大，看起來操作性沒有語句覆蓋、分支覆蓋強。之后嘗試一下，不知道實際意義如何。

猜測錯誤

參考下面幾個小節的常見錯誤。

邊界值分析

對于> max_num這類表達式，需要分析和測試剛好小于max_num、剛好等于max_num、剛好大于max_num三類情況。
也應該對類型允許的最大最小數字進行檢查。

隱蔽的邊界值分析：如果邊界值涉及若干個值，需要考察它們的極端情況。如要邊界值涉及若干個值的和，需要考察它們都很大、都很小的情況。

幾類壞數據

需要保證程序不會因壞數據發生超出預期的行為。如：
數據太少、數據太多、數據無效、長度錯誤、數據未初始化（這個在java里面比較突出）。

幾類好數據

也需要測試好數據。如：
中間的正常情況、最小的正常情況、最大的正常情況、與舊數據的兼容性。

建議采用容易手工檢查的測試數據

這個對我來說很實用，因為我經常自己算錯了還以為是測試的問題。
但是不應該因此就省略若干情況，依然應該盡量面面俱到。

TBC

因為這個章節講了很多查錯的技巧，整體上內容比較多，所以就先寫到這里了。
軟件質量這一部分大概也看了一大半，總結一下：作者整體上較為看好協同構建的方法，并認為測試的作用往往被我們高估。另外，在協同構建的方法中，作者推薦詳查（對于我們來說毫不現實）和閱讀代碼。

轉載于:https://www.cnblogs.com/jennawu/p/booknotesCodeCompleteVII.html

總結

以上是生活随笔為你收集整理的《代码大全2》读书笔记（七）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。