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

20

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

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

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

Ллистес Сугра
источник
2
Вы должны спросить на programmers.stackexchange.com. Вы делаете обзоры кода? У вас есть инструмент для проверки кода, такой как Crucible? Я бы порекомендовал сделать тщательный анализ кода и настаивать на том, чтобы все проблемы решались до того, как будет выполнена какая-либо другая работа.
15
Вы можете попытаться оставить голову лошади на их кровати, которая работала в Крестном отце.
Гаурав
4
Я имел большой успех с высоким напряжением. Ваш пробег может варьироваться.
Тим Пост
2
@Tim: свернутая газета более экологична
Стивен А. Лоу
@ Стивен, наверное. Сначала вы изменяете цель газеты, а затем повторяете ее. Я полагаю, что есть искусство запугивания зеленых.
Тим Пост

Ответы:

6

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

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

JeffO
источник
1
+1 за указание на то, что это культурный вопрос, и его нужно решать с точки зрения мотивации.
Алекс Фейнман
Это как культурная проблема компании, на которую ссылается JeffO. но иногда эта культура готовится снизу вверх, когда программисты и разработчики не видят качественный код и не нуждаются в нем. когда они учились в школе информатики, их профессора должны были несколько раз ударить их по бокам головы.
Роберт Бристоу-Джонсон
@ robertbristow-johnson - Хороший вопрос.
Джеффо
14

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

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

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

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

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

Мартин Викман
источник
2
Хотя я согласен, я также не согласен с «Не пытайтесь навязать им это, это будет иметь неприятные последствия». - Когда все это сказано и сделано, согласен ли кто-то с основными правилами или нет, это не имеет значения. Босс устанавливает правила, следуйте им или найдите другую работу. Мы не такие особенные, что отношения работодатель-работник не применяются.
Стивен Эверс
12

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

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

RationalGeek
источник
1
Согласен. Это политический вопрос, а не технический.
И любые стандарты кода должны быть согласованы, по крайней мере, частично группой. Такие инструменты, как StyleCop, очень помогают.
Работа
Мой босс пытается подтолкнуть его «качество кода», но это не сработает, потому что люди не верят в это. иметь власть - не всегда ответ.
IAdapter
@ 0101 Очень верно. Власть помогает подтолкнуть сообщение. Сообщение должно быть обработано так, чтобы оно было принято и сопровождено.
RationalGeek
7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В общем

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

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

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

bethlakshmi
источник
Длинный комментарий, но ваш подход потрясающий. Чтобы заставить людей придерживаться этих рекомендаций, им нужно верить, что это полезно. Мне было бы интересно услышать несколько примеров того, как это сработало для вашей команды.
jmort253
Мой любимый пример - последовательная настройка тестовой среды. Я НЕ ДОЛЖЕН обеспечивать Правильный Путь. У меня был парень, отвечающий за установочный документ. Я сказал: «Это все, что вы можете сделать, чтобы создать механизм установки, обеспечивающий согласованную установку, - каждый имеет право на ошибку при установке». Менее чем через месяц у нас был надежный инструмент и очень короткий документ. И инструмент был установлен как ярлык на каждом рабочем столе. Мне не нужно было принуждение, правильная установка уже была путем наименьшего сопротивления. Теперь наша цель - убрать ярлык, сделав его автоматизированным.
Бетлакшми
6

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

Sorantis
источник
3
Это не решение основной проблемы. Не тратьте время на проверки кода, когда вместо этого можно устранить первопричину.
Мартин Уикман,
Если вы сможете заставить их переделывать вещи снова и снова, их лень заставит их со временем начать соответствовать.
Дэвид Торнли
Согласитесь, люди просто должны нести ответственность и выполнять свою работу без предупреждения. Проверка кода после каждого изменения - это огромная трата времени.
jmort253
5

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

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

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

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

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

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

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

Ллистес Сугра
источник
3
Если ваши активы настолько достойны, может быть, эти проблемы не так важны? Вы должны выбирать свои битвы несколько раз.
JeffO
Мой вопрос касается улучшения того, что у меня есть, это сложнее, но эффективнее, чем поиск и замена
Llistes Sugra
Увольнение людей, которые не будут следовать правилам кодирования, НЕ теряет хорошие активы, это избавление от мертвой древесины.
HLGEM
@HLGEM - Если человек, который не следует правилам, просто оказывается ниндзя кода, который может решить любую проблему в организации. Доктор Хаус не следует правилам, но если бы его уволили из больницы, было бы много вымышленных людей, которые бы умерли. en.wikipedia.org/wiki/Gregory_House
jmort253
4

Есть 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. Следуйте гибким процессам и убедитесь, что проверка кода является частью спринта

Fanatic23
источник
1
+1, у меня есть зацепки для коммита, которые запускают все, что было изменено с помощью шины (и нескольких других строк), а также инструменты, позволяющие убедиться, что я не включаю заголовки без необходимости, а также чтобы убедиться, что отступ - это табуляция, а не пробелы и т. Д.
Тим Сообщение
Технические решения не помогут, если разработчики не обязаны их использовать.
Роберт Харви
2

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

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

: D

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

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

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

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

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

back2dos
источник
Мне это нравится. Отличный рецепт, чтобы заставить кого-то ненавидеть тебя. ;)
Роман Зенька
@Romman Zenka: Возможно, да. Но если выбор между ненавистью и разочарованием, потому что у вас в команде есть НАЭС, я предпочитаю первый вариант;)
back2dos
На данный момент их нужно отложить на заработную плату.
Джефф
Я действительно работал над этим! И они не ненавидят меня. Вывод таков: каждый удобен в своем дерьме. И это делает эту задачу такой сложной.
Llistes Sugra
1

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

Фло
источник
1

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

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

Константин Петрухнов
источник
1
Это отличный способ восполнить недостаток лидерских навыков и способности наставлять менее опытных людей. Если ваши навыки убеждения отстой, просто начните увольнять всех людей, которые не согласны с вами.
jmort253
@ jmort253, если бы у меня был шанс, я бы уволил каждого программиста, который не выполняет контроль версий на регулярной основе. Со слов автора, я понимаю, что ВСЕ программисты очень неопытны и не хотят учиться и совершенствоваться.
Константин Петрухнов
1

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

Питер Тернер
источник
0

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

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

SnoopDougieDoug
источник
Eeep! У вас есть тип VCS с единственной проверкой? Возьми с века, чувак!
Дэвид Торнли
0

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

dukeofgaming
источник
0

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

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


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

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

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

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

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

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

HLGEM
источник