Tiêu chuẩn để xem xét mã là gì?

Đánh giá mã là quá trình ủy quyền một cách có hệ thống một hoặc một số nhà phát triển xem lại mã do nhà phát triển khác viết để phát hiện lỗi và cải thiện nó. Đánh giá mã thường được thực hiện bởi một nhà phát triển có kinh nghiệm xem xét các khía cạnh khác nhau bao gồm chất lượng và tính bảo mật của mã, chia sẻ kiến ​​thức, cho phép cộng tác tốt hơn, xây dựng văn hóa đánh giá, tạo niềm tin cho Nhóm về mã họ đang làm việc

Chi phí đánh giá mã

Ngoài việc xem xét mã, có hai phương pháp nổi tiếng khác để hợp lý hóa quy trình phát triển

• Viết bài kiểm tra để thực hiện thường xuyên và tự động mã được viết và tái cấu trúc
• Sử dụng các công cụ kiểm tra mã để tự động tìm mã và lỗi

Không giống như các công cụ kiểm tra và phân tích, việc xem xét mã do con người thực hiện có thể được coi là một nhiệm vụ khói. Từ khói được sử dụng tương tự với thử nghiệm khói tôi. e đã thực hiện kiểm tra theo cách thủ công để nhanh chóng xác thực một điểm cụ thể. Test như vậy coi như khói vì khi code thay đổi thì phải thực hiện lại, y hệt như code review. Vì lý do đó, việc xem lại mã là một nhiệm vụ tốn kém vì nó tiêu tốn nguồn nhân lực và nó phải được lặp đi lặp lại sau mỗi lần thay đổi mã.

Lợi ích đánh giá mã

Chi phí xem xét mã cao. Mặt khác, lợi ích của việc xem xét mã là có thật

• Giáo dục. Với đánh giá mã, cấp dưới nhận được lời khuyên từ các lập trình viên cấp cao trong bối cảnh mã của chính họ. Không có cách nào tốt hơn để tìm hiểu các phương pháp phù hợp và quảng bá các nguyên tắc và yêu cầu về quy tắc của công ty
• Liên lạc. Với các lập trình viên đánh giá mã nhất thiết phải nói chuyện với nhau và chia sẻ ý kiến. Làm như vậy sẽ thúc đẩy sự đồng hành và cải thiện sự gắn kết của nhóm.  
• Kiến thức lan tỏa. Mọi nhóm nên đấu tranh chống lại quyền sở hữu mã i. e khi một người sở hữu cơ sở mã hoặc thành phần. Quyền sở hữu mã đang gây ra xích mích và căng thẳng, cho cả chủ sở hữu và đồng nghiệp của họ. Chủ sở hữu không còn học hỏi từ những người khác và có thể trở nên lười biếng vì công việc của nó không được người khác đánh giá. Mặt khác, những người khác có thể gặp rắc rối lớn khi chủ sở hữu vắng mặt hoặc nếu anh ấy / cô ấy rời đội. Đánh giá mã là cách thực hành tốt nhất để truyền bá kiến ​​thức và ngăn chặn quyền sở hữu mã
• Động lực để tiến bộ. Rõ ràng là nếu bạn ghi nhớ rằng mã của bạn sẽ được một số đồng nghiệp xem xét, bạn sẽ quan tâm nhiều hơn đến nó. Bạn sẽ dành thời gian để đặt tên chính xác cho các định danh, viết bài kiểm tra, giới thiệu các bản tóm tắt phù hợp và sử dụng cẩn thận các mẫu toàn doanh nghiệp
• mã tốt hơn. Bởi vì trí thông minh, kinh nghiệm và sự chú ý của nhà phát triển là cốt lõi của việc xem xét mã, nó có thể giúp phát hiện sớm các lỗi không thể phát hiện được thông qua thử nghiệm và công cụ

Với việc xem xét mã, không chỉ mã kết quả trở nên tốt hơn mà mọi người đều cải thiện với tư cách là nhà phát triển. Những lợi ích liên quan đến con người không thể có được thông qua một thực hành khác. Tuy nhiên, họ có thể tạo ra sự khác biệt giữa một dự án thành công và một dự án thất bại. Do đó, bạn phải nghiêm túc xem xét mã có hệ thống để nhận thấy rằng Lợi tức đầu tư (ROI) của nó là thuận lợi

Cách thực hiện đánh giá mã

Thông báo rằng một số mã đã sẵn sàng để được xem xét

Thường thì việc xem xét mã được tiến hành theo cách không chính thức. Khi một nhà phát triển kết thúc phiên mã hóa, anh ta sẽ thông báo cho một hoặc một số thành viên trong nhóm để xem lại khi họ có thể. Đây là một sự khởi đầu nhưng làm như vậy là không có hệ thống, không thể theo dõi cũng như không đo lường được

Đánh giá qua vai

Không giống như cách thông báo trước đây, đánh giá tổng thể liên quan đến đánh giá đồng bộ. Nó bao gồm việc yêu cầu một hoặc một vài nhà phát triển tham gia để trình bày cho họ công việc đã hoàn thành và thu thập nhận xét. Lý tưởng nhất là họ tham gia trực tiếp nhưng ngày nay, nhiều nhà phát triển làm việc tại nhà và việc đánh giá như vậy có thể được thực hiện từ xa. Đánh giá qua vai chịu cùng một nhược điểm không chính thức của cách thông báo trước đây. Tuy nhiên, nó khuyến khích nhà phát triển tham gia vào một cuộc thảo luận thực sự chứ không chỉ là một chuỗi thư khác, điều này tốt cho việc xây dựng nhóm

Lập trình cặp

Lập trình cặp là một cách tiếp cận phát triển phần mềm Agile xuất phát từ XP (Lập trình cực đoan). Lập trình cặp bao gồm hai nhà phát triển nhóm với nhau trên một máy tính. Họ tham gia nỗ lực viết mã và kiểm tra. Đây là một hình thức đánh giá mã vì có một bàn phím duy nhất. một người đang xem lại mã được viết bởi người kia

Lập trình cặp có một số lợi thế. Đây là một cách tuyệt vời để cố vấn cho một nhà phát triển cơ sở và phát hiện một số lỗi càng sớm càng tốt

Mặt khác, các nhà phát triển thường đạt năng suất cao nhất khi họ ở một mình, trong vùng dòng chảy và không bị gián đoạn. Do đó, lập trình cặp có hệ thống có thể làm giảm năng suất và khiến các nhà phát triển ít nhiệt tình hơn. Mã được viết bởi một nhà phát triển duy nhất trong khu vực dòng chảy vẫn có thể được những người khác xem xét và cải thiện sau này

Công cụ trợ giúp cho Đánh giá mã

Công cụ đánh giá mã giúp rất nhiều để cải thiện quy trình đánh giá. Với công cụ đánh giá có thể trở nên có hệ thống. Chúng có thể được theo dõi và một số số liệu có thể được suy luận để cải thiện quy trình. Các yêu cầu kéo của Github hiện đang phổ biến để thực hiện hầu hết các nhu cầu đánh giá. Ngoài ra còn có các công cụ tinh vi hơn như SmartBear Collaborator với nhiều loại SCM (Quản lý kiểm soát nguồn) được hỗ trợ

Tuy nhiên, nhược điểm của code review là chi phí cao vì nó đòi hỏi nhiều nỗ lực của con người. Đây là lý do tại sao nhóm phải đấu tranh để tự động hóa quá trình xem xét trên diện rộng để thu hẹp sự can thiệp của con người vào những điểm thiết yếu. Để làm như vậy, công cụ NDepend phân tích nhiều khía cạnh của mã như đặt tên, độ phức tạp, thiết kế, mùi mã, mức độ bao phủ mã bằng các bài kiểm tra… và tạo ảnh chụp nhanh. Hai ảnh chụp nhanh có thể được so sánh. Một số truy vấn dựa trên C# LINQ giúp dễ dàng truy vấn bất kỳ thứ nguyên nào trong vùng đồng bằng giữa hai ảnh chụp nhanh được so sánh. Dưới đây là một số truy vấn mẫu

Trước bất kỳ đánh giá nào của con người, các nhà phát triển có thể buộc phải tránh làm cho các phương thức vốn đã phức tạp trở nên phức tạp hơn nhờ truy vấn bên dưới. Lưu ý tiền tố warnif count > 0 biến truy vấn thành quy tắc. Bằng cách này, các kết quả phù hợp của truy vấn trở thành vấn đề cần khắc phục

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

// Avoid making complex methods even more complex

cảnh báo đếm > 0

từ m ở JustMyCode. Phương pháp ở đâu

!m. IsAbstract &&

  m. IsPresentInBothBuilds() &&

  m. Mã đã thay đổi() &&

  m. Phiên bản cũ hơn(). Độ phức tạp theo chu kỳ > 6

hãy delta = m. Độ phức tạp theo chu kỳ - m. Phiên bản cũ hơn(). Độ phức tạp theo chu kỳ

ở đâu delta > 0

theo thứ tự delta giảm dần

chọn mới {

   m,

   m. Phiên bản mới hơn(). Độ phức tạp theo chu kỳ ,

   delta ,

}

Có thể dễ dàng viết một quy tắc để buộc mã bao phủ 100% bằng các thử nghiệm trên tất cả các lớp mới được viết. Nhưng chắc chắn các nhà phát triển sẽ thấy nó hơi cực đoan vì một số mã như mã UI khó có thể được kiểm tra

Tuy nhiên họ chắc chắn sẽ chấp nhận quy tắc này. Các loại đã từng được bao test 100% vẫn nên được bao 100%. Chúng ta có thể tự hào khi một lớp được bao phủ 100% vì điều đó có nghĩa là lớp đó được thiết kế tốt vì nó có thể kiểm tra đầy đủ. Phạm vi bảo hiểm 100% cũng có nghĩa là nếu lớp có lỗi, có thể dễ dàng điều chỉnh các bài kiểm tra đơn vị để sao chép nó nhằm sửa lỗi. Sau khi sửa lỗi, với phạm vi bảo hiểm đầy đủ, thật dễ dàng để viết một hoặc một số bài kiểm tra để xác nhận sửa lỗi. Tuy nhiên, chúng tôi cần một cách để ngăn chặn các lỗi mới xuất hiện trong một lớp được bảo hiểm 100%. Và quy tắc này giúp ích rất nhiều vì nó phát hiện ra lỗ hổng mới trong phạm vi bảo hiểm của lớp. Kinh nghiệm cho thấy lỗ hổng mới trong phạm vi thử nghiệm hầu như luôn làm sáng tỏ một số sự thật thú vị – nếu không muốn nói là lỗi – đòi hỏi sự chú ý của nhà phát triển

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

// Types that used to be 100% covered by tests should still be 100% covered

cảnh báo đếm > 0

từ t ở JustMyCode. Các loại ở đâu

   t. IsPresentInBothBuilds() &&

   t. Phiên bản cũ hơn(). Tỷ lệ phần trăm Bảo hiểm == 100 &&

   t. Tỷ lệ phần trăm Bảo hiểm < 100

từ m ở t . MethodsAndContructor ở đâu

  m. NbLinesOfCode> 0 &&

  m. Tỷ lệ phần trăm Bảo hiểm < 100 &&

!m. IsExcludedFromCoverage

chọn mới {

   m,

   m. Tỷ lệ bao phủ,

}

Thông thường, đường cơ sở được chọn để vượt qua các quy tắc là ảnh chụp nhanh được thực hiện trên bản phát hành cuối cùng trong sản xuất. Nhiều quy tắc như vậy trên vùng đồng bằng vì đường cơ sở có thể được viết để hợp lý hóa đáng kể việc xem xét mã. Một số danh mục quy tắc mặc định có liên quan là

• Mã có mùi hồi quy
• Thay đổi phá vỡ API
• Mã số bảo hiểm

Ngoài ra, NDepend có thể giúp tập trung vào các vấn đề tin tức được giới thiệu kể từ cơ sở để tự động hóa nhiều khía cạnh hơn của đánh giá như đặt tên, cách sử dụng Hướng đối tượng hoặc cấu trúc mã. Điều này rất quan trọng vì không thể khắc phục tất cả các sự cố được phát hiện bởi một công cụ. Cách đúng đắn để sử dụng công cụ phân tích tĩnh là tập trung vào các vấn đề mới được đưa ra kể từ đường cơ sở

Những gì cần tìm trong một đánh giá mã

Chúng tôi vừa giải thích rằng với một công cụ như NDepend, rất nhiều khía cạnh của việc xem xét có thể được tự động hóa. Tuy nhiên, kỹ năng và kinh nghiệm của con người vẫn cần thiết để phát hiện những cải tiến quan trọng

• lỗi yêu cầu. Một nhà phát triển có thể đã hiểu sai một số yêu cầu. Mã của anh ta có thể được kiểm tra 100% tốt nhưng nếu cả mã và các bài kiểm tra được viết đều dựa trên các giả định sai thì không thể chấp nhận thay đổi
• thay đổi giao diện người dùng. Thiết kế các câu chuyện người dùng phù hợp sẽ dẫn đến một giao diện người dùng mượt mà giúp người dùng làm việc hiệu quả là một trong những nhiệm vụ phát triển khó khăn nhất. Đánh giá mã và đánh giá giao diện người dùng bởi các chuyên gia trong nhóm là bắt buộc để đảm bảo quá trình phát triển sản phẩm đi đúng hướng
• Khó phát hiện lỗi. Các lỗi liên quan đến lập trình đồng thời (deadlock, race-condition…) khó phát hiện, khó tái tạo và khó sửa. Các nhà phát triển cơ sở thường tạo ra những lỗi như vậy mà không hề nghi ngờ rằng nó có thể xảy ra. Mặt khác, khi xem xét mã được thực thi đồng thời, một lập trình viên dày dặn kinh nghiệm sẽ có thể đánh giá xem có khả năng xảy ra lỗi hay không. Anh ta sẽ kiểm tra khả năng biến đổi trạng thái và độ tinh khiết của phương pháp chẳng hạn. Nhân tiện, NDepend cung cấp một số quy tắc để thực thi các loại ràng buộc này. Trong quá trình xem xét mã, một số lỗi phức tạp khác có thể được phát hiện bao gồm rò rỉ bộ nhớ và mùi hiệu suất, chẳng hạn như sự cố chọn N+1 khét tiếng
• lỗ hổng. Có rất nhiều cạm bẫy bảo mật tiềm ẩn đòi hỏi chuyên môn. Một số công cụ như Semmle có thể tự động phát hiện nhiều cạm bẫy này. Nhưng nếu bảo mật là mối quan tâm của bạn (và nó nên như vậy) thì việc xem xét thường xuyên do chuyên gia bảo mật thực hiện là điều bắt buộc
• đặt tên. Quy tắc mã có thể được viết để thực thi các yêu cầu đặt tên đơn giản như tên giao diện phải có chữ I. Công cụ có thể tiến xa hơn để buộc sử dụng thuật ngữ miền lõi được xác định trước. Điều này được gọi là Kiểm tra ngôn ngữ phổ biến trong thiết kế hướng miền (DDD). Đối với điều đó, NDepend cung cấp một quy tắc có thể tùy chỉnh với từ vựng miền. Tuy nhiên, việc đặt tên thích hợp rất nhạy cảm, đặc biệt đối với các mã định danh API sẽ được công khai. Đây là lý do tại sao cần phải xem xét cẩn thận con người
• thử nghiệm. Như chúng ta đã thấy, thử nghiệm có thể được đo lường và chuyển tự động sang một phạm vi rộng lớn. Nhưng tỷ lệ bao phủ mã và số lần kiểm tra đã vượt qua là không đủ. Con người phải xem xét các bài kiểm tra để đảm bảo rằng các điều kiện thích hợp được khẳng định và các bài kiểm tra đó không quá phức tạp
• Tính nhất quán. Thường thì đàn em trong nhóm đang phát minh lại bánh xe vì họ không biết về các mẫu và thư viện toàn doanh nghiệp. Một số quy tắc tự động có thể được viết để buộc sử dụng một số lớp cụ thể trong một số tình huống nhất định. Nhưng đánh giá mã đại diện cho một cách tuyệt vời để cố vấn về kiến ​​thức và văn hóa công ty
• Bình luận. Thật dễ dàng để thực thi một tỷ lệ bình luận nhất định nhưng đây không phải là vấn đề với bình luận. Nhận xét phải được viết cẩn thận bằng tiếng Anh thích hợp để giải thích lý do tại sao mã cần thiết ngay từ đầu và tại sao mã được viết theo cách này. Ví dụ: khi một số mã không tầm thường được điều chỉnh từ stackoverflow. com, điều đáng nói là url phản hồi và ngữ cảnh. Mặt khác, mã phải đủ dễ đọc để tránh có nhận xét giải thích mã làm gì
• Tài liệu. Công cụ có thể dễ dàng phát hiện tài liệu bị thiếu. Một IDE như Visual Studio có thể dễ dàng tạo khung của một lớp hoặc tài liệu phương thức. Nhưng tài liệu được viết bởi con người và cho con người. Cần có sự đánh giá thích hợp của con người để đảm bảo rằng tài liệu thực sự cung cấp nhiều thông tin. Chúng tôi - với tư cách là nhà phát triển - thường xuyên thất vọng bởi tài liệu nông cạn và lỗi thời không thực sự giải thích lý do tại sao cần có API, cách sử dụng API và những gì bạn có thể mong đợi từ API. Tài liệu phù hợp là một cách tuyệt vời để giảm cả chi phí hỗ trợ và sự thất vọng của người dùng. Nó xứng đáng được xem xét cẩn thận

Không có công cụ nào có thể phát hiện ra loại lỗi vừa được liệt kê. Ít nhất là cho đến khi Trí tuệ nhân tạo đạt được một số tiến bộ to lớn trong việc hiểu mã. Điều này nhất thiết sẽ xảy ra nhưng vào năm 2021, nó vẫn chỉ là khoa học viễn tưởng. Thông tin thêm về chủ đề này có thể được đọc trong bài đăng này Trí tuệ nhân tạo có hỗ trợ mã hóa viên đạn bạc năng suất tiếp theo của nhà phát triển không?

Phần kết luận

Các lợi ích của việc xem xét mã được cộng đồng hoan nghênh rộng rãi và nếu bạn không thực hành nó trong nhóm của mình, thì bạn có cơ hội cải thiện nghiêm túc. Tuy nhiên, vì việc xem xét mã đang tiêu tốn rất nhiều thời gian quý báu của con người, điều cần thiết là sử dụng các công cụ phù hợp để hợp lý hóa việc phối hợp và phê duyệt đánh giá cũng như để thực thi các sự kiện có thể được xác minh tự động từ chính mã đó. Bằng cách này, người đánh giá đối phó với mã đủ sạch và có thể tập trung vào các điểm thực sự đòi hỏi chuyên môn của họ

Patrick Smacchia

Trang mạng

Bố tôi là một lập trình viên đầu những năm 70, tôi đã may mắn chuyển từ chơi Lego sang lập trình các trò chơi vi mô của riêng mình, khi tôi vẫn còn là một đứa trẻ. Kể từ đó tôi không bao giờ ngừng lập trình

Tôi tốt nghiệp chuyên ngành Toán học và Kỹ thuật phần mềm. Sau một thập kỷ tư vấn và lập trình C ++, tôi bắt đầu quan tâm đến thương hiệu mới. NET vào năm 2002. Tôi đã có cơ hội viết cuốn sách bán chạy nhất (bằng tiếng Pháp) trên. NET và C#, được xuất bản bởi O'Reilly và cũng đã quản lý một số khóa học chuyên nghiệp và học thuật trên nền tảng và C#

Trong những năm tư vấn của mình, tôi đã xây dựng chuyên môn về kiến ​​trúc, sự phát triển và những thách thức bảo trì của các ứng dụng lớn và phức tạp trong thế giới thực. Có vẻ như spaghetti & di sản nguyên khối vướng víu liên quan đến mọi nhóm đủ lớn. Kết quả là, tôi quan tâm đến phân tích mã tĩnh và bắt đầu dự án NDepend vào năm 2004

Ngày nay, NDepend là Nhà cung cấp phần mềm độc lập (ISV) chính thức. Với hơn 12. 000 công ty khách hàng, bao gồm nhiều công ty trong danh sách Fortune 500, NDepend cung cấp cái nhìn sâu sắc hơn và toàn quyền kiểm soát ứng dụng của họ cho nhiều người dùng chuyên nghiệp trên khắp thế giới

Tôi sống với vợ và hai đứa con sinh đôi Léna và Paul tại hòn đảo Mauritius xinh đẹp ở Ấn Độ Dương

3 loại đánh giá mã hóa là gì?

Đánh giá mã nên bao gồm những gì?

7 bước để xem xét mã là gì?

Làm thế nào xem xét mã nên được thực hiện?