Bài viết này cung cấp tổng quan về quy trình xem xét mã được viết bằng C# bằng Visual Studio 2015 và cũng khám phá các phương pháp hay nhất để xem xét mã
Đánh giá mã là một phần rất quan trọng trong cuộc sống của bất kỳ nhà phát triển nào. Đánh giá mã là một kỹ thuật cho phép một nhà phát triển khác [không nhất thiết phải làm việc trong cùng một nhóm hoặc cùng một tính năng trong một nhóm] xem qua từng dòng mã của bạn và xác định các khu vực cần cải thiện hoặc chỉ ra các lỗ hổng. Do đó, code review là một quá trình chứ không phải là một công nghệ. Tuy nhiên, có sẵn một số công cụ năng suất dành cho nhà phát triển [được đề cập sau trong bài viết này] có thể cho phép nhà phát triển viết mã chất lượng tốt
từ chối trách nhiệm
Có rất nhiều hướng dẫn và thực tiễn tốt nhất mà các nhóm phát triển phần mềm tuân theo và phụ thuộc vào. Bài viết này sẽ khám phá hầu hết những điều đó nhưng nó có thể không bao gồm tất cả các phương pháp hay nhất xung quanh việc xem xét mã. Tuy nhiên, tôi muốn đảm bảo với bạn rằng tất cả các hướng dẫn được đề cập bên dưới sẽ giúp bất kỳ cá nhân nào thực hành và áp dụng các nguyên tắc mã hóa tốt cũng như thực hiện đánh giá mã chất lượng
Mã của tôi có bắt buộc phải được các nhà phát triển khác xem xét không?
Chà, bạn phải. Nhưng nó phụ thuộc vào phương pháp phát triển của nhóm bạn và cài đặt công cụ ALM [Quản lý vòng đời ứng dụng]. Có nhiều cách để bỏ qua việc xem xét mã bằng cách đơn giản là không thực hiện và kiểm tra mã trực tiếp. Nó không được khuyến khích mặc dù.
Điều gì sẽ xảy ra nếu mã của tôi không được xem xét?
Thật khó để nói nhưng đôi khi và trong một số trường hợp, điều đó có thể gây ra sự cố nghiêm trọng và gây lo ngại cho cả nhóm. Chẳng hạn, kiểm tra điều kiện bị bỏ sót hoặc null không được xử lý đúng cách hoặc không phải tất cả các tình huống lỗi đều được khối xử lý ngoại lệ của bạn xử lý. Chà, những ví dụ này nghe có vẻ rất đơn giản và hầu hết các nhà phát triển đều viết mã phòng thủ và đề cập đến những khía cạnh như vậy. Nhưng điều mà việc xem xét mã cũng có thể mang lại giá trị hướng tới là “thiết kế”, “kỹ thuật”, “mẫu”, “cách tiếp cận” của bạn, v.v.
Cách tìm người đánh giá mã
Tôi đã làm việc trong nhiều môi trường làm việc và nhóm khác nhau. Nhiều lần tôi được mời thực hiện đánh giá mã cho một nhà phát triển không thuộc nhóm của tôi, hay nói đúng hơn là tôi không thuộc nhóm của họ. Nhưng điều tôi ngưỡng mộ và đánh giá cao ở đây là việc ai đó đã liên hệ với nhà phát triển khác trong trường hợp nhà phát triển của nhóm họ không có mặt hoặc đang bận với các vấn đề sản xuất quan trọng, v.v. Một tư duy như vậy trao quyền cho nhóm để cung cấp mã được viết tốt nhất
Hãy bắt đầu với các phương pháp hay nhất về đánh giá mã
Ở đây, tôi sẽ liệt kê ra một số lĩnh vực quan trọng từ góc độ đánh giá mã. Tôi đã cố gắng làm nổi bật các phương pháp hay nhất cốt lõi cần có trong bất kỳ bài đánh giá mã nào. Tôi đã nhiều lần thấy rằng trong quá trình đánh giá mã, các nhà phát triển tập trung hơn vào việc tìm kiếm các mẫu thiết kế mã hoặc một số lĩnh vực trong đánh giá mã,
- Tên dự án và tệp
Nhiều khi nhà phát triển chỉ tập trung vào mã, nhưng theo quan điểm của tôi, tên Dự án, tên tệp của bạn, v.v. cũng quan trọng rất nhiều. Nó không đủ để cung cấp mã chức năng được viết tốt; . Chẳng hạn, hãy xem giải pháp và tên dự án như trong hình bên dưới
Hình 1 - Giải pháp và Dự án được đặt tên phù hợp - Luôn luôn bắt đầu từ đầu
Trước khi bạn thực sự bắt đầu quét qua các khối mã/câu lệnh trong một lớp [. cs] tập tin; . tập tin cs. Cá nhân tôi đã quan sát thấy rằng nhiều lần các nhà phát triển thêm nhiều câu lệnh “sử dụng” trong khi thử các khối mã khác nhau để đạt được chức năng. Nhưng một khi chức năng đó được hoàn thành;
Visual Studio 2015 hiển thị các câu lệnh sử dụng không sử dụng có màu xám có thể được xóa một cách an toàn như trong hình bên dưới
Hình 2 - Các câu lệnh sử dụng không được sử dụng sẽ bị mờ đi theo mặc định trong Visual Studio 2015 - Sắp xếp tất cả các câu lệnh sử dụng
Thực tiễn phát triển thông thường là chúng tôi tiếp tục thêm các câu lệnh sử dụng mới vào cuối các câu lệnh trước đó, chẳng hạn như trong hình bên dưới
Hình 3 - Các câu lệnh sử dụng mới được thêm vàoGiả sử rằng mã đang sử dụng tất cả các câu lệnh sử dụng được thêm vào, nhưng vấn đề là chúng không được sắp xếp. Một trong những cách viết mã tốt nhất là Sắp xếp tất cả bằng cách sử dụng các câu lệnh. Để sắp xếp bằng cách sử dụng các câu lệnh, nhấp chuột phải vào cửa sổ soạn thảo mã và nhấp vào “Tổ chức sử dụng”, sau đó nhấp vào “Sắp xếp sử dụng”
Hình 4 - Tùy chọn Sắp xếp Sử dụng trong Visual Studio 2015Sau khi thực hiện “Sắp xếp Sử dụng”, tất cả các câu lệnh sử dụng sẽ được sắp xếp theo thứ tự bảng chữ cái [đây là thứ tự duy nhất A Z] và sẽ được sắp xếp như trong hình bên dưới
Hình 5 - Câu lệnh Sử dụng được sắp xếp theo thứ tự bảng chữ cái - Đừng bỏ qua các cảnh báo
Là nhà phát triển, chúng tôi tập trung nhiều hơn vào các lỗi biên dịch và muốn thấy dự án/giải pháp đó được xây dựng thành công. Chẳng hạn, hãy xem xét mã như trong hình bên dưới,
Hình 6 - mã mẫuĐây là một mã rất đơn giản và dự án sẽ xây dựng thành công mà không có bất kỳ lỗi biên dịch nào. Tuy nhiên, như bạn có thể thấy rằng “j” không được sử dụng trong mã và vì vậy điều này sẽ gây ra cảnh báo;
Theo quan điểm của tôi và cũng như nhiều công ty phần mềm bao gồm nhiều nhóm Microsoft mà tôi đã làm việc với việc thực thi chính sách 0 cảnh báo trước khi đăng ký. Do đó, điều rất quan trọng là phải xem chi tiết trong menu Xem “Danh sách Lỗi” Danh sách Lỗi, sau đó quan sát Tab Cảnh báo và phải cố gắng để tab đó cũng hiển thị “0 Cảnh báo” giống như chúng ta luôn làm việc để chỉ thấy “0 Lỗi
Hình 7 - Danh sách Lỗi, đánh dấu cảnh báo trong mã - Tính nhất quán của mã
Một phẩm chất rất quan trọng của mã được viết tốt là “Tính nhất quán”. Tôi. e. dính vào một phong cách. Giả sử bạn muốn khai báo một biến số nguyên và rõ ràng là các nhóm và nhà phát triển khác nhau sẽ có các nguyên tắc viết mã khác nhau. Nhiều khi các nhà phát triển bỏ qua điều này và mã có các phiên bản rải rác của các loại/từ khóa Int32 hoặc int và Chuỗi hoặc chuỗi, điều này chứng tỏ rằng tính nhất quán của mã bị vi phạm
Tuy nhiên, sử dụng các câu lệnh hỗn hợp sẽ biên dịch mã thành công nhưng làm cho cơ sở mã của bạn hoàn toàn không nhất quán
Hình 8 - Vi phạm tính nhất quán của mã - Luôn quan tâm đến Null
Null có tác động nghiêm trọng đến chức năng mã của bạn. Chỉ cần bỏ qua kiểm tra rỗng và bạn sẽ phải đối mặt với hậu quả. Đây là lý do tại sao nhiều công cụ năng suất dành cho nhà phát triển như Re-Sharper nhắc nhở về bất kỳ “NullReferenceException” tiềm năng nào có thể được kích hoạt từ mã của bạn
Đảm bảo rằng tất cả if/else của bạn đều quan tâm đầy đủ đến null và có [các] biện pháp bảo vệ, hầu hết thời gian IsNullOrEmpty hoặc IsNullOrWhiteSpace sẽ thực sự hữu ích
- mã chết
Nhiều lần tôi đã thấy rằng với tư cách là nhà phát triển, chúng tôi chủ yếu quan tâm đến mã của chính mình; . Đôi khi chúng tôi quan sát thấy một khối mã được nhận xét lâu nhưng dường như chúng tôi không quan tâm, nhưng tại sao không? . Đầu tiên, tôi không quan tâm miễn là mã của tôi hoạt động. Thứ hai, tôi đang làm việc trong một nhóm nhanh nhẹn và tôi cam kết hoàn thành nhiệm vụ của mình đúng thời hạn đã cam kết
Đầu tiên là vấn đề về thái độ, thứ hai là thời gian và số giờ còn lại để hoàn thành công việc. Nhưng cả hai có thể làm một điều chắc chắn. Mở một mục trong hồ sơ tồn đọng Nợ kỹ thuật với các chi tiết để dọn sạch tệp đó
- Quy ước đặt tên
Tất cả các nhà phát triển ngày nay đều biết rõ về vỏ Camel và Pascal và khi nào nên sử dụng cái này hơn cái kia. Đối với các tên tham số và biến thể hiện phải theo cách viết hoa Camel và đối với các tên lớp, hàm và phương thức phải sử dụng cách viết hoa Pascal. Đảm bảo nguyên tắc cơ bản này được áp dụng nhất quán
- Khả năng đọc mã
Nhiều khi mã được viết theo cách mà không ai có thể hiểu được nó. Tôi. e. tất cả các mã đều lộn xộn hết dòng này đến dòng khác đến mức hầu như không thể đọc được. Đảm bảo rằng mã có khoảng cách dòng đơn thích hợp bất cứ nơi nào có thể áp dụng giữa các khối mã
- Xử lý tài nguyên không được quản lý
Mặc dù. NET Framework chăm sóc tốt việc quản lý Bộ nhớ thông qua GC [thu gom rác] có những hạn chế đối với các mục rác và từ đâu có thể thu thập chúng và những gì không. Nhiều lần, thật khôn ngoan khi xử lý việc dọn dẹp các tài nguyên đắt tiền như trình xử lý Tệp I/O, kết nối, Tài nguyên mạng, v.v. một mình
Các mục như vậy có thể được loại bỏ sau khi sử dụng hết và điều này có thể được thực hiện bằng cách sử dụng khối "đang sử dụng" cho mã không được quản lý, nếu bạn muốn tự động xử lý việc loại bỏ các đối tượng khi chúng nằm ngoài phạm vi. Một nơi tốt khác để xử lý mã như vậy là khối cuối cùng chẳng hạn, Thao tác vào/ra tệp để đọc một tệp như trong hình bên dưới
Xem video kênh YouTube của tôi tại đây
Hình 9 - Xử lý các tài nguyên không được quản lý bằng. NET's StreamReader - Viết mã phòng thủ
NET Xử lý ngoại lệ là chìa khóa để viết mã phòng thủ và bảo vệ ứng dụng của bạn khỏi mọi bất thường trong thời gian chạy. Ba từ kỳ diệu để giải quyết hầu hết các vấn đề của bạn là thử/bắt và cuối cùng
Việc triển khai và sử dụng Xử lý ngoại lệ đúng cách cũng như ghi nhật ký bất kỳ thông báo và chi tiết ngoại lệ nào có thể bổ sung nhiều giá trị cho ứng dụng về mặt giám sát và khắc phục sự cố ứng dụng
- Khai báo rõ ràng các chỉ định truy cập
C#. NET có phạm vi mặc định được xác định cho nhiều loại khác nhau, ví dụ: một biến là riêng tư theo mặc định và vì vậy trong một lớp, chúng tôi chỉ muốn viết “int i” nhưng sẽ phù hợp hơn nếu được khai báo và thay vào đó viết nó là “private int i”
Bạn có biết phạm vi mặc định của một lớp trong C# là gì không?
Nhiều lần các nhà phát triển tuân theo quy ước đặt tên [camel hoặc pascal, v.v. ] nhưng tên đã đặt cho các biến, phương thức, hàm và lớp, v.v. không có ý nghĩa gì cả. Do đó, đôi khi các nhà phát triển viết các nhận xét mã dài để mô tả mục đích của từng chức năng hoặc biến chẳng hạn
Theo quan điểm của tôi, việc đặt tên "tự mô tả" sẽ bổ sung nhiều giá trị và cũng tiết kiệm thời gian của nhà phát triển trong việc ghi lại mã;
Chẳng hạn, thay vì "int age;" . Tương tự, thay vì chỉ viết một hàm có tên "GetData[]", bạn nên nói "GetStudentsReportData[]" sẽ hữu ích hơn. Các kỹ thuật tương tự cũng có thể được áp dụng cho tên lớp, hàm và Bài kiểm tra đơn vị, v.v. Nhưng trong trường hợp kiểm tra đơn vị, [các] tên có thể rất dài, nhưng điều này hoàn toàn ổn và có thể chấp nhận được
Do đó, tên phương thức thử nghiệm đơn vị "TestSuccessWithOneStudentRecordAddedToDb" sẽ được ưu tiên hơn nhiều so với việc chỉ nói "TestOneRecordData"
Tóm lược
Các hướng dẫn đánh giá mã được đề cập ở trên có trọng lượng nhẹ, dễ tìm và dễ áp dụng các kỹ thuật có tác động lớn hơn đối với bất kỳ cơ sở mã nào. Hầu hết rõ ràng là những điều đơn giản hoặc bị bỏ qua hoặc không được quan tâm. Những phương pháp hay nhất này có thể được thêm vào với nhiều hướng dẫn hơn hoặc kết hợp với các kỹ thuật khác nếu có. Mã hóa hạnh phúc…