Як повинен керувати менеджер з розробки коду "Тендер на мету"?

Спочатку дозвольте мені ввести термін:

цільове завдання коду: перевірка коду вранці, а потім мовчки переглядаючи всі зміни, внесені іншими розробниками за попередній день файл за файлом (особливо файли коду, які ви спочатку розробили), і виправлення форматування, логіки, перейменування змінних, рефакторинг довгі методи тощо, а потім внесення змін до СКС.

Ця практика має кілька плюсів і мінусів, які я визначив:

• Про : Якість коду / читабельність / послідовність часто зберігається
• Про : Деякі помилки виправлені через те, що інший розробник не надто знайомий з вихідним кодом.
• Con : Часто є марною витратою часу розробника, який спрямовує цілі.
• Con : Іноді вводяться помилки, що викликає лють волосся на розробників, які думали, що вони написали код без помилок напередодні.
• Кон : Інші розробники загострюються із надмірним занизуванням і починають не любити внесок у код цільового конкурсу.

Відмова: Справедливо кажучи, я насправді не менеджер з розвитку, я розробник, який насправді робить "тенденцію до досягнення мети".

На свій захист, я думаю, що це роблю з поважних причин (щоб у нас надзвичайно велика база коду була добре змащеною машиною), але я дуже стурбований тим, що це також створює негативну атмосферу. Я також певно стурбований тим, що моєму менеджеру потрібно буде вирішити це питання.

Отже, якби ви були менеджером, як би ви вирішили цю проблему?

ОНОВЛЕННЯ: Я не маю на увазі, щоб це було занадто локалізовано, але деякі запитували, тому, можливо, деякий фон буде висвітлюватися. Мені було призначено гігантський проект (200K LoC) три роки тому, і лише нещодавно (1 рік тому) до проекту були додані додаткові розробники, деякі з яких не знайомі з архітектурою, інші, які ще вивчають мову (C #). Я, як правило, повинен відповідати за загальну стабільність продукту, і я особливо нервую, коли зміни напрочуд вносяться до основних архітектурних частин кодової бази. Ця звичка з'явилася тому, що спочатку я був оптимістично настроєний на внески інших розробників, але вони зробили занадто багато помилок, які спричинили серйозні проблеми, які не були б виявлені до тижня, коли палець буде вказаний на мене для написання нестабільного коду. Часто ці "

Це здається, що те, що ви робите, в основному еквівалентне огляду коду, за винятком того, що замість того, щоб надати розробникам зворотній зв'язок, ви вносите всі зміни, які ви б запропонували в огляді коду. Майже напевно вам буде краще зробити фактичний огляд коду, де ви (або хтось інший) надаєте відгуки оригінальному розробнику щодо проблем якості коду та очевидних помилок і попросите оригінального розробника виправити їх. Це підвищує якість коду, але також допомагає розробнику ознайомитись з оригінальним кодом та його підводними каменями та допомагає покращити майбутні зміни коду. Плюс до цього, це не має недоліків викликати "лютість волосся", коли помилка мовчки вводиться або змушує інших розробників думати, що про них говорять за спиною.

Якщо чесно, ІМХО, це жахлива ідея.

Я б очікував, що мораль впаде в жолоб, якщо цього ще не було.

Щоб бути справедливим до вас, ви це визнаєте.

Огляди експертного кодексу чудові, це покладає увагу на розробників на одному рівні, замість того, щоб це був сценарій "їх проти нас". (де їх управління / веде).

Можливо, є деякі розробники, за якими вам може знадобитися стежити за іншими, але ковдра змушує весь код першим пройти через вас смішно.

І незважаючи на те, наскільки добре ви думаєте, що ви є, буде час, коли ви помиляєтесь, або "збирання ніт", і це просто погіршить ситуацію.

Якби я був менеджером, щоб вирішити цю проблему:

• Перегляньте стандарти та практики коду з командою, передайте їм копію стандартів кодування
• Код експертного огляду на регулярній основі для посилення стандартів та практик, яких слід дотримуватися
• Застосовуйте прищеплення / форматування за допомогою інструмента автоматизації, щоб розробники змушені були дотримуватися стандартів
• Позбудьтесь від поганих товаришів по команді, які відмовляються дотримуватися стандартів
• Перестаньте бути воротарем

Ваші наміри хороші, але реалізація є жахливою і, як уже вказували інші, спричинить поганий моральний стан та снайперство серед членів команди.

Якщо проект ніколи не мав ніякого стандарту для початку, спробуйте полегшити новий стандарт поетапно, а не просто перемикати комутатор.

Погане жужу.

Я не менеджер розробок, але якби я не хотів би, щоб хтось із моїх розробників торкнувся коду, який не є частиною дефекту чи призначеної їм функції. Період. Якщо ви бачите проблему з чужим кодом, то будь-яким чином доведіть це до відома відповідальних розробників, але не просто занурюйтесь і виправляйте їх самостійно, особливо якщо ви не поговорили з іншим розробником ( з) першим.

Завдання очищення повинні виконуватися лише після офіційного перегляду коду командою та лише розробниками, яким ці завдання були призначені.

Ініціатива в цілому хороша, але іноді може вкусити тебе в дупу. Якщо вводити будь - які помилки в те , що був робочий код, ви швидко можете бажати ви вибрали інший шлях кар'єри.