Có yêu cầu kéo là nơi đào tạo đàn em

Chúng tôi có một khái niệm rằng tất cả các mã trong Yêu cầu kéo thành chủ nên sẵn sàng sản xuất. Điều này có ý nghĩa và là một tuyên bố công bằng theo ý kiến ​​của tôi.

Ý tưởng ở đây là một khi bạn tạo PR, bạn nói rằng bạn sẽ đặt nó thành chủ, nhưng muốn một số nhà phê bình chỉ đơn giản là 'đồng tình' với bạn và phát hiện ra bất cứ điều gì bạn bỏ lỡ.

Vì chúng tôi chỉ là con người, chúng tôi mắc lỗi và hy vọng rằng những người đánh giá khác có thể tìm thấy các mục mà bài kiểm tra đơn vị không thể tìm thấy - lỗi chính tả, javadocs không chính xác, v.v.

NHƯNG, là một Yêu cầu Kéo là nơi chúng ta sẽ cung cấp một số mức hỗ trợ / đào tạo cho các nhà phát triển và nếu vậy, đến mức nào?

Mỗi khi bạn thúc đẩy các thay đổi mới, người đánh giá phải xem xét lại các thay đổi của bạn, điều này mất từ ​​thời gian phát triển của họ và gây ra việc xem xét lại các thay đổi.

Vì vậy, nên cho phép đào tạo bao nhiêu, trong Yêu cầu Kéo? Một phần trong tôi cảm thấy nó thay đổi từ đàn em đến đàn anh. Tuy nhiên tôi cũng cảm thấy rằng đó không phải là nơi để tìm ra vô số vấn đề - ngay cả đối với đàn em.

Có ai khác đang vật lộn với việc cố gắng để các nhà phát triển đạt được mục tiêu "Yêu cầu kéo của tôi phải sẵn sàng sản xuất" không?

Không. Yêu cầu kéo không phải là nơi đào tạo. Nhóm của bạn có ý tưởng đúng. Một PR có nghĩa là "Tôi nghĩ rằng nó tốt để đi. Tôi có thể có được một đôi mắt thứ hai trong trường hợp tôi bỏ lỡ một cái gì đó. Rốt cuộc tôi là con người." Và tôi nghi ngờ đó chính xác là những gì người học việc của bạn đang làm. Họ thành thật nghĩ rằng nó tốt để đi.

Đây là một ý tưởng cực đoan (ý định chơi chữ). Chương trình ghép đôi với người học việc khiến bạn đau lòng. Là một thành viên nhóm cao cấp hơn, công việc của bạn là nâng họ lên và làm cho họ làm việc hiệu quả.

Nếu mã vi phạm các nguyên tắc thiết kế cốt lõi hoặc tiêu chuẩn của nhóm đưa nó đến giai đoạn yêu cầu kéo, thì nó chắc chắn phải được giải quyết ở đó. Và đánh giá mã có thể là một phương tiện tốt để truyền đạt các tiêu chuẩn và thực hành thiết kế của nhóm.

Nhưng nó là nơi tốt nhất? Đây là một số lý do tại sao tôi sẽ nói không:

1. Nếu phải mất một vài lần lặp lại đánh giá mã để giải quyết một lỗi thiết kế cơ bản hoặc vấn đề quy mô lớn, thì sẽ có một sự cám dỗ mạnh mẽ để bỏ qua các vấn đề nhỏ hơn được đề cập ở trên, do thời hạn hoặc kiệt sức chung với đánh giá. Lý tưởng nhất là nhóm sẽ đủ kiên cường để chống lại sự cám dỗ này, nhưng có lẽ tốt nhất là không tạo ra một tình huống sẽ dẫn đến nó.
2. Nhận được một đánh giá mã với một số lượng lớn ý kiến ​​không phải là một kinh nghiệm tuyệt vời cho một nhà phát triển thuê mới / thiếu niên. Đúng, trả lời phản hồi là một kỹ năng họ sẽ cần phát triển, nhưng cũng đúng là các nhà phát triển không phải lúc nào cũng có kỹ năng đáp ứng một cách khéo léo mã mà họ không thích.

Đánh giá cặp lập trình và thiết kế là địa điểm thích hợp cho phản hồi quy mô lớn hơn.

Điều đó nói rằng, sẽ còn tồi tệ hơn khi để mã đi qua vì sợ rằng việc giải quyết nó trong quá trình đánh giá mã là "sai", và có thể có một số trường hợp (ví dụ như các đội từ xa) trong đó đây là cách tốt nhất bạn có thể làm. Trong trường hợp đó, hãy giải quyết các vấn đề trong đánh giá mã và cũng giải quyết các vấn đề trong quy trình phát triển của bạn mà nó đã đạt được điều này.

Mặc dù việc tìm kiếm sự cố trong khi yêu cầu kéo có thể không lý tưởng, nhưng nó chắc chắn tốt hơn trong thử nghiệm hoặc trong một vấn đề sản xuất.

Tôi sẽ diễn đạt nó nhiều hơn vì các yêu cầu kéo không phải là nơi duy nhất bạn đào tạo mọi người. Ngoài ra, các nhà phát triển cơ sở không phải là những người duy nhất có thể cần được đào tạo về yêu cầu kéo. Các nhà thầu, những người đóng góp mã nguồn mở, các nhà phát triển từ các bộ phận khác không quen thuộc với mã hoặc tiêu chuẩn địa phương và thậm chí các lập trình viên kỳ cựu cũng cần nhắc nhở thỉnh thoảng khi họ tự mãn.

Có rất ít chi phí để giữ một yêu cầu kéo mở trong một thời gian. Cung cấp cho nó nhiều hoặc ít phản hồi tùy thích, bao nhiêu người tùy thích, sau đó để yên cho đến khi các tác giả thông báo lại cho bạn rằng họ nghĩ rằng nó đã sẵn sàng để hợp nhất. Yêu cầu kéo là một công cụ trung tâm tuyệt vời để truyền đạt về các thay đổi mã được đề xuất, cho dù chúng hoàn toàn sẵn sàng hay cần nhiều công việc.

Một số đánh giá yêu cầu kéo ra ít hơn một con dấu cao su và một số bài nộp bên ngoài cho một đội có thể mất một tháng qua lại. Loại thứ nhất là tốt khi bạn có thể có được nó, nhưng điều đó không có nghĩa là loại thứ hai không có giá trị. Cố gắng để mọi người gửi yêu cầu kéo hoàn hảo mọi lúc sẽ chỉ gây khó chịu cho mọi người.

Tôi luôn cảm thấy rằng một trong những đặc điểm nổi bật của một người lãnh đạo giỏi là người cung cấp đào tạo bổ sung khi cần thiết trong mỗi chu kỳ phát triển. Đối với tôi, điều đó có nghĩa là tôi không chỉ tự viết mã, hoặc xem xét mã, mà còn ngồi với nhiều nhà phát triển cơ sở hơn, kết hợp lập trình với họ để giúp họ tránh các loại mỏ đất mà tôi đã bước vào.

Chủ yếu, tôi không ảo tưởng rằng mục tiêu chính của chúng tôi là giáo dục - không phải vậy. Cho dù bạn là người cao cấp, người dẫn đầu hay nhà phát triển cơ sở, mục tiêu không phải là sự thay đổi của bạn. Mục tiêu là luôn cung cấp mã chất lượng cho khách hàng. Tốt nhất là về thời gian, ngân sách, làm những gì họ muốn. Tuy nhiên, tôi nhận ra rằng tôi không thể tự mình hoàn thành mọi công việc, vì vậy điều đó là đương nhiên với tôi để giúp mọi người giúp nhóm thành công. Và điều đó có nghĩa là nhận ra cơ hội đào tạo khi chúng xuất hiện trong tự nhiên.

Vì vậy, đối với câu hỏi của bạn về việc liệu các yêu cầu kéo có phải là nơi đào tạo đàn em hay không, tôi sẽ phải nói rằng không có gì lạ khi những khoảnh khắc có thể dạy được phát sinh trong những lúc này. Này, bạn sẽ phải đối phó với xung đột hợp nhất đầu tiên của mình, hãy xem xét lại sau khi xem xét. Hãy nhìn xem, bạn đã không bao gồm bất kỳ bài kiểm tra đơn vị nào cho DAO của bạn, chúng tôi sẽ hoãn đánh giá của bạn cho đến khi chúng tôi có cơ hội đề cập đến các phương pháp mới đó. Tại sao bạn nghĩ rằng sẽ tốt hơn nếu sử dụng nguyên thủy kép trong tính toán tài chính này hơn BigDecimals? Vâng, đó không phải là hiếm.

Vì vậy, trong khi tôi sẽ nói rằng điều đó chắc chắn có thể xảy ra, nhưng rõ ràng đó không phải là mục tiêu chính của yêu cầu kéo. Tôi cũng không cảm thấy có một kỳ vọng rằng mã trong yêu cầu kéo đã sẵn sàng sản xuất. Thường thì không.

Nếu bạn đang sử dụng tính năng và phát hành các nhánh trong chiến lược phân nhánh theo kiểu gitflow, thì các yêu cầu kéo của bạn sẽ trở thành một thứ giống như các ứng cử viên phát hành. Không sẵn sàng sản xuất, nhưng một cái gì đó gần đúng hơn nó. Bạn biết mã của bạn biên dịch (phải) và bạn có đủ covfefe thử nghiệm để đưa ra một tuyên bố đúng đắn rằng nó đáp ứng các mục tiêu của câu chuyện người dùng. Và vì bạn đã chạy một số thử nghiệm tích hợp trong môi trường phát triển của mình, bạn sẽ có một bản demo tuyệt vời để sẵn sàng nếu bạn được yêu cầu chứng minh những thay đổi của mình, trong quá trình đánh giá PR của bạn.

Cuối cùng, tôi cảm thấy rằng chúng tôi nên cung cấp hỗ trợ trong quá trình đánh giá PR, nhưng sự trợ giúp đó không xoay quanh mã hóa chung. Thay vào đó, nó liên quan đến việc chuẩn bị mã được đề xuất để đưa vào cơ sở làm việc của mã chất lượng sản xuất. PR là cơ hội để các nhà phát triển chứng minh rằng họ có lý do chính đáng và nắm vững, từng thay đổi mà họ đã đưa vào PR. Và ngay cả sau đó - ngay cả sau khi chúng tôi cân nhắc chúng với các bài kiểm tra đơn vị, bản demo và vô số câu hỏi - vẫn không có hy vọng rằng những thay đổi được đề xuất đã sẵn sàng để sản xuất.

Các mã đóng sau tất cả điều đó. Nhưng sau đó chúng tôi để QA tra tấn nó.

Tôi muốn cảm ơn mọi người vì sự đóng góp của họ và giúp tôi hiểu mọi người nói gì về chủ đề này.

Đây là câu trả lời của tôi sau khi phản hồi được đưa ra và sự hiểu biết của tôi bây giờ dựa trên câu trả lời và nhận xét nhận được. Cảm ơn mọi người.

Tóm lược

• Không mong đợi hoặc thực thi các yêu cầu kéo hoàn hảo của dơi vì điều này sẽ chỉ trở nên bực bội cho tất cả những người liên quan.
• Nhưng tiếp tục biến nó thành mục tiêu của chúng tôi cho các Yêu cầu Kéo hoàn hảo.
• Mong đợi một số lượng hợp tác / hỗ trợ trong các yêu cầu kéo. Rốt cuộc, đó là những gì bạn chủ yếu yêu cầu bằng cách tạo Yêu cầu kéo.
• Nếu nó nhận được một chút do lỗi thiết kế hoặc lỗi thực thi, hãy dành thời gian với nhà phát triển đó và thực hiện một số Lập trình cặp để xây dựng chúng và đưa mã của họ đến gần mục tiêu hơn . Đây là vai trò của tất cả các nhà phát triển cao cấp.
• Người cao niên sẽ cần nhiều phiên Lập trình cặp hơn so với nhà phát triển trung gian. Vì vậy, mong đợi các yêu cầu kéo để phản ánh yêu cầu đó.
• Khuyến khích các nhà phát triển tổ chức các cuộc họp thiết kế / triển khai trước khi chạm vào mã để giảm bất kỳ việc làm lại nào được xác định trong Yêu cầu kéo.

Bạn có thể nói thêm về văn hóa công ty của bạn về các nhóm kỹ thuật? Nếu bạn đang vật lộn với ý tưởng mã sẵn sàng để sản xuất khi nhà phát triển muốn hợp nhất vào dòng chính, thì bạn thực sự đang nói gì với nhà phát triển của mình? Bạn đang nói với họ rằng khi công việc của họ "xong", có ổn không nếu nó không hoạt động? Không sao nếu nó phá vỡ hệ thống? Nếu họ đang thêm nợ kỹ thuật, có lẽ điều đó ổn nếu họ có thể biện minh và nhận thức được những gì họ đang làm, và cho thấy rằng họ có thể quay lại và thực hiện tái cấu trúc sau đó. Nhưng nếu họ không biết tại sao họ lại làm điều gì đó nguy hiểm, thì bạn sẽ để nó đi qua bao nhiêu lần?

Nếu bạn có một nhà phát triển cơ sở, một vài yêu cầu kéo đầu tiên của họ rõ ràng sẽ có vấn đề. Cuối cùng, họ sẽ nhận được hang của nó. Nếu bạn thấy rằng họ tiếp tục gặp sự cố, thì bạn có thể chỉ định cho họ làm việc mà họ chưa sẵn sàng?

Hoặc có thể bạn cần thuê một thiếu niên thay thế và sa thải người chưa thể tìm ra?

Bạn biết những gì tôi đã thấy? Những người không phải là nhà phát triển có năng lực tiếp tục làm việc tại một công ty trong nhiều năm chỉ vì gia đình trị. Vì vậy, tất nhiên các yêu cầu kéo của họ yêu cầu nhiều đánh giá. Theo cách nói của Lean, chúng là "chất thải" - lực cản đối với đội và lực cản ở điểm mấu chốt.

Vì vậy, bạn phải tự quyết định: sẽ cần bao nhiêu yêu cầu kéo để đàn em của bạn thể hiện năng lực, và bạn có đủ can đảm để từ bỏ những người không?