同學們已經了解了盡早發現缺陷的意義，那我們通過什么方法來發現缺陷呢，我想大部分同學都會說“測驗”，其實只對了一部分，的確測驗作為缺陷發現非常重要的一個手段，但不是全部，確切的說應該只是占了一小部分，因為還有一個非常重量級的選手 – 評審（Review），
測驗作為軟體開發中必不可少的階段，重要性不言而喻，而評審可以說無處不在，滲透到了我們軟體開發的各個環節，可以說：只要是成果物我們都可以對它進行評審，從而發現并消除缺陷，提高成果物的質量，比如：需求檔案，設計檔案，代碼，測驗用例等等，甚至是測驗計劃，風險管理計劃等計劃書，測驗會在后面的章節專門介紹，
記得大蝦的導師曾經說過：做得好的專案，往往都是review做得好的專案，這里的“好的專案”指的是質量好的專案，可見review在軟體質量中的作用，那么我們該怎樣進行評審呢，
會議評審 OR 單人評審
首先一起來了解下評審的形式，大蝦把評審分為兩種形式：會議評審（多人一般都采用會議形式），單人評審，在選擇評審的形式時，大蝦會綜合考慮成本，成果物影響大小及范圍，以及所處階段的不同時期等情況，
從成本角度，會議評審參加人數多，成本高，打個比方，有5個人參加評審會，1個小時的會議時長，等于總共消耗了團隊5個人時數，因此，可以看出會議評審的成本遠高于單人評審，相比單人評審，會議評審還有一個缺點就是溝通效率較低，會更加放大成本，試想一下一群人在那討論，一人一句就要花費更多的時間，還經常有人跑題太遠，把大家帶偏，驢都拉不回來，因此，會議效率非常重要，應該事先將材料發送給相關人員，最好大家帶著問題來參會，
從成果物影響大小及范圍角度，需求檔案能否反映用戶的真實需求，將直接影響軟體的質量，另外，需求檔案也是后續設計，開發，測驗的基礎，因此需求檔案影響非常大是不言而喻的；概要設計檔案涉及模塊間的互動，通常涉及多個人，甚至多個團隊，影響范圍廣，需要一起評審發現問題；詳細設計檔案涉及具體模塊的實作，影響范圍相對可控，并且通常由一個人來負責，因此，需求檔案，概要設計檔案通常采用會議評審，而詳細檔案可以采用單人評審，
從所處階段的不同時期角度，代碼評審初期，大蝦傾向于會議評審，讓所有開發人員參與，中后期更傾向于單人評審，因為專案初期，開發人員對代碼規約還不夠熟悉，代碼風格也存在較大的差異，如果不加以規范將影響軟體質量以及今后的維護，此外，代碼規約大都從組織或者外部渠道獲取，并通過“剪刀手”裁剪而來，還沒有經過專案實際檢驗，評審會議上很可能會對某個規范進行激烈的討論，找出更適合專案的規范，然而到了專案中后期，開發人員已經適應了代碼規范，代碼與規范存在的差異很小，可以使用單人評審，提高效率，
以上討論了評審的形式，接下來我們討論對成果物進行全評審，還是抽檢，
全評審 OR 抽檢
全評審成本較高，往往我們對某些成果物采用抽檢的方式，抽檢不僅能提高被抽檢成果物的質量，對未被抽檢的成果物也能間接提高質量，怎么說呢，試想一下，如果自己的代碼可能被抽到，在評審會上向大家展示并進行說明，有點廉恥之心的人都會按照代碼規約盡全力寫好代碼，是全評審，還是抽檢，大蝦通常綜合考慮以下兩點：1. 成果物的影響大小及范圍；2. 擔當者是否靠譜，
從成果物影響大小及范圍角度，大蝦通常只考慮對詳細設計檔案，源代碼，單元測驗用例進行抽檢，如果時間壓力不大，最好僅對源代碼進行抽檢，
從擔當者是否靠譜的角度，通常我們發現一個規律：靠譜的人提交的成果物質量明顯高于其他人，那么我們怎么才是知道誰靠譜，誰不靠譜呢，其實專案剛開始我們也無法知道誰靠譜，誰不靠譜，先從全評審開始，如果一個人能持續產出高質量的成果物，那么信任感就會增加，就會逐步減少對他成果物的評審，直至不評審，反之，如果一個人經常被評審出很多缺陷，那么就要加強對他成果物的評審，信任的建立程序非常緩慢，崩塌卻很快，大蝦希望同學們能用心對待自己的每一篇檔案，每一行代碼，每一條注釋，做個靠譜的人，
上面我們討論了評審形式，以及評審成果物范圍的選擇，對于評審人員的選擇我們就不詳細談了，比如：測驗用例評審會，一般都會有產品經理，核心開發人員或者開發全員參加，只要綜合考慮成本選擇必要的人員參加即可，
評審的標準 – Checklist
接著，我們一起討論下評審的標準，同學們是否有過這樣的經歷，當你把單元測驗用例發給Leader評審后，他指出了一些問題，當你改完這些問題，他再次評審后，他又指出了新的一些問題，再次修改后，又來了其他的新問題，這種情況是不是很讓人絕望，不僅內心備受打擊，而且來來回回浪費了很多時間，這種情況就是沒有確定評審標準帶來的后果，如果使用會議形式，不好的效果還會被放大，
那么如何讓大家用統一的標準進行評審呢，答案就是之前曾提到過的工具Checklist，比如：Checklist中列明：是否覆寫所有分支；是否覆寫邊界值；是否考慮null等等，大家參照Checklist就可以以相同的標準一條一條的確認了，因此，評審的時候一定別忘了好搭檔Checklist，Checklist工具非常強大，功能也不限于此，將在后面章節專門介紹，
其他
最后，我們一起討論下內部評審，從團隊的角度劃分，可以分為內部評審和外部評審，舉個例子，產品經理肯定不希望在PRD評審會上被指出一堆問題，尤其是一些簡單的問題，比如：檔案模版的一些必填項忘記填寫，字體大小不統一等等，因此，將檔案提交外部評審前，最好能進行下內部評審，大蝦建議內部評審除了評審邏輯外，更應當重視格式規范的評審，要是外部評審出一堆簡單的問題，肯定會質疑咱們的專業性，這也是大家最不想看到的，那么就請記得把這些規范都整理到內部評審的Checklist吧，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/403910.html
標籤：其他
上一篇：我的Python入門之路