Пока что это должна быть разумная комбинация всех ответов. В конце концов, когда вы говорите о группе умных людей (разработчиков), вы должны указать им причины важности поведения и дать им достаточный контроль над тем , как это поведение реализовано, чтобы они вкладывались в его правильное выполнение. Мандаты сверху, как правило, бесполезны для умных людей, потому что, если они не согласны с тем, что проблема является проблемой, то они, скорее всего, будут тратить больше времени на работу над мандатом, чем следуя правилу.
Вот несколько моих тактик:
Передача изменений:
Во-первых, команда должна договориться о том, когда совершать и что совершать. Абсолютно важным является настройка сборки, которая имеет смысл, так что люди не сдерживаются только потому, что не знают, куда что-то положить. И согласие о том, когда / как часто регистрироваться. «Не нарушайте сборку» - очевидное хорошее правило, но как это проверяется, и кому об этом говорят? Другой базовый уровень - «это не сделано, если оно не зарегистрировано».
Большинство разработчиков, которых я знаю, более чем рады проверить код IF:
- Процесс регистрации прост
- Процесс синхронизации прост (с учетом изменений от других разработчиков)
- Просматривать изменения и перемещаться между версиями легко
Одна вещь, которую я недавно заметил, состояла в том, что проверки стали более частыми и менее болезненными, когда мы перешли к новому инструменту CM. Наша команда является пионером Rational Team Concert, ранее использовавшим Clearcase. Я не хочу рекламировать инструменты, но новая (для меня) волна потоковых чеков с множеством небольших быстрых слияний делает этот процесс более привлекательным для раннего и частого чекинга.
Разрешение разработчикам отвечать за устранение боли CM обычно увеличивает количество проверок в этом случае.
Придерживаясь архитектуры - не записывать проблемы модели в представлениях и контроллерах
Я помещаю это в общую группу «делай архитектуру правильно». Я согласен с тем, кто сказал рецензии - давление со стороны коллег отлично подходит для этого. Один из способов, с помощью которых я обычно вижу, что люди приходят в лидеры за лучшие практики в этой области, - это когда их сверстники спрашивают их, почему они сделали это по-другому (не очень правильный путь). Обычно вопрос «почему» приведет людей к пониманию того, почему они должны были сделать это по-другому. Когда у людей есть хорошо понятная причина для лучшей практики, ее гораздо легче придерживаться.
Кроме того, если есть какая-то формальность, связывающая человека с решением, тогда может быть легче назначить ошибки в этой области ... так что, если человек отвечает за исправление ошибок в области неправильного дизайна, необходимо что-то исправить перед тем, как они могут перейти к чему-то новому и захватывающему, может стать большим мотиватором.
Избегайте жесткого кодирования
Я бы начал с четких стандартов кодирования и включения обзора стандартов кодирования в экспертные обзоры. Жесткое кодирование - это одна из тех вещей, которая может быть легко помечена в повестке дня рецензирования.
Я боюсь, что такого рода вещи - единственное, что, как я видел, стало ролью команды, ведущей в обеспечении соблюдения правила. В командах, которые я запускал, мы, как правило, не позволяем кому-либо двигаться дальше, пока они не исправят комментарии, полученные в результате рецензирования своего кода. И «без жесткого кодирования» является частым комментарием рецензента.
В общем
Почти с любой лучшей практикой, я думаю, вы должны выбрать свои сражения. Ни одна команда не станет абсолютно идеальной. Но вы можете следить за своими основными болевыми точками и начинать решать их в кластерах. Я думаю, что роль лидера состоит в том, чтобы действительно знать, что является болевым пунктом для команды, а не раздражающим причудами конкретного человека.
Если ваша команда упускает возможность выполнить определенную лучшую практику, я думаю, что первый вопрос должен быть «насколько большой ущерб это вызывает?» если ответ «минимальный», то это, вероятно, не стоит времени. Некоторые передовые практики наиболее актуальны для конкретных типов систем - хотя они в целом хороши, они могут не стоить битвы за системы, где практика не является частым явлением или основной частью системы.
Если ответ на "сколько даманжа?" это «ALOT !!!», тогда вы можете начать строить кейс для того, чтобы показать команде, что всю эту боль и страдания можно снять, исправив это одно слабое место в лучших практиках. Большинство людей счастливы избежать боли и страданий, и это меняет диалог с «сделай это, потому что я сказал тебе», на «мы решили сделать это, потому что это лучше».