Giới thiệu
Nếu bạn có một số mẹo viết mã React của riêng mình, có thể bạn đã quen với quy trình xem xét mã React. Nếu không – đó là một quy trình giúp giữ mã tốt trong dự án, loại bỏ các lỗi tiềm ẩn hoặc chỉ kiểm tra từ các nhà phát triển React có tay nghề cao hơn . Nó cũng giúp các thành viên khác làm việc tích cực và cập nhật vì họ có thể xem tất cả các bản cập nhật mã.
Tôi sẽ cố gắng chỉ ra những gì bạn nên tìm kiếm trong quá trình xem xét mã phản ứng và cách viết những câu lệnh hay thay vì những bình luận không cần thiết như “thay đổi A thành B” .
Nhưng hãy bắt đầu với câu hỏi đơn giản.
Mục tiêu của việc kiểm tra mã React là gì ?
- Hiển thị những thay đổi được thực hiện đối với dự án, cho phép các nhà phát triển khác cập nhật thông tin về quá trình phát triển liên tục của các thành phần phản ứng.
- Cung cấp phản hồi và chia sẻ kiến thức với đồng đội, thúc đẩy văn hóa học hỏi và cải tiến.
- Cố vấn cho các nhà phát triển React ít kinh nghiệm hơn về cách viết mã rõ ràng và hiệu quả, cải thiện khả năng tạo mã chất lượng tổng thể của nhà phát triển.
- Thiết lập sự hiểu biết vững chắc về ứng dụng React giữa các thành viên trong nhóm, thúc đẩy sự hợp tác và chuyên môn tập thể.
- Khuyến khích thảo luận về các giải pháp thay thế với các nhà phát triển React đồng nghiệp, khám phá các cách tiếp cận khác nhau để giải quyết vấn đề.
- Xác định và giải quyết các vấn đề hoặc lỗi tiềm ẩn, đảm bảo ứng dụng mạnh mẽ và đáng tin cậy.
Mặc dù việc phát hiện lỗi là một khía cạnh quan trọng của quá trình đánh giá mã, nhưng trọng tâm chính phải là chia sẻ kiến thức và nâng cao sự tự tin của nhà phát triển có mã đang được xem xét. Việc chấp nhận yêu cầu kéo phải được coi là sự công nhận công việc đã hoàn thành tốt, củng cố môi trường nhóm tích cực.
Yêu cầu đánh giá mã React
Nếu bạn là người đánh giá và thường xuyên đánh giá mã React – trước tiên bạn nên thiết lập một số quy tắc.
Họ sẽ giúp bạn bớt tức giận hơn, vì người cung cấp dịch vụ phát triển React và chuẩn bị đánh giá mã sẽ có các bước cụ thể cần thực hiện trước khi gửi mã cho bạn.
Có một số mẹo tôi thực sự thích trong quá trình xem xét mã và tôi cho là rất hữu ích:
1. Đảm bảo rằng mã được viết đúng cách trước khi gửi.
Linting là quá trình phân tích mã để xác định các lỗi tiềm ẩn, vi phạm kiểu mã hóa và các vấn đề khác. Nó giúp cải thiện chất lượng mã, phát hiện lỗi sớm và thúc đẩy các tiêu chuẩn mã hóa nhất quán trong toàn bộ dự án. Nếu các nhà phát triển làm việc tích cực và xử lý nó trước khi gửi, nó có thể cải thiện đáng kể toàn bộ quá trình đánh giá.
2. Khuyến khích các nhà phát triển tự xem lại mã của họ trước khi chia sẻ mã đó với bạn, vì nó giúp phát hiện các vấn đề cơ bản như console logs, bad formatting, v.v.
Nhà phát triển nên thực hiện việc này trên nền tảng trước khi chia sẻ liên kết với người đánh giá. Điều đó thường giúp giải quyết một số nhận xét không cần thiết, console.log, định dạng sai và các phần còn sót lại khác.
3. Yêu cầu mô tả những thay đổi đã được thực hiện trong pull request. Nó cung cấp bối cảnh cho người đánh giá.
Nó không cần phải quá chi tiết, nhưng đại loại như “Thêm một trang mới cho danh sách người chơi bằng bảng, bảng có phân trang nhưng không thể sắp xếp hoặc lọc được. Hiện tại, chúng tôi phải sử dụng mô hình dữ liệu vì API chưa sẵn sàng.” sẽ hiển thị bối cảnh tổng thể của mã được thiết kế quá mức.
4. Cân nhắc việc đính kèm ảnh chụp màn hình công việc đã thực hiện để hỗ trợ người đánh giá.
Đôi khi, việc gửi một số ảnh chụp màn hình cũng là một điều tốt để người đánh giá không phải chạy dự án (trừ khi anh ta cũng phải kiểm tra nó).
Bổ sung: Tránh tạo pull request với số lượng lớn tệp. Các yêu cầu kéo nhỏ hơn, tập trung hơn sẽ dễ dàng xem xét hơn và cung cấp phản hồi hữu ích hơn.
Nhiều tệp hơn = ít nhận xét hơn, vì không ai có thể kiểm tra điều đó một cách chính xác – sẽ mất nhiều thời gian. Nếu bạn có một tính năng lớn – bạn có thể tạo một nhánh cho nó và sau đó tạo các nhánh phụ nhỏ hơn với các tính năng nhỏ hơn.
Một vài điều này chỉ là một ví dụ và tôi muốn khuyến khích bạn thiết lập các quy tắc của riêng mình theo cách bạn muốn.
NHỮNG ĐIỀU CHUNG CẦN XEM XÉT KHI TIẾN HÀNH ĐÁNH GIÁ MÃ REACT
Làm việc trong cùng một nhóm React
Mặt khác, nếu bạn chỉ chịu trách nhiệm đánh giá mã chứ không làm việc với chính dự án – đừng cảm thấy tiếc vì những điều bạn không biết. Không ai sẽ đổ lỗi cho bạn về chức năng hoặc cấu trúc mã không hoạt động và bạn đã không nhận thấy điều đó.
Nói chung, rất khó để tìm ra lỗi trong quá trình đó và nếu bạn tìm thấy bất kỳ lỗi nào – điều đó thật tuyệt! Nhưng hãy sẵn sàng hỏi thêm chi tiết hoặc tại sao một số thành phần con được thực hiện theo cách này hoặc cách kia mà không phải cách khác. Hãy thực sự tò mò.
Hiển thị nhận xét
Việc đảm bảo rằng mọi người tham gia vào quá trình xem xét mã đều có thể nhìn thấy nhận xét sẽ giúp duy trì tính minh bạch và cho phép người khác hiểu được bối cảnh của cuộc thảo luận. Nó ngăn ngừa việc mất đi những phản hồi quan trọng và mang tính xây dựng, đồng thời thúc đẩy trải nghiệm đánh giá mã mang tính toàn diện và mang tính xây dựng hơn.
Cho biết thời gian
Nếu bạn không có thời gian để xem lại mã thích hợp – hãy thêm nó dưới dạng ghi chú.
Ví dụ: “Tôi chỉ có 15 phút nên tôi chỉ kiểm tra nhanh những thứ quan trọng nhất như A, B, C.” .
Hãy nhớ rằng – nếu một người yêu cầu bạn đánh giá, hãy cho họ biết khi nào bạn có thời gian cho việc đó. Ngay cả một số nhà phát triển React giỏi cũng có xu hướng chỉ đợi cho đến khi bạn hoàn thành việc đánh giá và gửi lại mã cho họ.
Ví dụ: nếu bạn nói với họ rằng bạn sẽ làm việc đó vào ngày hôm sau – họ có thể tìm một số công việc khác để làm trong thời gian chờ đợi.
Đừng lãng phí thời gian vào các vấn đề về kiểu dáng
Nói chung, hầu hết các nhận xét trong bài đánh giá mã React (tôi đã xem) đều là về các vấn đề về kiểu dáng – và cá nhân tôi không thích chúng.
Nếu bạn gặp phải những lo ngại về kiểu dáng trong toàn bộ cơ sở mã React, hãy giải quyết chúng một lần và đề xuất giải pháp để ngăn chúng tái diễn trong tương lai.
Cách tiếp cận này đảm bảo quá trình xem xét suôn sẻ hơn và tránh nhận xét lặp đi lặp lại trên mỗi yêu cầu.
18 Mẹo để kiểm tra code React của bạn tốt hơn
Dưới đây là tổng quan đầy đủ về danh sách kiểm tra các mẹo của chúng tôi và những điều cần kiểm tra để thực hiện Đánh giá mã React tốt hơn và cung cấp các ứng dụng phản ứng tốt hơn:
- Kiểm tra xem có gói npm mới nào được thêm vào không .
- Kiểm tra xem có chức năng nào trùng lặp như date-fns + moment hay không.
- Ngoài ra, hãy kiểm tra import , vì đôi khi tính năng tree shaking không hoạt động như bạn muốn và bạn có thể gói toàn bộ thư viện và chỉ sử dụng một phương pháp duy nhất như dưới đây:
- Nếu ứng dụng của bạn đang sử dụng bản dịch – hãy kiểm tra xem tất cả các khu vực mới cũng có bản dịch hay không. Nếu không, hãy chỉ ra điều đó và nhà phát triển sẽ biết điều đó trong tương lai.
- Kiểm tra các type bị thiếu hoặc không hợp lệ nếu bạn đang sử dụng TypeScript. Tất cả các loại “ BẤT KỲ ” cũng phải được sửa trừ khi bạn có lời giải thích thực sự, thực sự hợp lý cho việc không làm như vậy. Dưới đây chúng tôi thiếu các loại đạo cụ và bất kỳ loại nào trong phương thức.
- Kiểm tra các biến, hàm và quy ước đặt tên . Tất cả họ nên tuyên bố họ là ai và họ làm gì.
- Đối với các giá trị boolean, hãy sử dụng tiền tố is/are/nên khai báo hành vi của chúng (hiển thị => isVisible) để tránh coi chúng là thuộc tính HTML.
- Đảm bảo các hàm khai báo mục đích của chúng và nếu chúng trả về bất cứ thứ gì, hãy đặt tên cho chúng cho phù hợp. Ví dụ: nếu họ thao tác dữ liệu: updateUsers => addUniqId, ParseData => ParsToAPIFormat, v.v.
- Kiểm tra các mẫu logic kỳ lạ (những thứ bạn chưa từng thấy trước đây). Đôi khi, nhà phát triển React mất quá nhiều thời gian cho một nhiệm vụ – họ bắt đầu thực sự sáng tạo trong khi viết mã và tạo ra các phương thức hoặc quy trình vô nghĩa và có thể phá hủy cấu trúc dự án. Bạn nên cung cấp phản hồi và đề xuất giải pháp phù hợp hơn để đưa ra code tốt hơn.
- Kiểm tra các đoạn mã quá phức tạp . Nếu ai đó đang thêm ID vào một mảng bằng 20 dòng mã thay vì 1, hãy thực hiện một số hành động. Hoặc khi bạn đang sử dụng một số gói của bên thứ 3 như lodash , nhưng nhà phát triển vẫn tự mình viết tất cả các phương thức.
- Nếu bạn không thể hiểu một đoạn mã cụ thể đang làm gì , hãy thêm các nhận xét mô tả để làm rõ mục đích của nó. Ngoài ra, hãy yêu cầu nhà phát triển giải thích để tránh nhầm lẫn trong tương lai.
- Kiểm tra tên, đường dẫn và giá trị được mã hóa cứng . Tách riêng loại mã đó để bạn có thể dễ dàng thay đổi nó ở một nơi. Thay vào đó hãy sử dụng đường dẫn. Chúng (trong hầu hết các trường hợp) được sử dụng trong cấu hình định tuyến và trong mọi liên kết và chuyển hướng. Ngoài ra, còn có các loại, định dạng ngày tháng riêng biệt và mọi thứ có thể được sử dụng ở nhiều nơi – để dễ dàng thay đổi chúng.
- Kiểm tra các vấn đề tương thích ngược như thay đổi đạo cụ từ tùy chọn sang bắt buộc . Hoặc thay đổi loại tham số của một số phương thức. Nếu bạn thực hiện thay đổi như vậy với TypeScript – nó sẽ gây ra lỗi biên dịch. Nếu bạn chỉ sử dụng JavaScript – bạn cần theo dõi thủ công.
- Kiểm tra sự lặp lại mã . Nếu bạn đã thấy logic giống nhau/tương tự ở nhiều nơi – hãy chỉ ra điều đó. Mã phải có thể tái sử dụng được và nếu cần cập nhật logic đó, bạn sẽ phải cập nhật nó ở một nơi duy nhất. Không phải 3 trong số họ.
- Kiểm tra xác thực biểu mẫu bị thiếu hoặc xác thực biểu mẫu không chính xác. Tôi chưa bao giờ thấy ứng dụng React có biểu mẫu mà không cần xác thực trường.
- Kiểm tra các trình xử lý lỗi bị thiếu trong phản hồi API để cung cấp phản hồi thích hợp cho người dùng. Hãy chú ý đến các khối thử/bắt và cách xử lý chúng trong quá trình bắt.
- Kiểm tra các phương thức không đồng bộ – chúng có thể được thực hiện song song hay chúng ta cần tất cả dữ liệu theo một trình tự? Kiểm tra xem chúng tôi có thực sự đợi dữ liệu này nếu chúng tôi cần hay không hoặc liệu chúng tôi có đọc từ đối tượng lời hứa hay không.
- Đôi khi bạn có thể nhận thấy những lỗi tiềm ẩn . Một phần lớn kiến thức đi kèm với kinh nghiệm. Nếu bạn là một nhà phát triển React giỏi và thấy điều gì đó bạn đã làm trước đây nhưng gây ra lỗi – đừng để điều đó xảy ra lần nữa. Giải thích rằng bạn đã từng ở đó và bạn biết lối thoát như bạn đã làm trước đây.
Tóm tắt
Hãy nhớ rằng – ngay cả khi 10 người xem xét mã của bạn thì đó vẫn là mã của bạn và bạn phải chịu trách nhiệm về mã đó.
Việc thiết lập một số quy tắc sẽ giúp việc hợp tác dễ dàng hơn nhiều.
Đừng quên chỉ ra những điều tốt đẹp nữa.
Nếu bạn cho rằng có điều gì đó không ổn và bạn có ý tưởng về cách khắc phục – hãy đề xuất điều đó – điều đó sẽ đẩy nhanh quá trình.
Đừng chỉ thêm những nhận xét như “đổi A thành B” – hãy thêm lời giải thích hợp lý về lý do nên thay đổi. Ví dụ: “Vui lòng đổi tên từ “changeUserStatus” thành “changeUserData” vì chúng tôi đang thay đổi nhiều trường trong người dùng – không chỉ trạng thái.”
Và tất nhiên, hãy tử tế! Không có ích gì khi khiến nhà phát triển cảm thấy tội lỗi, buồn bã hoặc vô giá trị. Sử dụng ngôn ngữ chính xác sẽ thay đổi ý nghĩa của câu như “A thành B” – “Bạn có thể đổi tên A thành B cho dễ đọc hơn không” . Nói cách khác, hãy đưa ra lý do cho mỗi thay đổi.
Ngoài ra, hãy nhớ trao đổi về trạng thái của quy trình, bất cứ khi nào bạn muốn thảo luận về một số giải pháp hoặc bạn cần thêm một số câu trả lời.
