Làm thế nào để đối phó với mã 'gần như tốt' từ một nhà phát triển cơ sở? [đóng cửa]

Tôi có một câu hỏi về quản lý đội. Ngay bây giờ tôi đang làm việc với một nhà phát triển cơ sở, những người làm việc từ xa từ một nhà máy mã hóa. Anh chàng cởi mở với những lời chỉ trích và sẵn sàng học hỏi, nhưng tôi có một số nghi ngờ rằng tôi nên đẩy một số thứ.

Ngay bây giờ khi một cái gì đó thẳng thắn và rõ ràng là vi phạm các thông lệ tốt: như vi phạm SRP, các đối tượng của Chúa, các tên không có ý nghĩa cho các phương thức hoặc biến; Tôi chỉ ra những gì anh ấy phải sửa chữa và cố gắng giải thích tại sao nó sai.

Câu hỏi của tôi là: khi nào tôi dừng lại? Ngay bây giờ nếu có một số vi phạm nhỏ về kiểu mã hóa như tên biến trong ngôn ngữ sai (nhóm trước trộn lẫn tiếng Tây Ban Nha và tiếng Anh và tôi đang cố gắng khắc phục điều đó), hoặc một số vấn đề nhỏ về cấu trúc tôi sẽ bỏ qua và sửa nó nếu Tôi có bất kỳ thời gian rảnh hoặc tình cờ cần phải sửa đổi lớp có vấn đề. Tôi cảm thấy điều này tốt cho tinh thần đồng đội vì vậy tôi không liên tục đẩy lùi mã về những gì người mới có thể giống như những chi tiết nhỏ, có thể khá bực bội, nhưng tôi cũng lo lắng rằng việc quá 'mềm' có thể ngăn cản anh chàng từ việc học cách làm một số thứ.

Làm thế nào để tôi cân bằng ranh giới giữa việc dạy anh chàng và không đốt cháy anh ta với những lời chỉ trích liên tục? Đối với một thiếu niên, nó có thể gây bực bội nếu bạn bảo anh ta làm lại những thứ mà mắt anh ta đang làm việc.

Nếu bạn nghĩ rằng mã nên được sửa trước khi hợp nhất, hãy bình luận. Tốt nhất là với "tại sao" để nhà phát triển có thể học hỏi.

Hãy nhớ rằng mã được đọc thường xuyên hơn nhiều so với viết. Vì vậy, những thứ có vẻ "nhỏ" thực sự có thể thực sự quan trọng (ví dụ tên biến).

Tuy nhiên, nếu bạn thấy mình đưa ra những bình luận có vẻ tẻ nhạt, có lẽ nên cân nhắc:

• Quá trình CI của bạn có nên nắm bắt những điều này?
• Bạn có một "hướng dẫn dành cho nhà phát triển" rõ ràng để tham khảo (hoặc mọi thứ được ghi lại trong đầu bạn) không?
• Những ý kiến ​​này thực sự đóng góp cho chất lượng mã?

Rất nhiều người hy sinh năng suất tại bàn thờ của quá trình hoặc sự hoàn hảo. Hãy cẩn thận bạn không làm điều này.

Cố gắng đến gặp đồng nghiệp của bạn trong người nếu có thể. Hoặc sử dụng các cuộc gọi video. Xây dựng mối quan hệ làm cho những lời chỉ trích (thậm chí đánh giá mã) dễ quản lý hơn.

Nếu bạn thấy rằng một đoạn mã có quá nhiều vấn đề qua lại, hãy yêu cầu xem xét lại các đoạn mã nhỏ hơn. Thay đổi tăng dần có nhiều khả năng tránh một số vấn đề thiết kế quan trọng hơn, bởi vì chúng theo định nghĩa nhỏ hơn.

Nhưng tuyệt đối không hợp nhất công cụ và sau đó quay lại và sửa nó. Điều này là tích cực thụ động và nếu nhà phát triển thấy bạn làm điều này, bạn sẽ giết chết tinh thần của họ.

Giữ những lời chỉ trích về mã hơn là người viết.

Bất kỳ tác phẩm được sản xuất đi kèm với tình cảm gắn bó vốn có. Xem xét giảm bớt điều này bằng cách tách mã từ người viết càng nhiều càng tốt. Chất lượng của mã phải được thiết lập một cách nhất quán như một mục tiêu chung mà cả hai bạn cùng đối mặt, thay vì một điểm ma sát giữa hai bạn.

Một cách để đạt được điều này là khôn ngoan chọn từ của bạn. Mặc dù các cá nhân STEM thích nghĩ mình có tính logic cao, cảm xúc là một phần của bản chất con người. Verbiage được sử dụng có thể là sự khác biệt giữa cảm giác bị tổn thương hoặc bị ảnh hưởng. Nói "Tên hàm này sẽ phù hợp hơn với các quy ước nếu nó bằng tiếng Anh" thì tốt hơn là "Bạn đã viết sai tên hàm này và nó phải bằng tiếng Anh." Mặc dù cái sau vẫn còn thuần hóa và một mình có vẻ ổn, nhưng so với lỗi trước đây thì rõ ràng - khi chuẩn bị những gì cần nói trực tiếp hoặc email kiểm tra xem ngữ cảnh, từ ngữ và trọng tâm của bạn có phải là vấn đề hay không người .

Ngôn ngữ cơ thể

Trong khi các từ là quan trọng, hầu hết giao tiếp là phi ngôn ngữ. Hãy chú ý đến ngôn ngữ cơ thể, thậm chí là những sự tinh tế dường như không đáng kể như mattter định hướng, ví dụ: Nhiều tương tác cấp cao xảy ra trực diện, nhưng cách tiếp cận bên cạnh sẽ có lợi hơn cho kết quả mong muốn của bạn.

Cho phản hồi tích cực trung thực

Nhiều nghiên cứu cho thấy thông tin được học nhanh hơn và được giữ lại tốt hơn khi chúng ta thưởng cho hành vi tốt thay vì trừng phạt những hành vi xấu. Đôi khi chỉ cần lưu ý rằng hiệu suất đã được cải thiện với một "công việc tốt" đơn giản hoặc cụ thể hơn "Tôi nhận thấy gần đây rằng phong cách của bạn đã phù hợp với tiêu chuẩn của chúng tôi với một tee, công việc tuyệt vời!" thậm chí bổ sung sự công nhận cải tiến này bằng cách nhờ họ, lần lượt, tư vấn cho người khác về các vấn đề họ đã sửa đổi có thể tạo ra tất cả sự khác biệt cho nhà phát triển cơ sở và công việc của anh ấy.

Anh chàng cởi mở với những lời chỉ trích và sẵn sàng học hỏi, nhưng tôi có một số nghi ngờ rằng tôi nên đẩy một số thứ.

Đẩy mọi thứ bạn có thể. Nếu anh chàng đang học và đó là công việc của bạn để xem lại mã của anh ta, cả hai bạn sẽ có nhiều thứ để đạt được nếu anh ta làm tốt công việc.

Điều đó có nghĩa là ít mã hơn để bạn xem xét trong tương lai và có thể cung cấp cho nhóm của bạn một mục tiêu tuyển dụng.

Ngoài ra, nếu bạn giữ lại, bạn sẽ không giúp đỡ, nhưng bảo trợ.

Chỉ bằng việc bạn đăng câu hỏi của bạn ở đây, hỏi bạn có làm quá nhiều không, đã ký cho tôi rằng bạn không cần lời khuyên cụ thể này, nhưng đối với những người khác, đây là: Chỉ cần nhớ rằng đẩy mạnh không có nghĩa là là một thằng ngốc

Trở thành một người cố vấn không phải là một nhiệm vụ dễ dàng. Bạn cũng sẽ phải dành một chút không gian để anh ấy mắc lỗi và tự sửa lỗi, chỉ cần chắc chắn rằng anh ấy sẽ làm điều đó ở một nơi không gây thiệt hại thực sự.

Dựa trên mô tả của bạn, tôi sẽ để lại tại: "điều này tốt. Có một vài điều tôi sẽ làm khác đi nhưng chúng không quan trọng lắm."

Khi bạn dường như nắm bắt, những lời chỉ trích có chi phí và nếu bạn dành nhiều thời gian cho các chi tiết gây cười, nó sẽ trở thành một vấn đề tinh thần. Lý tưởng nhất là tất cả các tiêu chuẩn mã hóa được kiểm tra tự động và bạn không thể xây dựng trừ khi bạn tuân theo chúng. Đây là một tiết kiệm thời gian rất lớn và cho phép bạn bắt đầu công việc. Nếu bạn dành những lời phê bình của mình cho 'những điều quan trọng', lời khuyên của bạn sẽ có tác động hơn nhiều và bạn sẽ được coi là một người cố vấn có giá trị. Thật sự rất quan trọng để phân biệt giữa những điều không tốt và những điều không chính xác theo cách bạn sẽ làm.

Tôi tin vào khái niệm của thời điểm có thể dạy được . Nếu nhà phát triển có đủ năng lực tinh thần, anh ta có thể hỏi chi tiết về những gì bạn sẽ làm khác đi. (S) anh ấy có thể không và điều đó ổn. Mọi người bị kiệt sức và sớm trong sự nghiệp, có thể cần rất nhiều năng lượng tinh thần để hoàn thành những điều có vẻ đơn giản sau này.

Tôi sẽ xem xét chấp nhận công việc của mình khi nó được chấp nhận, không hoàn hảo. Và sau đó, nhiệm vụ tiếp theo là sau một cuộc thảo luận để cấu trúc lại nó ngay lập tức bằng cách thực hiện tất cả những thay đổi nhỏ nhưng quan trọng mà bạn muốn.

Vì vậy, khi công việc được chấp nhận lần đầu tiên, thông điệp của bạn là nó không tệ và một số nơi sẽ chấp nhận nó đủ tốt - nhưng không phải là nơi mà bạn muốn trở thành một nhà phát triển cơ sở muốn tìm hiểu giao dịch của mình.

Vì vậy, bạn không nói "Tôi từ chối công việc của bạn vì nó không đủ tốt". Bạn nói (a) "Tôi chấp nhận công việc của bạn vì nó đủ tốt", và sau đó (b) "Nhưng tôi muốn nó tốt hơn".

Câu hỏi khá rộng mở, nhưng đây là một vài ý tưởng.

1. Đánh giá ngang hàng (bởi nhà phát triển cơ sở)

   Cách tốt nhất để ai đó học cách "đúng" là thấy người khác làm điều đó. Có phải tất cả các nhà phát triển của bạn thực hiện đánh giá mã? Nó có thể không phải là một ý tưởng tồi để cho nhà phát triển cơ sở của bạn thực hiện chúng (mặc dù bạn cũng nên yêu cầu ít nhất một đánh giá từ một nhà phát triển cao cấp quá). Bằng cách đó, anh ta sẽ thấy các lập trình viên giỏi trong hành động, cộng với anh ta sẽ quan sát rằng có những nhận xét đánh giá nhắm vào các kỹ sư khác ngoài anh ta, có nghĩa là nó không phải là cá nhân.

2. Phản hồi sớm / Đánh giá nhiệm vụ

   Cho phép nhà phát triển tham gia vào phân tích nhiệm vụ của riêng mình. Yêu cầu anh ta ghi lại thiết kế dự định của mình trong ghi chú nhiệm vụ và gửi "đánh giá mã" không có thay đổi và chỉ có nhiệm vụ. Bằng cách đó bạn có thể xem lại kế hoạch của anh ấy trước khi anh ấy viết một dòng mã. Khi nhiệm vụ của anh ta đã được xem xét, anh ta có thể bắt đầu viết mã (sau đó anh ta sẽ gửi một đánh giá mã khác). Điều này tránh được tình trạng mất tinh thần nơi nhà phát triển đã viết một loạt các công cụ và bạn phải bảo anh ta viết lại nó.

Nếu mã vi phạm một cách khách quan một tiêu chuẩn rõ ràng bằng văn bản, thì tôi nghĩ bạn chỉ nên tiếp tục đẩy lùi cho đến khi mọi vấn đề được khắc phục. Chắc chắn, nó có thể hơi khó chịu cho nhà phát triển trong vài lần cam kết đầu tiên, nhưng họ cũng có thể tìm hiểu các hướng dẫn sớm hơn so với sau này.

Ngoài ra, nếu bạn cho phép một vài vi phạm tiêu chuẩn ở đây và ở đó thì họ sẽ thiết lập một tiền lệ xấu - xem lý thuyết cửa sổ bị hỏng . Ngoài ra, việc nhớ theo các tiêu chuẩn sẽ dễ dàng hơn rất nhiều nếu nó đã được áp dụng nhất quán cho cơ sở mã. Vì vậy, thực sự, tất cả mọi người chiến thắng, bao gồm cả các nhà phát triển cơ sở trong câu hỏi.

Tôi không nghĩ rằng tinh thần là một vấn đề lớn miễn là tiêu chuẩn mã hóa được viết ra. Chỉ khi nó trở nên chủ quan hơn "tốt, tôi sẽ làm nó khác đi" - thì bạn nên quan tâm, vì cách tiếp cận của các nhà phát triển có thể hợp lệ.

Xem xét áp dụng quy trình đánh giá mã, trong đó các nhà phát triển đăng các cam kết được đề xuất của họ lên một công cụ như Github Pull Requests hoặc Photypeator Diffusion và nhận đăng nhập ngang hàng trước khi đưa các thay đổi của họ lên nhánh chính được chia sẻ.

Bằng cách này, thay vì chỉ trích hồi tố hoặc yêu cầu ai đó làm lại những gì đã làm, công việc vẫn chưa được thực hiện cho đến khi nó vượt qua đánh giá ngang hàng. Việc qua lại với các đồng nghiệp cũng là một phần của quy trình công nghệ phần mềm cũng như qua lại với trình biên dịch.

Bạn có thể gửi mối quan tâm của bạn dưới dạng nhận xét về các dòng cụ thể và có các cuộc thảo luận theo chuỗi về chúng. Anh ta có thể làm tương tự với mã của bạn. Cuộc thảo luận tập trung vào các thay đổi mã được đề xuất cụ thể và không nói chung về hiệu suất hoặc năng lực của ai đó.

Ngay cả các kỹ sư cao cấp xuất sắc tại công ty của tôi cũng biết ơn khi đánh giá mã bắt lỗi chính tả hoặc buộc họ làm cho mọi thứ rõ ràng hơn. Đó là điều hoàn toàn bình thường đối với những nhân viên mới yêu cầu nhiều vòng lặp hơn. Theo thời gian, bạn bắt đầu sửa chữa theo phản xạ các loại vấn đề bạn biết sẽ thu hút bình luận trước khi đăng một khác biệt. Có được tỷ lệ phần trăm chênh lệch cao hơn được chấp nhận trong lần thử đầu tiên là cách bạn biết mình đang tiến bộ.

Tôi không liên tục đẩy lùi mã về những gì cho người mới có thể giống như những chi tiết nhỏ, điều này có thể khá bực bội, nhưng tôi cũng lo lắng rằng việc quá 'mềm' có thể ngăn anh chàng học cách làm một số thứ.

Đây là cả những khả năng thực sự và mối quan tâm hợp lệ. Hỏi nhà phát triển họ cảm thấy thế nào về nó.

Giả sử rằng bạn có một số yêu cầu kéo hoặc quy trình xem xét mã, và có vẻ như bạn làm như vậy, tôi sẽ khuyên bạn nên lưu ý những thứ "không văn bản" hoặc "ưa thích".

Nếu bạn thấy PR ở trạng thái tương tự như những gì bạn đang mô tả, với một số vấn đề về phong cách nhỏ hoặc cần tái cấu trúc không văn bản, hãy để lại nhận xét, nhưng cũng cảm thấy thoải mái khi phê duyệt. Nói điều gì đó như: "Trong tương lai, có thể cố gắng tránh các tên phương thức như thế này để ủng hộ một cái gì đó như descriptiveMethodName" ghi lại ý kiến ​​của bạn mà không buộc chúng phải thay đổi hoặc ngăn chặn sự phát triển của chúng.

Bây giờ họ biết sở thích của bạn và nếu họ đang cố gắng cải thiện, hy vọng sẽ nhận thấy tình huống như vậy trong tương lai. Nó cũng để cánh cửa mở cho họ thực sự thay đổi nó vào thời điểm đó, nếu họ đồng ý với bạn và xem nó là đủ quan trọng.

Tôi đang làm việc với một nhà phát triển cơ sở, những người làm việc từ xa từ một nhà máy mã hóa.

Thật không may, đó không phải là một tình huống lý tưởng: một lập trình viên tiên tiến phụ trách một lập trình viên mới làm quen, với sự tách biệt về địa lý. Không có gì đáng ngạc nhiên khi có một số căng thẳng, nhưng sự chênh lệch có thể được giảm nhẹ.

Tôi tò mò, ý của bạn là "nhà máy mã hóa" là gì? Thuật ngữ đó, với tôi, chỉ ra một thái độ rắc rối có thể làm trầm trọng thêm một số vấn đề quản lý mà bạn đã đề cập.

Vi phạm SRP, các đối tượng của Chúa, các tên không có ý nghĩa đối với các phương thức hoặc biến; Tôi chỉ ra những gì anh ấy phải sửa chữa và cố gắng giải thích tại sao nó sai.

Vấn đề, tôi nghĩ, là nhà phát triển cơ sở của bạn đang phun mã mà không trải qua một quy trình thiết kế phù hợp. Đây là một thất bại về phía bạn, với tư cách là người quản lý và nhà phát triển cao cấp, để cung cấp hướng dẫn và dạy thói quen phát triển phần mềm tốt. Bạn có thể ngăn chặn mã xấu được viết ở vị trí đầu tiên nếu bạn lần đầu tiên làm việc cùng nhau để phác thảo một phác thảo. Điều đó sẽ tốt hơn để chỉ trích và viết lại mã sau khi nó đã được sản xuất, về cả hiệu quả và tinh thần.

Có lẽ bạn sẽ cần điều chỉnh lại quy trình làm việc của mình. Có vẻ như bạn hiện đang mong đợi anh ấy giao sản phẩm cho bạn. Những gì bạn cần là sự hợp tác chặt chẽ hơn, để bạn có thể cung cấp hướng dẫn ở mọi bước phát triển. Nói về thiết kế và giao diện trước khi bắt đầu mã hóa. Trong khi mã hóa đang xảy ra, hãy làm các trạm kiểm soát thường xuyên hơn, để nắm bắt các vấn đề sớm hơn. Nếu có thể, hãy thử lập trình cặp, thông qua chia sẻ màn hình với một kênh âm thanh.

Tất cả điều này sẽ đòi hỏi nhiều nỗ lực hơn từ phía bạn, nhưng có lẽ sẽ đáng giá, khi xem xét mối quan hệ có vấn đề mà bạn hiện đang có.

Nếu đó là vi phạm tiêu chuẩn mã hóa, hãy cho anh ấy / cô ấy biết nơi đó để anh ấy / cô ấy biết. Nếu bạn phải tiếp tục cho anh ấy / cô ấy biết lỗi tương tự thì bạn có thể gặp vấn đề với ai đó không thể tuân thủ các quy tắc hoặc từ chối. Đừng sử dụng thời gian rảnh rỗi của bạn để sửa chữa sai lầm. Người này nên sửa lỗi của mình để họ không tái phạm.

Luôn nói với họ những gì họ đã làm đúng và làm thế nào họ có thể cải thiện trong lần tới. Chúng tôi luôn có thể trở nên tốt hơn trong một số lĩnh vực. Phản hồi là rất quan trọng trong việc trở nên tốt hơn ở bất cứ điều gì.

Một ý tưởng khác để đối phó với "quá nhiều chỉ trích" là thỉnh thoảng tự mình thực hiện một nhiệm vụ và để nhà phát triển cơ sở thực hiện đánh giá mã cho bạn. Điều này có ít nhất hai lợi thế:

• họ có thể học cách mọi thứ nên được thực hiện.
• trong trường hợp khi có nhiều giải pháp tốt hoặc tên biến, tôi chấp nhận đề xuất các cách tiếp cận khác nhau nhưng (gần như?) tốt như nhau. Khi tôi sửa mã của mình vì nhận xét của ai đó, tôi cho mọi người thấy rằng họ được tôn trọng và những lời chỉ trích luôn chỉ liên quan đến mã - bất kể tác giả là ai.