Chào tất cả các bạn, bài viết này mình sẽ cung cấp một số tiêu chí cần thiết và cốt lõi cần phải có của một Coder để đánh giá mã nguồn trong các ứng dụng được phát triển bằng C# (sử dụng Visual Studio). Bên cạnh đó mình cũng giới thiệu đến các bạn 1 công cụ hỗ trợ khá hiệu quả trong quá trình triển khai các tasks được giao mà tránh lặp đi lặp lại những skills code cơ bản trước khi tạo pull request để Leader của mình review:
1. Projects & files name
Nhiều khi chúng ta lúc phát triển tính năng chỉ tập trung vào việc viết code. Nhưng theo quan điểm của mình, tên projects, tên files, v.v. mà chúng ta tạo ra cũng rất quan trọng. Cung cấp mã chức năng được viết tốt thôi là chưa đủ, tên projects và tên files được xác định rõ ràng sẽ giúp chúng ta xác định được mục đích chính mà project hay files mang lại nếu chưa cần đọc vào mã chi tiết.
2. Loại bỏ using statements không sử dụng
Chúng ta thêm vào một số câu lệnh “using” trong khi test các khối code khác nhau để đạt được chức năng. Nhưng một khi chức năng đó được hoàn thành, nhiều developers có xu hướng quên việc dọn dẹp các tham chiếu của các câu lệnh “using” hiện không còn cần thiết nữa.
Việc loại bỏ những using statements không sử dụng trong code C# có một số lý do quan trọng:
- Dễ đọc và hiểu code: Khi một using statement không được sử dụng, nó chỉ làm cho code trở nên lộn xộn và khó đọc. Việc xóa những using không sử dụng giúp làm sạch code, giúp bạn và các developers khác dễ dàng hiểu hơn.
- Tối ưu hóa hiệu suất: Mỗi using statement tiềm ẩn một overhead nhỏ trong quá trình biên dịch và thực thi. Mặc dù overhead này nhỏ, nhưng khi có nhiều using không cần thiết, nó có thể tích lũy và gây ra một số tác động tiêu cực đến hiệu suất của ứng dụng.
- Tránh xung đột tên: Đôi khi, khi bạn có nhiều using statements, có thể xảy ra xung đột tên giữa các loại dữ liệu hoặc phương thức từ các không gian tên khác nhau. Việc loại bỏ những using không cần thiết giúp tránh những xung đột này.
3. Đừng bỏ qua những warnings khi biên dịch code
Mình ví dụ khi chúng ta viết code sẽ có một số biến được khai báo ra và không sử dụng, nên remove chúng trước khi check-in. Rất nhiều công ty đưa ra chính sách 0 warnings trước khi check-in code. Những mã nguồn có warnings có thể đang cảnh báo những vấn đề tiềm ẩn, tiêu thụ những tài nguyên không cần thiết ảnh hưởng đến hiệu suất hệ thống. Ngoài ra, chúng ta phải cố gắng giữ code của mình phải không có warnings để có được mã nguồn sạch sẽ và dễ đọc.
- Bộ source code như thế này thì có vẽ dễ toang lắm nhé các bạn:
4. Code consistency
Một phẩm chất rất quan trọng của code được viết tốt là “Tính nhất quán”. Giả sử bạn muốn khai báo một biến số nguyên nhưng nhiều khi các bạn viết code không nhất quán như Int32/int. Ngoài ra còn các case khác như String/string, v.v điều này chứng tỏ rằng tính nhất quán của code bị vi phạm. Trình biên dịch code thành công nhưng làm cho mã nguồn của bạn hoàn toàn không nhất quán.
5. Phải luôn quan tâm đến việc check Null value
Null có tác động nghiêm trọng đến chức năng trong mã nguồn 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 developers như Re-Sharper nhắc nhở về bất kỳ “NullReferenceException” tiềm ẩn nào có thể được kích hoạt từ code của bạn. Hãy đảm bảo rằng tất cả if/else của bạn quan tâm đầy đủ đến việc check Null value nhé.
6. Dead code
Đôi khi chúng ta quan sát thấy một khối code được comment rất lâu hoặc các functions không có tham chiếu nhưng dường như chúng ta không quan tâm. Có thể do các lí do: đầu tiên về vấn đề thái độ, thứ hai là thời gian và số giờ còn lại để hoàn thành công việc. Với những case như thế này, các bạn hãy note lại trong mục tồn động công việc của team kèm thông tin chi tiết để dọn dẹp những khối code đó.
7. Naming convention
Tất cả các developers ngày nay đều nhận thức rõ về Camel và Pascal và khi nào nên sử dụng cái này hơn cái kia. Ví dụ, tên biến và tham số phải tuân theo cách viết hoa Camel và đối với tên lớp, hàm và phương thức, phải sử dụng cách viết hoa Pascal. Hãy đảm bảo nguyên tắc cơ bản này được áp dụng một cách nhất quán.
8. Code readability
Nhiều khi code được viết theo cách mà khó ai có thể hiểu được. Tất cả các khối code đều lộn xộn hết dòng này đến dòng khác đến mức khó có thể đọc. Đảm bảo rằng mã nguồn có khoảng cách dòng thích hợp ở bất kỳ vị trí nào và comment code đối với những functions phức tạp.
9. Write defensive code
.NET Exception Handling là chìa khóa để viết code 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. 3 từ kỳ diệu có thể giải quyết hầu hết các vấn đề của bạn là try/catch and finally. Việc triển khai và sử dụng đúng cách Exception Handling có thể mang lại 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.
10. Code comment
Việc comment code là hữu ích đổi với bản thân mỗi người và tốt cho team. Giúp chúng ta khi cần update code sẽ nhanh hơn và tránh những sai sót không đáng có nếu code được comment chi tiết đối với các functions phức tạp và một thời gian rất lâu chúng ta cần quay lại cập nhật.
Có rất nhiều tiêu chí để đánh giá mã nguồn nhưng cá nhân mình nghĩ những tiêu chí mình đã liệt kê ở trên là cơ bản mà mọi lập trình viên đều phải nắm và áp dụng triệt để. Là một Leader và phải review code cho rất nhiều members, đôi lúc mình cũng miss nhiều tiêu chí do chủ quan, mà những tiêu chí đó các members lại thường xuyên gặp phải. Vì vậy, hầu như trong các tasks triển khai mình đều phải list ra những tiêu chí trên để members verify trước khi tạo pull request để mình review. Điều này sẽ giúp members của mình tiến bộ hơn và mình tiết kiệm được nhiều thời gian để focus vào những vấn đề advance hơn.
Như đã đề cập ở đầu bài viết, mình giới thiệu đến mọi người công cụ hỗ trợ tốt khi triển khai tasks xong mà không cần phải nhớ trong đầu phải verify nhưng tiêu chí nào trước khi check-in code. Con người ai cũng có trí nhớ giới hạn thôi =))) Thời buổi tiên tiến mình có rất nhiều công cụ hỗ trợ rồi nên tận dụng nhé. Khi phân bổ task cho members. Ngoài những mô tả yêu cầu và những thông tin cần thiết của task đó thì mình thường add thêm những tiêu chí để đánh giá mã và members phải đánh giá mã của mình viết ra có đáp ứng hết tất cả các tiêu chí đó không, hoàn thành hết thì mới được tạo pull request để mình review. Cụ thể như thế này nhé:
Đến đây chắc các bạn đang suy nghĩ rằng cậu này rảnh quá, lỡ 100 tasks phải ngồi define từng task một danh sách Code review checklist đó sao. Không, mình không rảnh vậy đâu. Mình dùng 1 công cụ có chức năng thiết lập "Mẫu kiểm tra" (Checklist template) và mình chỉ cần define một lần và members của mình sẽ apply mẫu đó và verify toàn bộ các tiêu chí đánh giá mã trước khi check-in code. Đối với những tasks giao cho members mới là rất cần thiết để áp dụng việc verify code đã viết ra theo các tiêu chí như mình đã đề cập ở trên để chúng ta có những khối code chất lượng. Tránh con sâu làm rầu nồi canh nhé =)))
Mình sẽ hướng dẫn các bạn sử dụng tính năng "Mẫu kiểm tra" trong phần mềm quản lý công việc Cleeksy này nhé. Ngoài ra, các bạn có thể vào website của tool này để khám phá những tính năng khác hay hơn. Cá nhân mình thấy dùng tool này rất hữu ích cho mình rất nhiều và tiết kiệm được nhiều thời gian hơn. Giờ thì cùng mình đi vào chi tiết phần thiết lập cho tính năng "Mẫu kiểm tra" này. Đầu tiên, tại màn hình Dự án, bạn vào Tùy chỉnh và chọn tab Mẫu kiểm tra như hình minh họa này: Tiếp theo, các bạn tạo "Mẫu kiểm tra" tương tự như mình define ở đây: Và rất đơn giản, sau khi tạo xong, các bạn quay trở lại các công việc của mình và thao tác như mô tả ở hình mình họa. Nhấn "/" ở section "Mẫu kiểm tra" sẽ hiển thị mẫu kiểm tra mà bạn đã define trước đó. Cuối cùng chỉ cần click vào tên mẫu đó trên danh sách là sẽ có kết quả như mình mong đợi:
Vậy là mình đã giới thiệu xong đến mọi người một số tiêu chí và cách sử dụng công cụ hỗ trợ. Mọi người có thêm những tiêu chí nào mà bản thân nghĩ là quan trọng thì add ở comment giúp mình để giúp các bạn lập trình viên mới viết mã chất lượng hơn nhé. Mình note lại thông tin tool mà mình sử dụng ở trên cho mọi người - Cleeksy