Как заставить разработчиков следовать стандартам кодирования?

Ответ 1

Автоматизируйте его.

В процесс сборки можно интегрировать StyleCop и FxCop (анализ кода в VS2008).

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

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

StyleCop

http://code.msdn.microsoft.com/sourceanalysis

FxCop:

http://blogs.msdn.com/fxcop/

Ответ 2

Были ли консультации с разработчиками при написании стандартов? Мне не нравится следовать рекомендациям, которые кто-то придумал, и не проконсультировался с некоторыми из разработчиков. Так происходит все время.

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

Ответ 3

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

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

Ответ 4

У вас есть стандарты. У вас есть процесс для них. Если они не последуют, прекратите их и найдите квалифицированных людей, которые могут следовать стандартам.

Более конкретно,

• В начале проекта просмотрите стандарты с командой. Сообщайте, что они должны соблюдаться.
• В конце проекта просмотрите, чтобы убедиться в их соблюдении. Если бы они не были, работать с лицами, ответственными за несоблюдение. Задавайте вопросы о том, почему и т.д.
• Дайте ему второй шанс.
• Если повторяется, завершите личность.

Ответ 5

Похоже, вы недостаточно уважаемы.

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

Возможно, если вы делаете проект в третий раз, это вы делаете неправильно.

Ответ 6

Неужели они некомпетентны, ленивы или невежественны?

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

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

Сотрудники Know-it-all-superstar - это тоже то, что никогда не исчезнет. Есть несколько вещей, которые вы можете сделать, хотя.

Ответ 9

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

Ответ 10

Техническое решение если вы используете Team System, вы можете использовать политики проверки, чтобы обеспечить ее соблюдение. Другие системы управления версиями, без сомнения, поддерживают подобные вещи. Для этого вам понадобится инструменты TFS Server Power.

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

Ответ 11

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

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

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

Ответ 12

Изменить: всего около 10 разработчиков в моей команде. Они закончились под давлением и не тратьте время комментировать и делать код аккуратно поскольку на заполните продукт из нашего управление. Каким будет решение для этого?

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

Ответ 13

Рекомендации по кодированию важны, но будьте осторожны:

• быть слишком педантичным. Легко следовать/легко запомнить правила хороши. Стандартные стандарты для общедоступных (например, для ваших клиентов) хороши. Включение, если внутренняя переменная должна быть вызвана num_of_elements или number_of_elements или nelem слишком много.
• переход от стандартизации к их творчеству. Например, решить, что синглтоны запрещены, слишком много. Быть программистом не более чем отличается от того, чтобы быть художником. Вы должны оставить определенную степень творчества.

Кроме того:

• Сделайте рецензию. Когда разработчик совершает какой-либо код, другой разработчик должен его просмотреть и одобрить, также с точки зрения стандартов кодирования. Если ошибка обнаружена, вы не ставите вину на одного человека, что никогда не бывает хорошим, но вы разделяете вероятность того, что ошибка будет одновременно на двух (желающих или не желающих) разработчиков.
• Если вы менеджер, найдите время, чтобы выполнить этот обзор, даже код с ними. Хороший менеджер является частью команды и разделяет ее задачи и бремя. Если вы просто являетесь менеджером "почты, документов и заказов", вы не получите уважения от своей команды, в частности, если это сделано из энтузиастов, в отличие от бессмысленных типизирующих обезьян. Будьте так же, как вы более опытный член команды, соберите с собой свои руки.

Ответ 14

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

Они улавливают и подавляют Throwable s

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

return null s

Это не так серьезно, как подавление Throwable, но все равно может вызвать проблемы. Покажите им, где их код вызывает NullPointerException. Вы также должны показать им, что вместо null (пустой массив, Null Object и т.д.), И насколько это проще работать с вызывающим кодом.

объединить String в больших циклах

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

Для любой практики, которую вы видите как проблему, вам нужно продемонстрировать две вещи:

• Почему это неправильно.
• Правильный способ сделать это.

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

Ответ 15

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

Я действительно устал переписывать этот ужасный код сам.

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

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

Ответ 16

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

Ответ 17

Автоматизация, вероятно, лучший ответ на проблему, вышеупомянутые решения fxcop или командные системы работают хорошо.

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

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

Ответ 18

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

Объясните им, почему стойки кодирования - это хорошо.

Я использую элемент управления Code Style в Visual Studio, а eclipse применяет стандарты кодирования.

http://joel.fjorden.se/static.php?page=CodeStyleEnforcer

Ответ 19

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

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

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

Ответ 20

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

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

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

Ответ 21

Я бы начал с перефразирования вашего вопроса: "Как я могу убедить разработчиков, что следующие стандарты кодирования улучшат их жизнь?"

В ответе есть как минимум две части:

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

• Простота лучше. Если ваш документ стандартов длинный, он будет немедленно проигнорирован занятым разработчиком. В моем мире лучший документ - это не более одной страницы. Для стандарта кодирования я был бы склонен создать один лист пример кода. При условии, что я успешно сделал бизнес-пример выше, я бы сказал команде: "Сделайте свой код похожим на это, пожалуйста".

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

Если вы допустили ошибку, угрожающую инженерам (например, предложения о прекращении выше), существует очень высокая вероятность того, что вы в конечном итоге будете представлены в Daily WTF.

Если вам удастся добиться успеха в точках 1 и 2, фактическая поддержка проверки стандартов уже хорошо понята. Убедитесь, что в среде IDE (control-shift-F для правильного форматирования и т.д.) Обработаны как можно больше возможностей, автоматические средства проверки и т.д.

Техническая методология - легкая часть. Проблемы людей всегда самые сложные (и самые важные).

Ответ 22

Вы можете попробовать предложить им значки и очки репутации.;)

Ответ 23

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

Ответ 24

Вы пробовали деревянную линейку через суставы? Работал для меня в школе: P

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

• Подсоедините его и сделайте все возможное.
• Начать поиск другого задания.

Ответ 25

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

Используйте некоторые сеансы для введения стандартов.

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

И если все не удается, избавьтесь от них.

Ответ 26

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

Такие проблемы должны быть решены с помощью

• Обучение
• Связь
• Отзывы

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

Ответ 27

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

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

Сделайте их привычкой.

Ответ 28

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

Ответ 29

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

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

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

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

Ответ 30

Рассматривая вопросы, которые вы задали в SO, я бы сказал, что у вас проблемы с принятием решений с вашими разработчиками. Вы не видите кого-то, кто должен сказать старшим разработчикам, как выполнять свою работу.

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

[править] Заменить или обучить руководство. Менеджменту все равно, так зачем им это делать.