共用方式為


進行設計和程式碼檢閱的方針

下列方針會提供數個設計和程式碼檢閱的技巧。

必要條件

  • 安排時間進行檢閱。

    檢閱的目的是小心謹慎地了解並分析設計和程式碼。 請至少花費您撰寫程式碼或規劃設計之一半的時間,做檢閱的動作。

  • 讓檢閱者主導檢閱。

    檢閱者與其意見必須主導檢閱過程。 如果讓程式開發人員主導自己工作的檢閱程序,則其他的檢閱者可能會忽略潛在的問題。

  • 在檢閱會議之前,先行閱讀程式碼或設計文件。

    除非會議是要檢閱某些較細微的變更,否則請事先做好準備。 檢閱者事前沒有閱讀程式碼或設計文件的檢閱會議,是在浪費所有與會人員的時間。

  • 使用 Team Project Portal 進行群組檢閱。

    將設計文件發行至專案入口網站,讓每個人都能輕易找到並檢閱這些文件。 將所發行之文件的指標傳送給檢閱者,並要求他們使用 Internet Explorer 討論功能加上註解。 如果要使用類似的方式檢閱您的程式碼,請將程式碼貼到 Word 文件,並將此文件也發行至 SharePoint 網站。 如需詳細資訊,請參閱計劃和追蹤專案

  • 使用檢查清單。

    在進行檢閱時,如果專注於某些方面像是安全性、錯誤處理或風格,很容易導致離題。 在完成某一方面的檢閱後,您可能會急著要進行別的工作。 檢查清單可以提醒您檢閱中必須涵蓋的眾多其他層面。

  • 追蹤在程式碼檢閱期間找到的所有問題。

    將問題記錄為工作項目、程式碼中的註解或設計文件中的問題。 否則,之後可能會忘記這些問題,而您在程式碼檢閱中投入的時間就不會得到回報。 如需詳細資訊,請參閱 建立工作項目

請避免

  • 在不通知檢閱者的情況下,變更程式碼或設計。

    您可能在送出設計或程式碼供檢閱之後才發現缺失,此時就必須克制想要在檢閱會議之前修正問題的衝動。 如果在會議之前變更程式碼或設計,屆時整個檢閱過程將會變得令人疑惑,而且檢閱者很可能會因此而不悅。 反之,以檢閱者的身分來對待找到的錯誤,將錯誤標示出來,並和其他檢閱者的註解一起進行追蹤。

建議使用

  • 包含各部門的代表。

    雖然讓開發人員以外的各部門成員檢閱設計和程式碼並不一定是可行的,但是來自各部門的代表可以幫忙發現不容易注意到的問題。 每個部門推選一至兩人就已足夠, 超過此數目反而會使檢閱過程變得冗長並且難以管理。

  • 檢閱所有的程式碼和設計。

    若要讓產品具有高品質,請檢閱所有工作的程式碼和設計。 在檢閱過程一開始時便應該包含程式碼分析、單元測試和設計文件。

  • 考慮建立擱置集來管理程式碼檢閱。

    您可以建立只包含要檢閱者檢查之變更的擱置集。 當您建立擱置集時,會與檢閱者共用變更,而不須將這些變更簽入版本控制。 如需詳細資訊,請參閱使用擱置集

請參閱

概念

使用程式碼分析工具進行應用程式品質分析

使用 Team 專案簽入原則強化程式碼品質