Làm thế nào để mã hóa Mục tiêu có xu hướng được xử lý bởi Người quản lý phát triển?

Đầu tiên cho phép tôi kiếm một thuật ngữ:

mã mục tiêu theo xu hướng: Kiểm tra mã vào buổi sáng, sau đó âm thầm xem xét tất cả các thay đổi được thực hiện bởi các nhà phát triển khác tệp ngày hôm trước bằng tệp, (đặc biệt là các tệp mã bạn đã phát triển ban đầu) và sửa định dạng, logic, đổi tên biến, tái cấu trúc phương thức dài, v.v., và sau đó cam kết thay đổi đối với VCS.

Thực tiễn này có xu hướng có một vài ưu và nhược điểm mà tôi đã xác định:

• Pro : Chất lượng mã / khả năng đọc / tính nhất quán thường được duy trì
• Pro : Một số lỗi được sửa do nhà phát triển khác không quá quen thuộc với mã gốc.
• Con : Thường lãng phí thời gian của nhà phát triển chăm sóc mục tiêu.
• Con : Thỉnh thoảng giới thiệu các lỗi gây ra cơn thịnh nộ của các nhà phát triển, những người nghĩ rằng họ đã viết mã không có lỗi vào ngày hôm trước.
• Con : Các nhà phát triển khác trở nên trầm trọng hơn với quá trình nitpicking quá mức và bắt đầu không thích đóng góp cho mã của mục tiêu.

Tuyên bố miễn trừ trách nhiệm: Công bằng mà nói, tôi thực sự không phải là người quản lý phát triển, tôi là nhà phát triển thực sự đang thực hiện "xu hướng mục tiêu".

Để bảo vệ, tôi nghĩ rằng tôi đang làm điều này vì lý do chính đáng (để giữ cho cơ sở mã cực lớn của chúng tôi trở thành một cỗ máy được bôi dầu tốt), nhưng tôi rất lo ngại rằng nó cũng tạo ra một bầu không khí tiêu cực. Tôi cũng chắc chắn lo ngại rằng người quản lý của tôi sẽ cần phải giải quyết vấn đề.

Vì vậy, nếu bạn là người quản lý, bạn sẽ giải quyết vấn đề này như thế nào?

CẬP NHẬT: Tôi không có nghĩa là điều này quá cục bộ, nhưng một số người đã hỏi, vì vậy có lẽ một số nền sẽ được chiếu sáng. Tôi đã được chỉ định một dự án khổng lồ (200K LoC) ba năm trước và chỉ gần đây (1 năm trước) là các nhà phát triển bổ sung được thêm vào dự án, một số trong đó không quen thuộc với kiến ​​trúc, những người khác vẫn đang học ngôn ngữ (C #). Tôi thường phải trả lời cho sự ổn định chung của sản phẩm và tôi đặc biệt lo lắng khi những thay đổi được thực hiện một cách đáng ngạc nhiên đối với các phần kiến ​​trúc cốt lõi của cơ sở mã. Thói quen này xuất hiện bởi vì ban đầu tôi rất lạc quan về những đóng góp của các nhà phát triển khác, nhưng họ đã tạo ra quá nhiều sai lầm gây ra những vấn đề nghiêm trọng không thể phát hiện ra cho đến vài tuần sau đó, nơi ngón tay sẽ chỉ vào tôi vì viết mã không ổn định. Thường là những "

Nghe có vẻ như những gì bạn đang làm về cơ bản tương đương với đánh giá mã ngoại trừ việc cung cấp phản hồi cho nhà phát triển, bạn đang thực hiện tất cả các thay đổi mà bạn sẽ đề xuất trong đánh giá mã. Bạn gần như chắc chắn sẽ tốt hơn khi thực hiện đánh giá mã thực tế nơi bạn (hoặc người khác) cung cấp phản hồi cho nhà phát triển ban đầu về các vấn đề về chất lượng mã và các lỗi rõ ràng và yêu cầu nhà phát triển ban đầu khắc phục chúng. Điều đó giữ cho chất lượng mã tăng lên nhưng nó cũng giúp nhà phát triển làm quen với mã gốc và những cạm bẫy của nó và giúp cải thiện các thay đổi mã trong tương lai. Thêm vào đó, nó không có nhược điểm là gây ra "cơn thịnh nộ kéo tóc" khi một lỗi được âm thầm giới thiệu hoặc khiến các nhà phát triển khác nghĩ rằng họ đang bị nói xấu sau lưng.

Thành thật mà nói, IMHO, đây là một ý tưởng khủng khiếp.

Tôi hy vọng tinh thần sẽ rơi vào máng xối, nếu nó chưa có.

Để công bằng với bạn, bạn thừa nhận điều này.

Đánh giá mã ngang hàng là tốt, nó đặt onus cho các nhà phát triển ở một cấp độ, thay vì đó là một kịch bản "họ so với chúng tôi". (nơi họ là quản lý / khách hàng tiềm năng).

Có thể có một số nhà phát triển mà bạn có thể cần để mắt đến nhiều hơn những nhà phát triển khác, nhưng việc buộc tất cả các mã phải thông qua bạn trước tiên là vô lý.

Và mặc dù bạn nghĩ bạn giỏi đến mức nào, sẽ có lúc bạn sai, hoặc "chọn nit" và điều này sẽ khiến mọi thứ trở nên tồi tệ hơn.

Nếu tôi là người quản lý, để giải quyết vấn đề này:

• Xem xét các tiêu chuẩn và thực hành mã với nhóm, đưa cho họ một bản sao của các tiêu chuẩn mã hóa
• Mã đánh giá ngang hàng trên cơ sở thường xuyên để củng cố các tiêu chuẩn và thực hành cần tuân thủ
• Thực thi nitpicking / định dạng bằng một công cụ tự động hóa để các nhà phát triển buộc phải tuân theo các tiêu chuẩn
• Loại bỏ bất kỳ đồng đội xấu nào từ chối tuân theo các tiêu chuẩn
• Ngừng làm thủ môn

Ý định của bạn là tốt, nhưng việc thực hiện là khủng khiếp và như những người khác đã chỉ ra, sẽ gây ra tinh thần kém và bắn tỉa giữa các thành viên trong nhóm.

Nếu dự án không bao giờ có bất kỳ tiêu chuẩn nào để bắt đầu, hãy cố gắng giảm bớt tiêu chuẩn mới trong các giai đoạn thay vì chỉ lật một công tắc.

Juju xấu.

Tôi không phải là người quản lý phát triển, nhưng nếu là tôi, tôi sẽ không muốn bất kỳ nhà phát triển nào của mình chạm vào mã không phải là một phần của lỗi hoặc tính năng được gán cho họ. Giai đoạn = Stage. Nếu bạn thấy có vấn đề với mã của người khác, thì bằng mọi cách, hãy đưa nó đến sự chú ý của (các) nhà phát triển, nhưng đừng chỉ tự mình sửa và sửa nó, đặc biệt là nếu bạn chưa phối hợp với nhà phát triển khác ( s) đầu tiên.

Các tác vụ dọn dẹp chỉ nên được thực hiện sau khi nhóm đánh giá mã chính thức và chỉ bởi (các) nhà phát triển mà những nhiệm vụ đó được giao.

Sáng kiến ​​là tốt nói chung, nhưng đôi khi nó có thể cắn vào mông bạn. Nếu bạn giới thiệu bất kỳ lỗi vào những gì đã đang làm việc, bạn có thể nhanh chóng được nhu cầu bạn muốn chọn một con đường sự nghiệp khác nhau.