Как должен обрабатывать код «Тенденция к цели» менеджер по развитию?

Сначала позвольте мне обозначить термин:

стремление к коду: проверяйте код утром, затем молча просматривайте все изменения, сделанные другими разработчиками за предыдущий день, файл за файлом (особенно файлы кода, которые вы изначально разработали), а также исправляйте форматирование, логику, переименование переменных, рефакторинг длинные методы и т. д., а затем фиксация изменений в VCS.

У этой практики есть несколько плюсов и минусов, которые я определил:

• Pro : Качество кода / читаемость / согласованность часто поддерживается
• Pro : Некоторые ошибки исправлены из-за того, что другой разработчик не слишком знаком с исходным кодом.
• Против : Часто это пустая трата времени разработчика, стремящегося к цели.
• Con : Время от времени появляются ошибки, которые вызывают невероятную ярость у разработчиков, которые думали, что они написали код без ошибок днем ​​ранее.
• Против : Другие разработчики раздражаются от чрезмерного придирки и начинают не любить вносить свой вклад в код цели.

Отказ от ответственности: честно говоря, я на самом деле не менеджер по развитию, я разработчик, который на самом деле занимается "стремлением к цели".

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

Итак, если бы вы были менеджером, как бы вы решили эту проблему?

ОБНОВЛЕНИЕ: я не хочу, чтобы это было слишком локализовано, но некоторые спрашивают, так что, возможно, какой-то фон будет освещать. Три года назад мне был назначен гигантский проект (200K LoC), и только недавно (1 год назад) в проект были добавлены дополнительные разработчики, некоторые из которых незнакомы с архитектурой, другие еще изучают язык (C #). Обычно мне приходится отвечать за общую стабильность продукта, и я особенно нервничаю, когда неожиданно вносятся изменения в основные архитектурные части базы кода. Эта привычка возникла, потому что сначала я с оптимизмом смотрел на вклад других разработчиков, но они допустили слишком много ошибок, которые вызвали серьезные проблемы, которые не будут обнаружены до нескольких недель спустя, когда мне будут указывать пальцем на написание нестабильного кода. Часто эти

Похоже, то, что вы делаете, в основном эквивалентно проверке кода, за исключением того, что вместо того, чтобы предоставлять обратную связь разработчику, вы вносите все изменения, которые вы предлагаете при проверке кода. Вам почти наверняка было бы лучше сделать реальный обзор кода, где вы (или кто-то еще) предоставите исходному разработчику информацию о проблемах качества кода и очевидных ошибках и попросите первоначального разработчика исправить их. Это повышает качество кода, но также помогает разработчику лучше ознакомиться с исходным кодом и его подводными камнями и помогает улучшить будущие изменения кода. Кроме того, у него нет недостатка в том, чтобы вызывать «гневную волну», когда ошибка появляется незаметно или заставляет других разработчиков думать, что о них говорят за спиной.

Честно говоря, ИМХО, это ужасная идея.

Я бы ожидал, что боевой дух упадет в канаву, если он еще этого не сделал.

Чтобы быть справедливым по отношению к вам, вы признаете это.

Рецензирование кода на уровне сверстников - это хорошо, оно ложится бременем на всех разработчиков на одном уровне, а не на сценарий «они против нас». (где их управление / ведет).

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

И, несмотря на то, насколько вы хороши, вы будете думать, что вы не правы, или «гнида», и это только усугубит ситуацию.

Если бы я был менеджером, чтобы решить эту проблему:

• Просмотрите стандарты кода и практики с командой, передайте им копию стандартов кодирования
• Кодекс рецензирования на регулярной основе для усиления стандартов и практики, которым необходимо следовать
• Принудительный выбор / форматирование с помощью инструмента автоматизации, чтобы разработчики были вынуждены следовать стандартам
• Избавьтесь от любых плохих товарищей по команде, которые отказываются следовать стандартам
• Перестань быть вратарем

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

Если у проекта никогда не было стандарта для начала, попробуйте постепенно перейти к новому стандарту, а не просто щелкнуть переключателем.

Плохой юджу

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

Задачи очистки должны выполняться только после формальной проверки кода группой и только разработчиком (-ями), которым были назначены эти задачи.

Инициатива хороша в целом, но иногда она может укусить тебя в задницу. Если вводить какие - либо ошибки в то , что был рабочий код, вы быстро можете желать вы выбрали другой путь карьеры.