Как я могу побудить своих коллег создавать более качественный код? [закрыто]

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

Мне интересно, есть ли процесс или форум, который может помочь улучшить код для всех? У нас уже есть основные вещи, такие как хорошо документированные стандарты кодирования, тесты, линтинг, код-ревью и т. д.

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

Кто-нибудь пробовал что-то подобное и как получилось? Любые другие предложения? (извините за открытые вопросы)

Проблематично, так как содержит много ошибок или плохо спроектировано/продуманно? Содержат ли билеты достаточно информации и документации?
Вы слышали аргументы защиты? Что они тебе сказали?
@JuhaUntinen - плохо продуманный, слишком сложный материал, который нарушает разделение интересов, DRY и принцип наименьшего удивления. Неподходящие шаблоны проектирования, неточные имена и невнимание к вопросам безопасности. Все это просто базовые вещи, которые не нужно явно запрашивать в билетах.
@Josef Единственный веский защитный аргумент заключался в том, что все нужно делать в условиях ограниченного времени. Однако я не согласен с этим, потому что (а) проблемы с качеством сохраняются, даже если сроки не сжаты, (б) плохие привычки теперь переходят на более молодых членов команды, и (в) в конечном итоге проблемы с ремонтопригодностью обходятся нам всем дороже. время в долгосрочной перспективе.
@manannan Спасибо. Кто тогда устанавливает и следит за соблюдением сроков? И есть ли кто-то, кто защитит от них команду и код? Я бы не стал сбрасывать со счетов их ответ, возможно, вы на самом деле разговариваете об этой проблеме не с теми людьми.
Хороший вопрос @Josef. Лица, принимающие решения, должны знать, что сжатые сроки для команды А могут в конечном итоге вызвать проблемы с ремонтопригодностью для команды Б.

Ответы (2)

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

Вы не говорите, есть ли у вас формальный процесс контроля изменений.

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

Это хорошая идея, с которой я не сталкивался. Это было бы очень полезно, когда кто-то собирается внести изменения, которые нельзя отменить, которые влияют на клиентов и накладывают ограничения на дальнейшее развитие.

У меня нет влияния, чтобы пройти через их головы

Ты руководитель группы, это дает тебе влияние.

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

Проведите встречу с ними с целью повышения качества по всем направлениям.

Опробование новых процессов, вероятно, не сработает, поскольку вы уже внедрили качественные/стандартные процессы кодирования, которые явно не работают достаточно хорошо. Добавление еще одного не улучшит качество, оно просто добавит бремени всем остальным.

Решите эту проблему как команда тимлидов.

Однако один из руководителей другой команды — худший нарушитель (мы тоже пишем код). Его вещи объективно плохи; по крайней мере 5 других людей прокомментировали это. Я всегда чувствую себя более комфортно, используя процесс, когда пытаюсь навязать кому-то консенсус.
Затем обсудите это с руководителями групп, которые производят код достойного качества и работают вместе.
Как я могу побудить своих коллег создавать более качественный код? [закрыто]
СпросиСетьПолитика конфиденциальности1y, 0v