Đánh giá mã là một thực tế ngày càng phổ biến trong các nhóm phát triển. Đó là quy trình làm việc trong đó các nhà phát triển gửi mã của họ để nhận phản hồi trước khi hợp nhất các nhánh hoặc triển khai mã vào sản xuất. Phản hồi này thường được đưa ra bởi đồng nghiệp, nhà phát triển khác, người quản lý hoặc trưởng nhóm công nghệ. Một trong những hình thức đánh giá mã quen thuộc nhất là Yêu cầu kéo Github, trong đó các nhà phát triển để lại nhận xét về các dòng mã cụ thể và cuối cùng phê duyệt hoặc từ chối các thay đổi được đề xuất.

Việc đánh giá mã dựa trên giả định đơn giản rằng “hai cái đầu tốt hơn một”. Tất cả chúng ta đều có những điểm mù khi viết mã: những cách tiếp cận mà chúng ta không xem xét, những hiệu quả mà chúng ta không tạo ra và những phần của hệ thống mà chúng ta hiểu kém hơn những phần khác. Đánh giá mã là một nỗ lực nhằm loại bỏ những điểm mù này và cải thiện chất lượng mã bằng cách đảm bảo rằng ít nhất một nhà phát triển khác có đầu vào trên mọi dòng mã được đưa vào sản xuất.

(Như một lưu ý phụ, lập trình cặp đôi khi có thể giống với một hình thức đánh giá mã 'trực tiếp', trong đó một người viết mã và những người khác đánh giá nó ngay tại chỗ.)

Mặc dù việc xem xét mã thường có nghĩa là mã sẽ mất nhiều thời gian hơn một chút để đưa vào sản xuất nhưng nhiều nhóm phát triển cho rằng việc này đáng giá do chất lượng mã tổng thể đã tăng lên. Việc đánh giá mã được thực hiện từ các công ty lớn có hiệu suất hoạt động hàng đầu, như microsoft và Google, cho các công ty khởi nghiệp như đầy đủ. Bruce Johnson, đồng sáng lập tại Fullstory, nói rằng công ty của ông thực hiện đánh giá mã vì “một ounce phòng bệnh có giá trị một pound chữa bệnh”. Nói tóm lại, việc xem xét mã thường có nghĩa là sẽ có ít lỗi xảy ra hơn trong quá trình sản xuất.

Có thể bạn đang thực hiện đánh giá mã tại nơi làm việc. Tuy nhiên, theo kinh nghiệm của tôi, hầu hết các nhà phát triển đều tiến hành đánh giá mã theo “cảm tính” của họ. Họ phản ứng với từng dòng mã mà không có kế hoạch rõ ràng về những gì họ sẽ xem xét trong quá trình xem xét mã. Do cách tiếp cận đặc biệt này nên một số khía cạnh nhất định của việc xem xét mã thường bị bỏ qua.

Trong bài viết này, chúng tôi sẽ hướng tới việc xây dựng kỹ năng đánh giá mã của bạn bằng cách đề xuất các yếu tố khác nhau mà bạn nên cân nhắc khi tiến hành đánh giá mã. Bạn có thể sử dụng danh sách này làm danh sách kiểm tra để xem lại mã. Nếu danh sách này có vẻ quá sức, Codementor cũng cung cấp đánh giá mã như một dịch vụ.

1. Dễ đọc hay còn gọi là 'Dễ hiểu'

Khả năng đọc trong phần mềm có nghĩa là mã dễ hiểu. Trong trường hợp này, hiểu mã có nghĩa là có thể dễ dàng nhìn thấy đầu vào và đầu ra của mã, mỗi dòng mã đang làm gì và nó phù hợp như thế nào với bức tranh lớn hơn. Khi đọc qua mã, bạn sẽ tương đối dễ dàng nhận ra vai trò của các hàm, phương thức hoặc lớp cụ thể.

Mã trở nên khó đọc hơn vì cần nhiều bộ nhớ làm việc hơn để ghi nhớ từng 'bước' trong đầu. Một trong những vấn đề thường gặp nhất với mã là nó không được chia thành các phần đủ nhỏ. Thông thường, điều này dẫn đến các lớp, phương thức hoặc hàm quá dài với quá nhiều trách nhiệm rối rắm. Bằng cách chia mã thành các phần nhỏ hơn, việc suy luận và thực hiện các thay đổi đối với các phần cụ thể của hệ thống sẽ dễ dàng hơn mà không có tác dụng phụ ngoài ý muốn.

Một khía cạnh khác của khả năng đọc là cách đặt tên biến, hàm, phương thức và lớp. Những cái tên hay, mang tính mô tả giúp mã dễ hiểu hơn. Đừng ngần ngại đưa ra phản hồi về những cái tên viết tắt quá mức hoặc khó hiểu. Ví dụ: mặc dù người lập trình ban đầu có thể rõ ràng rằng op là viết tắt options parser, bạn hoặc người tiếp theo sẽ sử dụng mã có thể không rõ. Những cái tên hay giúp tiết kiệm thời gian của mọi người và giảm tải nhận thức khi đọc mã.

2. Khả năng bảo trì

Một trong những lý do phổ biến nhất khiến việc làm việc với mã trở nên khó khăn là vì nó không được viết để dễ dàng mở rộng và thay đổi.

Dưới đây là một số dấu hiệu cảnh báo rằng mã có thể không dễ bảo trì trong tương lai:

• Nó được kết hợp rất chặt chẽ với một hệ thống khác.
• Cấu hình được mã hóa cứng.
• Nó góp phần tạo ra nợ công nghệ bằng cách tăng cường đầu tư vào công nghệ mà nhóm muốn loại bỏ dần (ví dụ: bằng cách sử dụng chức năng từ phiên bản cũ của thư viện).
• Nó dựa vào mã cũ đã được dự kiến ​​loại bỏ hoặc thay thế.

3. An ninh

Các lỗ hổng bảo mật thường xâm nhập vào cơ sở mã vì các nhà phát triển viết mã mà không nghĩ đến bảo mật. Điều này có thể có nghĩa là họ viết mã không an toàn gây ra các lỗ hổng bảo mật trong hệ thống hoặc sử dụng các thư viện và công cụ đã lỗi thời hoặc có các vấn đề bảo mật đã biết.

Trong quá trình xem xét mã, các vấn đề bảo mật có thể bị bỏ qua nếu nhà phát triển quên đặt mình vào vị trí của người đang cố gắng khai thác hệ thống. Ví dụ: hãy tự hỏi: nếu tôi đang cố gắng truy cập vào hệ thống hoặc đánh cắp dữ liệu, làm cách nào tôi có thể khai thác mã này?

4. Tốc độ và Hiệu suất

Xem xét hiệu suất trên hai khía cạnh: hiệu suất cho người dùng và mức tiêu thụ tài nguyên. Hiệu suất dành cho người dùng phản ánh sự tập trung vào tốc độ hoạt động của mã đối với người dùng cuối. Các truy vấn cơ sở dữ liệu dài dòng, nội dung không được tối ưu hóa và nhiều yêu cầu API đều có thể khiến mã của bạn bị chậm.

Khi có thể, mã nên sử dụng tính năng tải từng phần cũng như xử lý song song và không đồng bộ. Nó nên sử dụng bộ nhớ đệm càng nhiều càng tốt và không nên tải bất cứ thứ gì không được sử dụng.

Khía cạnh khác của hiệu suất là mức tiêu thụ tài nguyên. Điều này có nghĩa là không vận hành các máy chủ đám mây mạnh hơn mức cần thiết, không chạy các báo cáo chuyên sâu thường xuyên hơn mức cần thiết và mặt khác, không khiến hệ thống phải chịu tải nhiều hơn mức cần thiết do lựa chọn mã hoặc cơ sở hạ tầng.

Trong khi tuân thủ các phương pháp hay nhất như thế này, hãy lưu ý đừng đưa “nhu cầu tốc độ” này đi quá xa. Làm như vậy có thể dẫn đến tối ưu hóa sớm, tức là những tối ưu hóa không cần thiết, không được người dùng chú ý (hoặc trong chỉ số của bạn) hoặc không đáng để bạn đầu tư thời gian. Được thực tế. Tập trung vào 20% tối ưu hóa mang lại 80% kết quả.

5. Tài liệu

Kiểm tra xem mã bạn đang xem xét có yêu cầu tài liệu bổ sung đi kèm hay không. Nếu đó là một dự án mới, điều này có nghĩa là phải đảm bảo nó có đủ readme giải thích lý do dự án tồn tại và cách sử dụng nó. Nếu đó là mã mới được thêm vào dự án hiện có, bạn nên suy nghĩ xem liệu readme của dự án có cần được cập nhật để ghi lại chức năng mới hoặc công cụ mới hay không.

6. Phát minh lại Bánh xe

Mã có sử dụng đúng tính năng ngôn ngữ để hoàn thành công việc không? Khi mọi người viết mã bằng các ngôn ngữ lập trình mà họ chưa thành thạo, họ thường mất nhiều thời gian với mã. Ví dụ, họ có thể miệt mài viết ra một hàm để thực hiện điều gì đó đã tồn tại trong ngôn ngữ họ đang sử dụng. Khi thực hiện đánh giá mã, hãy đảm bảo rằng mã sử dụng tất cả các tính năng ngôn ngữ thích hợp. Mã không được triển khai lại các chức năng đã tồn tại trong ngôn ngữ hoặc thư viện mà dự án sử dụng.

7. độ tin cậy

Mã đáng tin cậy là mã có khả năng chịu lỗi. Khi có sự cố xảy ra với mã đáng tin cậy, trải nghiệm người dùng sẽ được bảo vệ khỏi tác động nhiều nhất có thể. Mã đáng tin cậy được viết dựa trên giả định rằng mọi thứ sẽ thất bại, nội dung đôi khi sẽ không tải, các yêu cầu API đôi khi sẽ trả về 500 lỗi và các bản ghi cơ sở dữ liệu sẽ bị thiếu. Khi dự đoán được một mức độ thất bại nhất định, nó có thể được xử lý một cách khéo léo. Mã giả định sẽ không có gì sai thường sẽ thất bại thảm hại.

XUẤT KHẨU. Khả năng mở rộng

Xem xét khả năng mở rộng bằng cách tưởng tượng điều gì có thể xảy ra với mã bạn đang xem xét nếu nó được tải dưới mức không mong muốn. Điều gì sẽ xảy ra với trang chủ của bạn nếu nó lan truyền và nhận được hàng chục yêu cầu mỗi giây? Điều gì xảy ra nếu người dùng có hàng nghìn hoạt động trong ứng dụng của bạn quyết định xem nhật ký hoạt động đầy đủ của họ? Điều gì xảy ra nếu sản phẩm của bạn xuất hiện trên tin tức và 100 người cố gắng mua tất cả cùng một lúc? Điều quan trọng là phải xem xét điều gì có thể xảy ra với mã trong khoảng thời gian sử dụng rất cao khi tiến hành đánh giá mã. Rốt cuộc, thời điểm tồi tệ nhất để phát hiện ra các vấn đề về khả năng mở rộng là khi họ đưa trang web/ứng dụng/dịch vụ của bạn ngoại tuyến.

9. Khả năng tái sử dụng

Kiểm tra xem mã có được viết phù hợp với các trường hợp sử dụng trong tương lai hay không. Ví dụ: nếu bạn đang xem xét mã cho một thị trường đang nhanh chóng mở rộng phạm vi sản phẩm của mình, hãy đảm bảo rằng mã có thể dễ dàng được cập nhật để hỗ trợ các loại sản phẩm mới trong tương lai.

Tương tự như vậy, hãy đảm bảo rằng mã không đi quá xa bằng cách cố gắng tính đến các trường hợp sử dụng khó có khả năng xảy ra. Tất cả chúng ta đều đã thấy mã trong đó tác giả đã cố gắng chứng minh sự sáng tạo của họ trong tương lai đến mức cuối cùng họ đã thêm các tính năng bổ sung sẽ không bao giờ được sử dụng vào mã của họ. Mã không bao giờ được sử dụng ngay lập tức là mã kế thừa. Vì vậy, điều quan trọng là phải đạt được sự cân bằng giữa mã có thể tái sử dụng và mã vi phạm nguyên tắc. nguyên tắc YAGNI: bạn sẽ không cần nó

DRY là một trong những châm ngôn đầu tiên mà các lập trình viên phải học. Nó có nghĩa là Đừng lặp lại chính mình. Nói cách khác, không sao chép mã hoặc chức năng. Một trong những cải tiến nhanh nhất mà bạn có thể thực hiện trong quá trình xem xét mã là xác định mã lặp lại và đề xuất hàm hoặc lớp có thể sử dụng lại để thay thế mã đó.

Một lời cảnh báo: có thể đi quá xa khả năng sử dụng lại và dẫn đến mã quá trừu tượng và cố gắng đáp ứng rất nhiều trường hợp sử dụng tiềm năng mà nó không phục vụ tốt cho trường hợp nào. Nó tương đương với việc cố gắng phát minh ra một dụng cụ nhà bếp gồm nĩa, dao, thìa và đĩa tất cả trong một. Nó vẫn chưa được thực hiện, đó là một dấu hiệu cho thấy đó có thể không phải là một ý tưởng hay!

10. Mẫu

Một điều cần cân nhắc khác khi thêm mã mới vào cơ sở mã là liệu nó có phù hợp với các mẫu mà nhóm của bạn đã thiết lập hay không. Cơ sở mã của bạn có thể đã có kiểu riêng và có thể có hướng dẫn về kiểu riêng. Mã mới không được đi chệch khỏi các mẫu đã thiết lập mà không có lý do chính đáng.

11. Phạm vi kiểm tra và chất lượng kiểm tra

Việc xem xét mã cũng quan trọng đối với các bài kiểm tra cũng như đối với mã được kiểm tra. Điều này là do một bài kiểm tra thiếu sót còn nguy hiểm hơn là không có bài kiểm tra nào. Việc vượt qua các bài kiểm tra cho phép nhà phát triển cảm thấy an tâm và sẵn sàng đưa mã mới vào sản xuất. Nhưng điều gì sẽ xảy ra nếu một trong các bài kiểm tra vượt qua vì lý do sai hoặc không kiểm tra những gì nó phải kiểm tra? Loại thử nghiệm này có thể là một quả bom hẹn giờ, cho phép lỗi lẻn vào cơ sở mã của bạn.

Các yêu cầu tương tự đối với mã sản xuất cũng phải được áp dụng cho các thử nghiệm. Các bài kiểm tra phải dễ đọc, có thể bảo trì, hoạt động tốt và tuân thủ các mẫu đã thiết lập. Khi đến lúc phải cập nhật hoặc duy trì mã hiện có, các thử nghiệm của mã đó có thể là điều đầu tiên cần thay đổi. Do đó, điều quan trọng là nhóm của bạn có thể dễ dàng làm việc cùng họ.

Cuối cùng, đừng dừng lại ở việc xem lại các bài kiểm tra ở đó. Hãy suy nghĩ xem có bài kiểm tra nào còn thiếu hay không. Có trường hợp nào chưa được thử nghiệm không?

12. Phù hợp với mục đích

Mã có thể hoạt động nhưng nó có hoạt động theo cách mà Giám đốc sản phẩm, Giám đốc điều hành hoặc người dùng mong đợi không? Trước khi mã được đưa vào sản xuất, bạn cần kiểm tra kỹ xem mã có thực sự cung cấp chức năng mà nó dự định cung cấp hay không. Nếu bạn không có quy trình đảm bảo chất lượng được xác định cho chức năng mới, việc xem xét mã có thể là cơ hội duy nhất để bạn xác nhận điều này.

13. Chú ý những gì còn thiếu

Việc xem xét mã có thể khuyến khích xu hướng chỉ xem xét những gì trước mắt bạn. Bạn xem lại mã mà bạn đã được cung cấp. Nhưng còn mã không có ở đó thì sao? Ví dụ: điều quan trọng là phải xem xét các trường hợp đặc biệt, đầu vào không mong muốn và các tình huống xử lý lỗi mà tác giả mã có thể chưa xem xét. Điều gì xảy ra khi API mà mã dựa vào bị hỏng? Điều gì xảy ra khi người dùng nhấn nút gửi hai lần liên tiếp? Điều gì xảy ra khi trình duyệt của người dùng không được hỗ trợ?

14. Thu nhỏ

Một trong những rủi ro khi xem xét mã là nó khuyến khích sự tập trung vào các chi tiết của mã, thay vì bức tranh lớn hơn. Điều gì sẽ xảy ra khi một yêu cầu kéo được gửi chứa hàng trăm dòng mã, tuy nhiên, cách tiếp cận giải quyết vấn đề còn kém? Có lẽ nó không hiệu quả, dễ vỡ hoặc có kiến ​​trúc kém? Đây có thể là phản hồi thực sự khó đưa ra, đặc biệt khi nhà phát triển đã dành vài ngày để tìm giải pháp trước khi yêu cầu xem xét mã.

Tuy nhiên, loại phản hồi này rất quan trọng vì các yêu cầu kéo lẽ ra không được phê duyệt ngay từ đầu thường trở thành điểm yếu trong cơ sở mã của bạn. Bạn cần cảm thấy thoải mái khi đề xuất một cách tiếp cận hoàn toàn mới nếu yêu cầu kéo về cơ bản có sai sót.

Một trong những cách tốt nhất để làm cho điều này trở nên thực tế hơn là đảm bảo rằng các yêu cầu kéo không quá lớn. Nếu các nhà phát triển đang làm việc độc lập trong nhiều ngày và cuối cùng gửi một yêu cầu kéo lớn thì đây là một mô hình phản đối. Yêu cầu kéo phải nhỏ và được tích hợp thường xuyên. Chuyển đổi tính năng, đôi khi còn được gọi là cờ tính năng, có thể trợ giúp việc này. Chúng là những công cụ thông minh cho phép chia khối lượng công việc lớn hơn thành một tập hợp các yêu cầu kéo tăng dần. Chúng cho phép tiến bộ liên tục về chức năng trong cơ sở mã của bạn mà không hiển thị cho người dùng cho đến khi bạn sẵn sàng.

Hãy cho chúng tôi biết: Bạn còn cân nhắc điều gì khác khi xem xét mã?

Chúng tôi hy vọng đây là danh sách kiểm tra hữu ích để bạn xem xét trong quá trình xem xét mã. Ngay cả khi bạn không tham khảo mọi mục trong danh sách mỗi khi xem lại mã, thì việc lưu ý đến các khía cạnh của việc xem lại mã mà bạn có xu hướng bỏ qua cũng có thể hữu ích. Những điều này sẽ khác nhau đối với mọi người và sẽ phụ thuộc vào nền tảng hoặc kinh nghiệm của bạn. Tuy nhiên, tất cả các khía cạnh này của mã đều quan trọng đối với chất lượng và không nên bỏ qua.

Bạn nghĩ điều gì khác là quan trọng cần cân nhắc khi tiến hành đánh giá mã? Chúng tôi muốn nghe ý kiến ​​từ bạn trong phần bình luận.

Nguồn: https://www.codementor.io/blog/code-review-checklist-76q7ovkaqj