Làm thế nào để tôi chọn mã nào để xem xét?

Tôi là thành viên của một nhóm gồm bảy nhà phát triển trong một công ty phần mềm nhỏ và tôi đang cố gắng giới thiệu mã nhóm và đánh giá thiết kế thường xuyên. Chúng tôi đã thực hiện một số đánh giá trong quá khứ, nhưng nó đã được lẻ tẻ. Tôi muốn làm cho nó một điều thường xuyên hơn.

Tôi đã đọc Code Complete và các tài nguyên tương tự khác và họ nói về các cơ chế về cách thực hiện đánh giá mã nhưng tôi không thể tìm thấy bất kỳ thực tiễn tốt nhất nào về cách chọn xem xét gì . Chúng tôi có một cơ sở mã đã hơn tám năm tuổi và bao gồm nhiều ngôn ngữ khác nhau, vì vậy có rất nhiều điều có thể được xem xét.

Dưới đây là một số yếu tố mà tôi có thể nghĩ đến có thể ảnh hưởng đến sự lựa chọn:

• Ngôn ngữ: C, Java, SQL, PL / SQL
• Mã tuổi: Mã mới so với mã cũ
• Sử dụng mã: Mã thường được sử dụng so với mã chết (ít hiệu quả)
• Mã quan trọng: Mã quan trọng so với mã không quan trọng
• Nhà phát triển: Mã nhà phát triển cơ sở so với Mã nhà phát triển cao cấp

Tôi hiểu rằng đây không phải là một câu hỏi với câu trả lời dứt khoát tuyệt đối, nhưng bất kỳ hướng dẫn nào cũng sẽ hữu ích.

Một số câu hỏi liên quan đến ngoại vi:

• Phương pháp xem xét mã (Đề cập đến việc xem xét các phần quan trọng và mã nhà phát triển mới)
• Chúng ta có nên thử xem lại tất cả mã của mình không?

Nói chung, bạn phải xem lại mọi thứ . Nếu một ứng dụng mới có 2 000 LỘC, tất cả 2 000 LỘC phải được xem xét.

Đó là lý do tại sao không có cách thực hành tốt nhất về cách chọn những gì cần xem xét.

Nếu bạn tiếp cận một cơ sở mã lớn hiện có, chưa bao giờ được xem xét trước đó, thì đó là điều tương tự khi bạn phải viết lại một cơ sở mã lớn hiện có và chọn nơi bắt đầu. Nó phụ thuộc mạnh mẽ:

• trên cơ sở mã (một mã nguyên khối đơn lẻ sẽ khó viết lại / đánh giá hơn một bộ các thành phần riêng biệt, v.v.),

• bối cảnh của bạn (bạn có thể dừng mọi thứ bạn làm và dành ba tháng (ba năm không?) chỉ làm việc để viết lại / đánh giá, hoặc bạn phải làm điều đó bằng những vòng nhỏ, chỉ khi bạn có thời gian rảnh)?

• loại đánh giá bạn làm (bạn có một danh sách kiểm tra những thứ cần xem xét không? Tùy thuộc vào các mục của danh sách kiểm tra, bạn có thể muốn xem lại một số phần trước).

Nếu tôi là bạn tôi sẽ:

• theo nguyên tắc 80% -20%, được đề cập trong bình luận đầu tiên của câu hỏi thứ hai mà bạn liên kết đến.

• hãy tính đến 100%, là một lý tưởng, có lẽ không đáng. Nó giống như phạm vi bảo hiểm mã 100% cho các thử nghiệm đơn vị, ngoại trừ việc bảo hiểm mã như vậy hầu như không thể hoặc cực kỳ tốn kém.

• bắt đầu với các phần của mã bạn sử dụng nhiều nhất và là phần quan trọng nhất. Nếu codebase có một thư viện xác thực và đăng ký người dùng mới trên trang web công ty của bạn, trước tiên hãy xem xét nó, bởi vì bạn chắc chắn muốn tìm thấy lỗ hổng bảo mật trước khi tin tặc làm.

• sử dụng các số liệu hiện có để xác định những gì quan trọng hơn để xem xét. Nếu một phần của cơ sở mã không có bài kiểm tra đơn vị nào, trong khi phần khác, phần quan trọng không kém, có độ bao phủ mã 85%, hãy bắt đầu bằng cách xem lại phần đầu tiên. Nếu một phần của cơ sở mã được viết bởi một nhà phát triển được biết là thiếu kinh nghiệm và giới thiệu nhiều lỗi hơn bất kỳ đồng nghiệp nào, hãy bắt đầu bằng cách xem lại mã của anh ta trước.

Bắt đầu bằng cách xem xét tất cả các thay đổi bạn thực hiện đối với mã; Điều đó sẽ ngăn chặn vấn đề trở nên tồi tệ hơn. Sau đó bắt đầu xem xét mã dựa trên tần suất thay đổi; đây sẽ là những khu vực 'vấn đề'.

Bạn sẽ muốn tìm ra một số cách để theo dõi rằng bạn đã xem xét một phần của mã để bạn có thể phân tích phạm vi đánh giá của mã của mình so với các mối quan tâm khác.

Nếu bạn có thể xác định mã nào không nằm trong các thử nghiệm của mình, mã đó sẽ trở thành ưu tiên cao hơn để xem xét.

Xem lại tất cả các thay đổi mới đã được thực hiện trước khi chúng được đưa vào sản xuất. kịch bản cài đặt, mã nguồn, thay đổi cơ sở dữ liệu, tất cả mọi thứ! Toàn bộ quan điểm của việc xem xét mã là ngăn chặn mã xấu đưa nó vào sản xuất. Có thể là một sơ đồ tổ chức kém hoặc đơn giản là một lỗi được giới thiệu bởi vì một cái gì đó đã bị bỏ lỡ.

Tái cấu trúc mã hiện tại bạn đang làm việc đi đôi với xem xét mã. Ví dụ: khi tôi đang xem xét mã, nếu có mã trùng lặp trong một lớp có sửa lỗi, ngay cả khi nhà phát triển không thay đổi mã đó trong bản sửa lỗi của họ, tôi sẽ không vượt qua. Tôi sẽ có họ quay lại và loại bỏ mã trùng lặp.

Nếu bạn tái cấu trúc không ngừng thì việc xem lại mã sẽ trở nên hữu ích. Nếu không thì thật lãng phí thời gian.

Nếu bạn kết hợp quy trình xem xét mã như một bước trong quy trình phát triển của mình, cơ sở mã sẽ trở nên tốt hơn theo thời gian. Tốt hơn nữa, bạn không nên cho phép các nhà phát triển của mình đảm nhận công việc tính năng mới hoặc sửa lỗi cho đến khi tồn đọng mã xem lại mã. Điều này đảm bảo rằng việc xem xét mã được thực hiện.

Nếu có những khu vực đã biết cần được tái cấu trúc, nhưng sẽ mất nhiều thời gian để thực hiện chúng (tức là 1 tuần trở lên). Sau đó, tạo một mục công việc để tự tái cấu trúc và thêm nó làm mục để xử lý.

Bắt đầu bằng cách xem lại tất cả mã mới và sửa đổi mã hiện có.

Khi xem xét sửa đổi mã hiện có, nhà phát triển nên tuân theo quy tắc tẩy chay. Để lại mã tốt hơn anh ta tìm thấy nó.

Điều đó không có nghĩa là bạn phải sửa toàn bộ tập tin để trở nên hoàn hảo. Nhưng nó không nên thêm vào mớ hỗn độn, nó sẽ làm cho nó tốt hơn một chút. Có lẽ bằng cách di chuyển các sửa đổi vào các lớp mới được cấu trúc đúng và để phần còn lại của tệp mã gốc như cũ (sau tất cả, nó đang hoạt động).

Khi bạn bắt đầu cải thiện mã bằng cách xem xét tất cả mã mới và sửa đổi, với tư cách là nhà phát triển, bạn nên biết khu vực nào của ứng dụng yêu cầu thay đổi nhiều nhất. Sau đó, xem lại những điều đó, thảo luận về cách chúng có thể được cải thiện, từng chút một.

Xem xét mã được viết 10 năm trước, vì mục đích xem xét nó, là vô nghĩa, nhà phát triển nên đã cải thiện trong 10 năm đó. Vì vậy, không có điểm nào để xem xét nó chỉ để tìm hiểu những gì bạn biết.

Mục đích của đánh giá mã là để cải thiện và sửa chữa những sai lầm bạn hiện đang mắc phải và chia sẻ kiến ​​thức đó giữa các nhóm.

Trong dự án của tôi, chúng tôi bao gồm đánh giá mã là điều bắt buộc trong hầu hết các trường hợp cho bất kỳ câu chuyện / lỗi người dùng / lỗi nào đang được phát triển. Chúng tôi đang sử dụng các quy trình scrum / agile và vé / câu chuyện không được chuyển sang xây dựng (đó là tồn đọng cho QA) cho đến khi các bài kiểm tra đơn vị được viết và hoàn tất đánh giá mã.

Chúng tôi sử dụng phân tích Atlassian FishEye với đánh giá mã Crucible được tích hợp với JIRA + SVN cho mục đích này.

Khi nhà phát triển kiểm tra mã trong một câu chuyện cụ thể, anh ta tạo một đánh giá mã mới trong FishEye, nơi anh ta chọn các thành viên khác trong nhóm để thực hiện đánh giá.

Sau khi hoàn tất đánh giá mã, (công cụ nêu bật các thay đổi được gửi và cho phép để lại nhận xét cho dòng mã cụ thể), nhà phát triển sửa các vấn đề được đề cập / thực hiện các cải tiến được đề xuất và chuyển vé vào cột Được xây dựng trong JIRA - điều đó có nghĩa là câu chuyện sẵn sàng để được kiểm tra và không có nhiều thay đổi mã dự kiến ​​cho mục công việc cụ thể này.

Điều này cũng đảm bảo QA không kiểm tra bất cứ điều gì có thể thay đổi và có khả năng bị phá vỡ trong khi tái cấu trúc mã sau khi xem xét mã .

Tóm lại, tất cả các mã phải được xem xét - điều này hỗ trợ chất lượng mã cao, thường dẫn đến thiết kế tốt hơn, dễ đọc, khả năng bảo trì và kiểm tra mã và cải thiện hiệu suất phát triển trong thời gian dài.