Как убедить программистов следовать основным правилам

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

• Фиксация изменений
• Не писать проблемы с моделью в представлении или контроллерах
• Избегайте жесткого кодирования

Можете ли вы рассказать мне о своем опыте? Как тебе это удается?

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

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

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

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

Так что соберите команду и начните работать над общим определением ваших основных правил!

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

Эти рекомендации должны быть изменены, когда команда чувствует, что есть что-то, что следует добавить или уточнить.

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

Это не будет волшебным переключателем, который вы можете включить; это будет медленный процесс и никогда не будет на 100%. В любом случае это был мой опыт.

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

Вот несколько моих тактик:

Передача изменений:

Во-первых, команда должна договориться о том, когда совершать и что совершать. Абсолютно важным является настройка сборки, которая имеет смысл, так что люди не сдерживаются только потому, что не знают, куда что-то положить. И согласие о том, когда / как часто регистрироваться. «Не нарушайте сборку» - очевидное хорошее правило, но как это проверяется, и кому об этом говорят? Другой базовый уровень - «это не сделано, если оно не зарегистрировано».

Большинство разработчиков, которых я знаю, более чем рады проверить код IF:

• Процесс регистрации прост
• Процесс синхронизации прост (с учетом изменений от других разработчиков)
• Просматривать изменения и перемещаться между версиями легко

Одна вещь, которую я недавно заметил, состояла в том, что проверки стали более частыми и менее болезненными, когда мы перешли к новому инструменту CM. Наша команда является пионером Rational Team Concert, ранее использовавшим Clearcase. Я не хочу рекламировать инструменты, но новая (для меня) волна потоковых чеков с множеством небольших быстрых слияний делает этот процесс более привлекательным для раннего и частого чекинга.

Разрешение разработчикам отвечать за устранение боли CM обычно увеличивает количество проверок в этом случае.

Придерживаясь архитектуры - не записывать проблемы модели в представлениях и контроллерах

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

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

Избегайте жесткого кодирования

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

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

В общем

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

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

Если ответ на "сколько даманжа?" это «ALOT !!!», тогда вы можете начать строить кейс для того, чтобы показать команде, что всю эту боль и страдания можно снять, исправив это одно слабое место в лучших практиках. Большинство людей счастливы избежать боли и страданий, и это меняет диалог с «сделай это, потому что я сказал тебе», на «мы решили сделать это, потому что это лучше».

Обзор кода. Принимайте только хорошо написанный код без ошибок.

По крайней мере :

• Сделайте так, чтобы им было легче следовать кодовым линиям (такие инструменты, как resharper, StyleCop). Если это легко, они с большей вероятностью примут.

Кроме того, выберите, что работает на основе вашей организации, разработчиков и вашей роли в команде.

• Пусть они исправляют ошибки и регулярно меняют запрос
• Парная программа с опытным разработчиком
• Кодекс рассматривает конструктивно
• Кодовые прохождения
• Начните обучение, используйте такие книги, как Code Complete и Прагматичный программист.

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

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

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

Есть 3 способа решения этой проблемы:

1. Статический анализ исходного кода для проверки проблем с соглашением о кодировании. Используйте такие инструменты, как cppcheck и GramMatech . В Википедии есть хороший список: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis . Как правило, большинство систем контроля версий имеют зацепки, с помощью которых вы можете проверить такие проблемы непосредственно во время регистрации. Для крюков CVS перейдите по этой ссылке: http://goo.gl/F1gd2 . Несоблюдение означает неудачную регистрацию, а более 3 неудач означают, что разработчик должен объяснить себя команде.

2. Во время процесса кодирования сам флаг выдаёт вопросы разработчику. Использование нестандартных сценариев, интегрированных в выбранную вами среду IDE, является отличным способом сделать это. Проверьте эту ссылку: http://goo.gl/MM6c4

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

Вот мой трехступенчатый план:

1. Уволить программистов
2. Наймите несколько инженеров программного обеспечения
3. ...
4. Прибыль!

: D

На полном серьезе, если они не верят ни в что, кроме написания кода, вам нужна более всесторонняя команда. Программист, где я работал, использовал разные директории на компьютере в качестве своего КМ. Мы боролись с их программистом почти год (так как изменения привели бы к ошибкам при копировании и вставке старого кода). В конце концов мы просто уволили их.

1. Обращайте внимание на них, когда они нарушают основные правила.
2. Дождитесь, пока они выдадут ошибки, которые они просто не могут отследить, или столкнутся с запросом функции, который они просто не могут реализовать из-за своего негибкого кода.
3. Напомните им, что вы сказали ранее.
4. Пусть они на какое-то время утонут в собственном дерьме.
5. Потратьте время на рефакторинг рассматриваемого кода, изолируйте ошибки / обеспечьте инфраструк-тром, чтобы подключить новые функции. Потратьте некоторое время, чтобы объяснить, что вы сделали.

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

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

В конце концов, люди учатся только на ошибках. НИКОГДА не исправляйте проблемы, основанные на чужом упрямстве. Если это действительно жизненно важно для проекта (т.е. к вашей компании будет предъявлен иск, если вы не доставите ее в течение N дней), то сначала снимите их с проекта.

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

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

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

Это немного грубо, но я оставил Code Complete в ванной на несколько месяцев. Не уверен, что это было эффективно, но в то время это казалось хорошей идеей.

Так каковы последствия несоблюдения правил и вознаграждения за соблюдение правил? Если ответ тот же - ничего - удачи в получении тяги. Я предлагаю многоуровневый подход. Сначала соберите их и обсудите, покупают ли они правила. Следующим шагом является включение их в обзоры кода. Вы также можете попробовать морковь и палочки. Что-то вроде любого, кто оставляет файл проверенным на ночь, должен принести пончики на следующее еженедельное собрание. Морковь может быть любой, кто следует правилам в течение целого месяца, получает выходные в Вегасе. Для двоих.

Или уволить худшего преступника, и пусть остальные потеют.

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

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

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

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

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

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

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

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