程式碼審查 (Code Review) 的最佳實務
成功的同儕審查策略需在嚴謹的流程與無壓力的協作環境之間取得平衡。過於制式化的同儕審查可能會抑制生產力，而過於鬆散的流程則往往無效。管理者需負責找出中間點，使同儕審查既高效又具成效，同時促進團隊間的開放溝通與知識分享。 有效執行同儕程式碼審查的 10 個實用技巧 1. 每次審查不超過 400 行程式碼根據 SmartBear 對 Cisco Systems 開發團隊的研究顯示，開發人員每次審查的程式碼行數應控制在 200 至 400 行之間。人腦一次能有效處理的資訊有限，超過 400 行後，找出缺陷的能力會顯著下降。 實務上，花 60 到 90 分鐘審查 200～400 行程式碼，通常可發現 70% 至 90% 的缺陷。換句話說，若該段程式碼中存在 10 個缺陷，正確執行的審查可找出其中 7 到 9 個。 2. 慢慢來——檢查速度應低於每小時 500 行程式碼（LOC） 在進行審查時，很容易會想快速瀏覽、認為其他人會補捉到自己錯過的錯誤。然而，SmartBear 的研究指出，當審查速度超過每小時 500 行程式碼時，缺陷密度的發現率會大幅下降。 以合理數量、較慢速度、在限定時間內進行的程式碼審查，能達到最有效的結果。 3. 每次審查時間不宜超過 60 分鐘就像不應該過快地審查程式碼一樣，也不應該一次審查太久。當人們長時間進行需要高度專注的活動時，約在 60 分鐘後表現就會開始下降。研究顯示，適時從任務中休息，有助於顯著提升工作品質。頻繁進行較短時間的審查，可減少未來需要進行長時間審查的情況。 4. 設定目標並蒐集衡量指標在導入審查流程之前，您的團隊應先決定如何衡量同儕審查的成效，並訂定幾個具體可行的目標。 建議使用 SMART […]
為何 Peer Review (同儕審查) 是軟體開發中的關鍵步驟
Peer Review 同儕審查，也可稱作交叉檢查 程式碼審查 (Code Review) 作為一種提升與控管品質的策略，其效益已廣泛獲得認可。開發社群現在普遍理解程式碼審查對整體軟體品質的影響——也就是在程式碼交付給 QA 進行測試之前，能先行發現並修正錯誤與問題的能力。 Peer Review 同儕審查為軟體開發導入了一定程度的品質控制實務，讓團隊能夠及早且頻繁地檢視開發過程中的各項產物。能夠輕鬆且徹底地審查這些文件，對於確保團隊資訊一致至關重要，尤其是在面對客戶臨時需求或變更要求時更是如此。擴編後的開發團隊也必須理解需求變更對開發工作量、任務管理與版本管理等各方面所造成的影響。 持續性地審查所有開發產物，有助於團隊達成專案目標與交付時程的要求。 工具輔助讓同儕審查更快速、更輕鬆 透過工具輔助的同儕審查，能免去排定會議的麻煩，同時更容易針對程式碼與重要技術文件給予回饋。像是 Collaborator 這類工具可協助審查者在最新版本的文件上直接註解與留言，節省處理 Microsoft Word 或 PDF 審查所需的意見彙整流程。 這些工具也能追蹤文件版本間的變更，讓團隊成員了解目前文件的演進歷程。藉由讓成員能共同參與文件與產物的製作過程，工具輔助的同儕審查不僅強化了對最終目標（例如：欲開發的軟體）的共識，也可節省時間、降低風險，並創造實質價值。 大型 IT 組織更需要同儕審查 (Peer Review) 專注於大型 IT 專案的開發組織深知這一點！當他們面對緊縮預算、壓縮時程與人員流動頻繁的挑戰時，更常遇到來自團隊地理分散與虛擬協作所帶來的溝通斷層，以及開發產物狀態不明、缺乏可執行見解的困境。在這樣的情境下，能夠以協作方式審查產物，有助於打破資訊孤島，協助所有人如期達成進度與預算目標。 團隊應審查的產物類型 任何軟體開發專案背後都有各式各樣的文件與產物。即使是 Agile 團隊，也同樣仰賴這些文件來推動 sprint 進行。邀請擴展團隊成員，如開發人員、產品經理與產品負責人、品質保證工程師、支援人員與技術文件撰寫者，共同提供意見與回饋，有助於提升最終產品的品質，並降低技術債與重工的風險。 以下文件特別適合進行同儕審查： 若您想進一步了解當前的程式碼審查趨勢，歡迎參閱《2018 年程式碼審查現況報告》。 文章來源: Why Peer Review is a Critical Step in Software Development, SmartBear 2012
什麼是產物審查 (Artifact Review)？
品質優良的軟體始於程式碼審查 (code review)，但品質不僅止於程式碼本身。文件與各種產物 (artifact) 同樣需要適當的關注，才能確保沒有任何環節被忽略。若要確保軟體品質，就必須對程式碼審查過程中所留下的軟體產物 (software artifact) 進行審查。 如果說程式碼審查 (code review) 是像吃蔬菜一樣不那麼吸引人的任務，那麼產物審查 (artifact review) 就像是每天走滿一萬步。兩者也許都不那麼有趣，但對您（和您的軟體）健康都有長遠的好處，只要持之以恆。 那麼，該審查哪些產物呢？如果您造訪我們的《2021 軟體品質現況｜程式碼審查》專題網站，就會看到產物審查涵蓋的範圍相當廣泛。除了最基本的程式碼，這些產物還可能包括需求文件（最常見）、測試案例、User story、設計文件等。 上圖為受訪者所審查之軟體產物的統計圖資料來源：State of Software Quality｜Code Review 2021 如圖所示，除了「示意圖（schematics）」維持相對穩定外，其餘所有產物的審查比率皆呈現上升趨勢。特別是「需求」的顯著成長並不令人意外，因為連續第三年，受訪者皆指出「需求變更」是他們準時交付版本的最大挑戰。 那麼，為何像「需求」這類產物會如此關鍵並帶來巨大影響呢？因為進行高品質審查需要清楚的審查準則，而這也關係到程式碼的品質。隨著軟體各領域的交付節奏加快，審查流程中的需求也必須不斷重新檢視與定義，以確保準時交付。 此外，還有許多因素也在發揮影響力，例如地理分布分散的團隊、遠距工作趨勢、產業變化等。從事程式碼與文件審查的團隊需要一套同時支援「產物審查」的工具，以免忽略如需求這類至關重要的要素。 如何評估一套審查平台 在理想的情況下，單一平台應能同時完成三大核心任務：程式碼審查 (code)、文件審查 (document) 與產物審查 (artifact)。一個整合式的同儕審查 (peer review) 平台能全面涵蓋這些重點，確保在審查流程中不遺漏任何關鍵內容。 審查流程因企業甚至不同團隊而異。具備可自訂的同儕審查工作流程，能依據團隊與組織需求建立清晰的稽核軌跡，妥善地掛載與追蹤軟體產物的驗證過程。這能提升準確性、降低錯誤，並簡化整體流程。您的產物審查將能從一開始就驗證並完成需求，且有完整稽核紀錄可供查閱。所選用的同儕審查工具必須具備這些功能，才能有效維護團隊問責機制並達成上述目標。 此外，開發人員應具備撰寫與維護高品質應用程式需求的能力。準確的需求能帶來更少的程式缺陷、更清晰的測試案例，也能讓軟體交付過程省時省力。同時保留過程中的版本紀錄，也將是一項極具價值的資產。 Collaborator 的角色 Collaborator 的設計初衷在於推動實質的團隊協作，同時建立簡便的稽核軌跡。這是一套針對文件與原始程式碼審查所打造的客製化解決方案，能讓您根據 SDLC 定義出最佳實務的審查流程。無論您希望設定固定的簽核人數、涵蓋特定職能人員，或其他客製化需求，都可靈活設定。更進一步，它可與 Jira 等外部工具整合，具備良好延伸性。 由於 Collaborator 能同時處理文件與程式碼審查，許多組織已選擇將其作為 SDLC 審查平台的首選工具。他們希望透過單一工具，整合程式碼、文件與產物審查，同時支援多個團隊與系統的串接。 Collaborator 在行政管理面也帶來助益：團隊無需學習或管理兩套工具，整體環境更簡化。工具越簡單，越容易實現統一的流程與單一供應商合作帶來的好處。 最後，對許多團隊而言，從審查過程中產出的報告是衡量成效的關鍵。團隊是否在同儕審查中達到預期成果？是否減少缺陷？是否蒐集到符合法規的資料？「成功」的定義可因組織而異，Collaborator 提供的彈性，可協助組織依自身需求進行報告管理。 […]
什麼是文件審查？
在軟體開發生命週期（SDLC）的背景下，文件審查能讓組織更有效地策劃、治理及管理數位產物的生命週期，而不僅限於原始程式碼。 這些數位產物包括文件、試算表、簡報、影像檔、系統與架構圖，以及與軟體專案相關的其他檔案。文件審查在受法規規範的產業中常被採用，或用於有品質認證要求的情境。即便不受法規限制，許多組織也會透過文件審查來聚焦於品質。 文件審查有助於整體品質的提升、改善客戶體驗，或強化風險管理，甚至還能降低人力成本等支出。 選擇文件審查平台時應注意哪些要素？ 理想的文件審查平台應同時支援程式碼與文件的審查，讓您能依循最佳實務需求，管理完整的審查與驗證流程。 透過平台附加並追蹤產物驗證的工作流程，可以提高準確性、降低錯誤率，並為治理控制提供基準。您的文件審查流程將能從最早期便驗證需求是否被滿足與完成——或至少極為接近。 此外，開發人員應能撰寫並維護高品質的軟體應用程式需求。準確的需求能轉化為更少的程式錯誤、更乾淨的測試，而當組織減少缺陷出貨時，也能節省大量時間與精力。更不用說，在整個流程中保留的歷史版本，往往是極具價值的紀錄。 「巴士理論」與審查制度的重要性 建立明確的文件審查流程，在變更管理上具備一大優勢：讓所有利害關係人都能掌握變更的背景脈絡。瞭解變更內容愈多，風險空間愈小。這與所謂的「巴士理論」有關，其核心假設是：若有若干人遭遇意外（如被巴士撞），剩下的人是否知道事情該如何進行？ 例如，若只有一位分析師撰寫需求，且她是唯一知情者，萬一她發生意外（或離職、退休），團隊就得重新向客戶確認原始需求，這將造成極大問題。 當然，我們希望客戶能體諒分析師的處境，但你可以理解這樣的風險：開發進程將嚴重延誤。反之，若該分析師的作業有其他成員參與，即使她突然離開，其他人也能掌握整體狀況。 換言之，這有助於降低員工流動帶來的風險，防止知識斷層，因為原有的「部落知識」已有文件佐證。 回到選擇文件審查系統的關鍵重點 系統應能對變更對品質的影響提供有序的控制。在軟體開發中，變更是不可避免的，但只要需求能被妥善管理並讓所有人保持共識，利害關係人就能有效更新資訊並與團隊溝通，從而降低對品質的重大衝擊及其相關的成本與風險。 Collaborator 如何提供協助？ 首先，Collaborator 的設計初衷正是為了滿足上述所有需求。這是一套針對文件與原始程式碼審查所打造的客製化解決方案，能讓您在軟體開發生命週期（SDLC）中定義符合最佳實務的審查流程。無論您的流程需要特定人數的簽核、不同職能人員的參與，或其他審查配置，Collaborator 都具備完全可調整的能力。而且，它也具備延伸性，可整合 Jira 等外部工具。 由於同時支援文件與程式碼的審查，許多組織選擇將 Collaborator 作為 SDLC 中的主要審查平台。他們需要一套能同時處理兩者的工具，並支援多個團隊、串接多個系統。 從管理面來看，Collaborator 也能降低行政負擔。如果不需要學習如何設定兩套工具，或不需負擔兩套系統的維運成本，整體環境就能簡化。使用單一供應商與統一作業流程，也會帶來明顯效益。 最後，對許多團隊來說，審查過程的報表功能是衡量成功與否的關鍵。例如：團隊在同儕審查中的表現是否良好？是否有效減少了缺陷的發現與釋出？是否收集到符合法規要求的資料？「成功」的定義可能因組織而異，因此 Collaborator 提供靈活度，讓團隊可依自身的報告需求進行管理。 了解更多 希望這篇對於文件審查的簡要介紹、其主要效益，以及 Collaborator 的協助方式，對您有所幫助。 若您想深入了解，歡迎點擊此連結，觀看我們的隨選網路研討會，了解更多關於 Collaborator 的細節，以及如何透過文件審查提升品質。 如果您偏好閱讀研究資料，也對同業如何看待文件審查感興趣，不妨參考《2020 年程式碼審查現況調查》。該研究由 700 多位軟體專業人士參與，深入探討文件與程式碼審查的頻率、工具使用與程式品質。 若您已準備好深入了解如何立即在組織中導入 Collaborator，歡迎透過此處聯繫我們的業務團隊。 文章來源: What is Document Review? SmartBear 2021