Đánh giá mã có thể gây đau đớn. Các kỹ sư phần mềm thường phàn nàn rằng quá trình xem xét diễn ra chậm, làm chậm trễ các tác vụ xuôi dòng và dẫn đến việc chuyển đổi ngữ cảnh khi bạn điều hướng qua lại giữa một yêu cầu kéo mở (PR) và tác vụ tiếp theo của bạn. Các bài đánh giá về mã cũng có thể chứa đầy những phản ứng khó hiểu và đánh lừa xe đạp, khiến cho mọi người tham gia đều có trải nghiệm kém. Để khắc phục sự cố này, một số kỹ sư thậm chí còn đề xuất chúng tôi loại bỏ hoàn toàn các yêu cầu kéo và đánh giá mã. Mặc dù điều đó có thể hiệu quả với các nhóm nhỏ tại các công ty khởi nghiệp, nhưng tôi không nghĩ đây là giải pháp phù hợp cho tất cả mọi người, đặc biệt là các công ty cấp doanh nghiệp. Thay vào đó, có rất nhiều cách để chúng tôi có thể làm cho quá trình xem xét mã trở thành trải nghiệm tốt hơn cho cả tác giả mã và người đánh giá mã. Chúng ta hãy cùng nhau xem xét bảy phương pháp hay nhất này. # 1: Giữ cho các yêu cầu kéo nhỏ Mọi kỹ sư đều lo lắng khi xem xét các yêu cầu kéo có hơn 1000 dòng mã được thay đổi. Những đánh giá này có thể mất hàng giờ để hoàn thành và đôi khi điều cuối cùng xảy ra là người đánh giá bắt đầu đọc lướt qua mã hơn là xem xét cẩn thận. Giải pháp là giữ cho các yêu cầu kéo của bạn ở mức nhỏ. Các bài PR nhỏ được đánh giá dễ dàng và nhanh chóng hơn vì người đánh giá không cần dành nhiều thời gian để xây dựng mô hình tinh thần về cách tất cả các thay đổi hoạt động cùng nhau. Cũng có ít mã được thay đổi hơn, điều này hy vọng tương đương với ít lỗi hơn, ít nhận xét hơn và ít vòng quay qua lại giữa tác giả và người đánh giá hơn. Ban đầu, việc giữ cho các PR của bạn nhỏ có vẻ khó khăn, nhưng bạn có thể thực hiện được nếu bạn chia nhỏ công việc của mình thành những nhiệm vụ nhỏ và luôn tập trung. Không thực hiện tái cấu trúc lớn trong khi triển khai các tính năng mới hoặc sửa lỗi. Sử dụng cờ tính năng trong mã của bạn để bạn có thể hợp nhất các phần nhỏ của các tính năng mới vào nhánh chính mà nó không hiển thị trong ứng dụng sản xuất. Giữ các PR của bạn nhỏ. Người đánh giá của bạn sẽ biết ơn. # 2: Sử dụng Mẫu yêu cầu kéo Một điều khó chịu khác là được yêu cầu xem xét một yêu cầu kéo mà không có bất kỳ ngữ cảnh nào. Khi một PR bị bỏ rơi trong lòng bạn mà không có lời giải thích, bạn thường tự hỏi, “PR này để làm gì? Vấn đề này đang giải quyết là gì? Có một nhiệm vụ liên quan cho việc này? Tại sao cách tiếp cận cụ thể này được thực hiện? " là một biểu mẫu nhỏ, có thể định cấu hình, bạn có thể đặt làm văn bản mặc định cho mọi yêu cầu kéo mới. Mẫu PR nhắc tác giả mã cung cấp các chi tiết liên quan cho bài PR của họ. Thông thường, một mẫu PR sẽ yêu cầu mô tả ngắn gọn về những gì bạn đã làm và lý do, liên kết đến phiếu nhiệm vụ và kế hoạch thử nghiệm để xác nhận các thay đổi. Mẫu yêu cầu kéo Các mẫu PR tốt cũng thường bao gồm một danh sách kiểm tra ngắn để tác giả mã xem qua để đảm bảo rằng họ không bỏ lỡ bất kỳ điều cơ bản nào. Danh sách kiểm tra này có thể bao gồm các mục như kiểm tra đơn vị, tài liệu, quốc tế hóa, hỗ trợ nhiều trình duyệt và khả năng truy cập. Dưới đây là một ví dụ về mẫu yêu cầu kéo mà tôi muốn sử dụng cho tất cả các đại diện của mình: # 3: Triển khai SLA thời gian phản hồi Nếu bạn nhận thấy rằng các yêu cầu kéo không được xem xét lâu hơn bạn muốn, thì bây giờ là thời điểm tốt để đặt kỳ vọng với tư cách là một nhóm về tốc độ xem xét một yêu cầu kéo mới. Nói cách khác, khoảng thời gian tối đa mà một PR có thể tồn tại trước khi nó phải được chọn là bao nhiêu? Một giờ? Hai tiếng? 24 giờ? Câu trả lời của bạn cho câu hỏi đó có thể sẽ phụ thuộc vào quy mô nhóm của bạn. Bạn cũng có thể có một câu trả lời khác cho các yêu cầu kéo nội bộ từ nhóm của bạn so với các yêu cầu kéo bên ngoài từ các nhóm khác. Khi chọn SLA thời gian phản hồi (thỏa thuận mức dịch vụ), bạn sẽ muốn tìm số dư phù hợp. Không hợp lý khi mong đợi mọi người ngay lập tức bỏ bất cứ điều gì họ đang làm và xem xét mã của bạn khi bạn đăng một bài PR mới, nhưng bạn cũng không muốn các bài PR không được đánh giá trong nhiều giờ liên tục. Tìm sự cân bằng phù hợp cho phép đồng đội của bạn vào trạng thái dòng chảy. Họ sẽ có thể làm việc trên mã của riêng họ và sau đó xem xét các bài PR tại các điểm dừng tự nhiên trong suốt cả ngày. Cá nhân tôi thích có SLA thời gian phản hồi hai giờ cho PR của nhóm nội bộ và SLA thời gian phản hồi 24 giờ cho PR của nhóm bên ngoài. Bất kể bạn và đồng đội của bạn quyết định điều gì, có một thỏa thuận nhóm cho phép bạn có trách nhiệm với nhau. Nếu mọi người đã đồng ý với một SLA cụ thể và thời gian đó đã trôi qua cho một trong những PR của bạn, bạn biết bạn có thể bắt đầu làm phiền mọi người về nó. # 4: Đào tạo kỹ sư sơ cấp và trung cấp Cơ hội đào tạo ở khắp mọi nơi. Cố vấn các kỹ sư ít kinh nghiệm hơn không chỉ là dạy họ về các công nghệ và ngôn ngữ mà họ đang làm việc. Nó cũng bao gồm việc dạy họ các kỹ năng mềm như cách thực hiện đánh giá mã hiệu quả. Hướng dẫn đồng đội của bạn những gì bạn tìm kiếm trong quá trình xem xét mã. Giúp họ hiểu điều gì quan trọng và điều gì không. Hướng dẫn họ cách giao tiếp hiệu quả trong các của họ, chẳng hạn như bằng cách bắt đầu các đề xuất không chặn bằng “nit”. nhận xét đánh giá mã Có rất nhiều tài nguyên tuyệt vời về cách trở thành người đánh giá mã hiệu quả hơn. Toàn bộ của Google rất đáng để đọc. Hướng dẫn có lời khuyên tuyệt vời cho cả tác giả mã và người đánh giá mã. Đối với một tài nguyên táo bạo hơn, dễ dàng là một trong những lời khuyên tốt nhất (và thú vị) dành cho các nhà phát triển tạo yêu cầu kéo. Hướng dẫn dành cho nhà phát triển đánh giá mã Cách khiến người đánh giá mã của bạn phải lòng bạn # 5: Thiết lập đường ống tích hợp liên tục Các bài đánh giá mã trở nên tẻ nhạt khi hầu hết các nhận xét là những thứ như “Thiếu dấu chấm phẩy” hoặc “Thụt lề có vẻ không ổn ở đây”. Đừng dành thời gian trong quá trình đánh giá mã về những thứ mà bộ định dạng mã và bộ lót mã có thể giải quyết cho bạn. Hãy để máy tính tự động hóa những việc vặt vãnh để bạn có thể tập trung vào những việc quan trọng cần đến con người. Đối với các dự án JavaScript, thật đơn giản để định cấu hình một trình định dạng như và một trình định dạng như cho repo của bạn. Sau đó, bạn có thể thiết lập tích hợp liên tục cho repo của mình bằng cách sử dụng thứ gì đó như , , hoặc . Prettier ESLint Travis CI CircleCI GitHub Actions GitLab CI / CD Đường dẫn CI của bạn sẽ chạy các tác vụ định dạng và kẻ viền này cho bạn cùng với các bài kiểm tra đơn vị của bạn. Nếu đường ống CI không thành công ở bất kỳ bước nào trên một yêu cầu kéo, nó sẽ chặn yêu cầu kéo đó được hợp nhất. Bây giờ, bạn đã tự động hóa một số phần quan trọng của quá trình xem xét mã, giúp bạn tiết kiệm hàng giờ. # 6: Sử dụng ứng dụng đánh giá yêu cầu kéo Đôi khi, không chỉ cần xem lại mã trong một yêu cầu kéo mà còn phải xem thủ công các thay đổi trong ứng dụng để xác minh rằng mọi thứ trông ổn. Đối với các ứng dụng có các bước thiết lập phức tạp, việc kéo mã của người khác xuống và chạy nó cục bộ trên máy của bạn có thể mất từ năm phút đến một giờ. Thật là đau đầu! Các được sử dụng để tự động triển khai mã của bạn vào một môi trường thử nghiệm ngắn hạn bất kỳ khi nào một PR mới được tạo. Điều này cho phép người đánh giá dễ dàng kiểm tra các thay đổi về giao diện người dùng mà không cần phải kéo mã xuống và chạy nó cục bộ trên máy của họ. Điều này không chỉ tiết kiệm thời gian mà còn thúc đẩy người đánh giá xem xét kỹ lưỡng hơn bằng cách làm cho nó trở nên dễ dàng. ứng dụng đánh giá yêu cầu kéo # 7: Tạo sơ đồ để hình dung các thay đổi mã của bạn Khi xem lại mã trong GitHub hoặc GitLab, các tệp thường được hiển thị theo thứ tự bảng chữ cái. Đối với các PR tương đối nhỏ, đây có thể không phải là vấn đề. Nhưng khi có hàng tá tệp liên quan đến một bài PR, đôi khi sẽ hữu ích khi xem những thay đổi đó được nhóm lại với nhau một cách hợp lý để bạn có thể thấy chúng khớp với nhau như thế nào trong một bức tranh toàn cảnh hơn. giúp bạn hình dung những tệp nào đã được thay đổi và những thay đổi đó ảnh hưởng như thế nào đến các phần phụ thuộc ngược và xuôi của chúng. Họ tích hợp với GitHub để tự động đăng nhận xét và sơ đồ về bài PR của bạn. Bạn thậm chí có thể tạo các chuyến tham quan tương tác về mã của mình để giúp hướng dẫn những người đánh giá mã của bạn. Hơn hết, CodeSee Maps miễn phí cho các tổ chức nguồn mở và kho lưu trữ công khai của họ. Bản đồ đánh giá CodeSee Kết luận: 7 cách để giảm đáng kể thời gian của bạn trong việc xem xét mã Tóm lại, đây là bảy mẹo để giảm đáng kể thời gian của bạn trong việc xem xét mã: Giữ các yêu cầu kéo nhỏ. Sử dụng các mẫu yêu cầu kéo để cung cấp tất cả các ngữ cảnh mà người đánh giá sẽ cần. Triển khai SLA thời gian phản hồi. Đào tạo các kỹ sư cấp cơ sở và cấp trung về những điều chính mà bạn tìm kiếm trong quá trình xem xét mã. Thiết lập đường ống CI để chạy linters, bộ định dạng và kiểm tra đơn vị. Sử dụng các ứng dụng đánh giá yêu cầu kéo để bạn có thể dễ dàng kiểm tra các thay đổi về giao diện người dùng. Tạo sơ đồ để trực quan hóa các thay đổi mã của bạn bằng công cụ như CodeSee Review Maps. Cảm ơn vì đã đọc và viết mã vui vẻ! Cũng được xuất bản tại đây
