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

12

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

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

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

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

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

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

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

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

Кевин Маккормик
источник
3
Очевидно, ваши разработчики недостаточно накачивают ваши шины. Замените своего вратаря на FxCop или что-то подобное и автоматически применяйте эти стандарты, чтобы они не могли зарегистрироваться.
Джон Рейнор
2
Con: Это не твоя работа. Эти люди должны заниматься своими целями.
Роберт Харви
10
как разработчик, я бы посчитал это невыносимым для другого разработчика, делающего это со всеми внесенными мною изменениями, и если в результате ошибки вводятся / вводятся в результате, это совершенно неприемлемо
Ryathal
4
@Ryathal: Магазин должен обеспечивать соблюдение стандарта кода. Код, как правило, принадлежит всей команде, поэтому, если вы не хотите, чтобы люди меняли его, вы должны сделать это правильно с самого начала.
Роберт Харви
1
@RobertHarvey внедрение стандарта - это одно, а мошеннический разработчик, молча отстаивающий свою точку зрения на «право», - это другое дело, и, похоже, это относится к последнему.
Ryathal

Ответы:

52

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

Джастин Кейв
источник
4
Большой +1. Обзоры кода помогают создать команду, в то время как описанное им «стремление к цели», похоже, может привести к неправильному отношению к людям.
Даг Т.
2
Эта. Реальные обзоры кода были бы намного лучшим путем здесь. Как вы сказали, два больших плюса: разработчик быстрее изучает архитектуру приложения, потому что вы показываете ему проблемы. Во-вторых, вы не будете вносить ошибки, потому что не до конца понимаете, что пишется новый код. Идеальный ответ на этот вопрос.
Майк Челлини
2
Блестящий ответ и спасибо за понимание. Я думаю, что привлечение копии этого вопроса и скромное отношение к моему менеджеру могут убедить его в том, что проверки кода будут полезны для команды и уменьшат потребность в «стремлении к цели».
Кевин Маккормик
1
Согласовано. Не копайтесь в чужом коде, не спрашивая. Таким образом вы можете получить несколько грубых ошибок. Я исправил ошибки, направленные на цели, и они не очень приятные. Если вас беспокоит надежность кода, напишите модульные тесты.
Пол Натан
2
Даже если вы никогда не переходите к «реальным» обзорам кода, просто поговорите с другим человеком - спросите, почему они сделали определенные вещи, и почему они не сделали это [каким-то другим способом], это отличный способ выполнить многие из тех же задач. цели. +1
TehShrike
14

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

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

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

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

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

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

Ozz
источник
Это и менеджер, скорее всего, сделают код хуже.
Энди
5

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

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

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

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

Джон Рейнор
источник
3

Плохой юджу

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

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

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

Джон Боде
источник