Làm thế nào để thực hiện đánh giá mã tốt hơn khi yêu cầu kéo lớn?

Tuyên bố miễn trừ trách nhiệm: Có một số câu hỏi tương tự, nhưng tôi không tìm thấy câu hỏi nào liên quan cụ thể đến các vấn đề bạn gặp phải trong khi xem xét yêu cầu kéo lớn.

Vấn đề

Tôi cảm thấy đánh giá mã của tôi có thể được thực hiện theo cách tốt hơn. Tôi đặc biệt nói về các đánh giá mã lớn với nhiều thay đổi trên 20 tệp.

Nó khá đơn giản để nắm bắt các vấn đề mã địa phương rõ ràng. Hiểu được liệu mã đáp ứng tiêu chí kinh doanh là một câu chuyện khác nhau mặc dù.

Tôi gặp rắc rối sau quá trình suy nghĩ của tác giả mã. Thật khó khi các thay đổi có rất nhiều và trải rộng trên nhiều tệp. Tôi cố gắng tập trung vào các nhóm tệp liên quan đến một phần thay đổi cụ thể. Sau đó xem lại từng nhóm một. Thật không may, công cụ tôi sử dụng (Atlassian Bitbucket) không hữu ích lắm. Bất cứ khi nào tôi truy cập một tập tin, nó sẽ được đánh dấu như đã thấy, mặc dù nó thường không liên quan đến các thay đổi hiện đang được kiểm tra. Chưa kể rằng một số tệp nên được truy cập nhiều lần và các thay đổi của chúng được xem xét từng mảnh một. Cũng quay trở lại các tệp có liên quan khi bạn đi theo một con đường xấu không dễ dàng.

Các giải pháp khả thi và tại sao chúng không hiệu quả với tôi

Xem xét yêu cầu kéo bằng các cam kết thường giải quyết các vấn đề về kích thước, nhưng tôi không thích nó vì tôi thường xuyên nhìn vào các thay đổi lỗi thời.

Tất nhiên, việc tạo các yêu cầu kéo nhỏ hơn có vẻ như là một biện pháp khắc phục, nhưng đó là những gì nó có, đôi khi bạn nhận được một yêu cầu kéo lớn và nó phải được xem xét.

Bạn cũng có thể bỏ qua khía cạnh logic của toàn bộ mã, nhưng có vẻ khá rủi ro, đặc biệt khi mã đến từ một lập trình viên thiếu kinh nghiệm.

Sử dụng một công cụ tốt hơn có thể hữu ích, nhưng tôi đã không tìm thấy.

Câu hỏi

• Bạn có vấn đề tương tự với đánh giá mã của bạn? Làm thế nào để bạn đối mặt với họ?
• Có lẽ bạn có công cụ tốt hơn?

Chúng tôi đã có những vấn đề này và đặt câu hỏi dưới đây đã làm việc tốt cho chúng tôi:

PR có làm một điều có thể được hợp nhất và có thể được kiểm tra độc lập không?

Chúng tôi cố gắng phá vỡ PR bằng trách nhiệm duy nhất (SR). Sau những người đẩy lùi ban đầu đã rất ngạc nhiên khi thấy rằng ngay cả một cái gì đó nhỏ dù có thể lớn.

SR làm cho nó thực sự dễ dàng để xem xét và cũng phổ biến kiến ​​thức về việc thực hiện dự kiến.

Điều này cũng cho phép các nhà tái cấu trúc gia tăng khi được thêm vào và thời gian quay vòng PR giảm đáng kể!

Tôi khuyên bạn nên phá vỡ chúng bằng SR nếu có thể và xem nó có hiệu quả với bạn không. Có một số thực hành để làm điều đó theo cách đó.

Đôi khi bạn không thể tránh các yêu cầu kéo lớn - nhưng bạn có thể sáng suốt xem ai có trách nhiệm gì.

Tôi coi các yêu cầu kéo như là lý lẽ thuyết phục. Tác giả đang cố gắng thuyết phục tôi rằng mã nên nhìn và hoạt động theo cách này.

Như với bất kỳ đối số, nó nên có một ý tưởng rõ ràng duy nhất. Nó cũng vậy:

• một người tái cấu trúc
• tối ưu hóa
• hoặc chức năng mới.

Nếu họ không rõ ràng, thì có khả năng họ không hiểu điều đó. Mở cuộc đối thoại và giúp họ chia nhỏ lập luận của họ thành các đối số phụ của nó. Nếu cần, nó hoàn toàn ổn - thậm chí có lợi cho họ để tạo lại những cam kết đó, và đưa ra các yêu cầu kéo trực tiếp và dễ hiểu hơn.

Vẫn sẽ có những yêu cầu kéo lớn, nhưng với một lập luận rõ ràng sẽ dễ dàng hơn nhiều để xem những gì không phù hợp.

Đối với công cụ, nó phụ thuộc vào tổ chức và quy trình của bạn. BitBucket là một công cụ tốt, dù tốt hơn hay không phụ thuộc vào mọi thứ từ ngân sách, phần cứng, yêu cầu của bạn, cho đến các quy trình, quy tắc kinh doanh và các phần mềm khác nhau mà bạn đã thực hiện để phù hợp với BitBucket. Tôi sẽ bắt đầu bằng cách xem qua tài liệu để xem liệu hành vi có thể được cấu hình hay không, có thể đưa ra cộng đồng plugin (hoặc tham gia nó bằng cách tạo một plugin để làm điều đó).

Đừng xem lại yêu cầu kéo hoàn chỉnh, nhưng mỗi cam kết. Dù sao bạn cũng sẽ hiểu rõ hơn về yêu cầu kéo bằng cách thực hiện theo cách này .¹

Nếu các cam kết là nhỏ, thực hiện đánh giá như vậy không phải là một vấn đề. Bạn theo dõi từng thay đổi thông qua các cam kết và cuối cùng bạn sẽ có được bức tranh đầy đủ. Có những nhược điểm, chẳng hạn như đôi khi bạn sẽ xem xét các thay đổi sẽ được hoàn tác sau một vài lần cam kết, nhưng điều này không nên là một vấn đề lớn.

Nếu các cam kết lớn, thì bạn nên thảo luận với người đã thực hiện các cam kết đó. Giải thích cho anh ta tại sao các cam kết lớn là có vấn đề. Lắng nghe những tranh luận của người khác về lý do tại sao anh ta thực hiện các thay đổi hiếm khi: ví dụ, bạn có thể biết rằng anh ta tránh thực hiện các cam kết vì các móc nối trước mất quá nhiều thời gian, trong trường hợp này, vấn đề này cần được giải quyết trước tiên.

Xem xét yêu cầu kéo bằng các cam kết thường giải quyết các vấn đề về kích thước, nhưng tôi không thích nó vì tôi thường xuyên nhìn vào các thay đổi lỗi thời.

Bạn làm vậy, nhưng đây chỉ là một vấn đề nhỏ và bạn nên lãng phí ít thời gian hơn để xem lại mã sẽ được hoàn tác sau một vài lần so với thời gian bạn lãng phí khi cố gắng tìm hiểu tại sao mã bị thay đổi khi xem lại một tệp.

Thường xuyên có thể rất mơ hồ, nhưng nếu bạn thấy mình dành quá nhiều thời gian để xem lại mã mà không tìm được cách sửa đổi cuối cùng của yêu cầu kéo, bạn có thể sử dụng hai kỹ thuật:

• Đi nhanh qua tất cả các cam kết một lần, chỉ cần đọc các thông điệp cam kết. Bằng cách này, khi nghiên cứu một cam kết cụ thể, bạn có thể nhớ rằng một thông điệp cam kết ở đâu đó sau đó nói rằng sự thay đổi mà bạn đang xem đã được hoàn nguyên.

• Có chế độ xem cạnh nhau của phiên bản mới nhất của tệp (mặc dù trong nhiều trường hợp, đối với các cam kết lớn, (1) các tệp có thể khác nhau hoàn toàn và (2) các tệp có thể được đổi tên hoặc các khối mã lớn có thể được chuyển đi nơi khác, gây khó khăn cho việc tìm tệp phù hợp).

• Hoặc yêu cầu người ủy quyền xóa sổ cam kết khi có ý nghĩa hoặc có một quy ước thông điệp cam kết cụ thể trong đó một cam kết hoàn tác một phần của một cam kết khác và xem xét của bạn có tính đến một số cam kết sau đây.

^{Instance Ví dụ, hãy tưởng tượng bạn đang xem một tệp trong đó một số biến đã được đổi tên. Nó nói gì với bạn? Làm thế nào bạn nên xem lại sự thay đổi này? Tuy nhiên, nếu bạn đang xem xét cam kết bằng cam kết, bạn sẽ thấy rằng một cam kết duy nhất đã đổi tên cùng một biến trong hai mươi tệp và nhận xét cho biết tên đã được thay đổi để sử dụng thuật ngữ kinh doanh phù hợp. Sự thay đổi này có ý nghĩa hoàn hảo và có thể xem xét.}

Tìm ra những gì bạn đang cố gắng đạt được với các đánh giá về yêu cầu kéo và xem liệu có cách nào khác không.

Ví dụ, bạn có thể muốn

• Đảm bảo các tiêu chuẩn được tuân theo
• Kiểm tra chức năng là chính xác
• Hãy chắc chắn rằng nhiều người hiểu mã
• Đào tạo đàn em

Vân vân.

Một số trong số này có thể được phục vụ tốt hơn bởi những thứ khác và thậm chí chỉ cần hiểu lý do cho phép bạn giới hạn phạm vi kiểm tra của mình.

Ví dụ: nếu tôi đang kiểm tra từng dòng để tôi có thể đề xuất và loại bỏ các thay đổi cho đào tạo, thì tôi có thể bỏ qua điều đó trên một PR lớn được thực hiện bởi người cao niên

Nếu tôi cần hiểu mã, có thể thực hiện lập trình cặp trên các tính năng lớn và giới hạn đánh giá mã để kiểm tra tiêu chuẩn.

Bạn không cần phải kiểm tra tất cả mọi thứ trên mỗi PR miễn là bạn có cách tiếp cận nhiều lớp với QA