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

Use an intelligent code formatter and probably an analysis tool to check if the standards are followed.

Use some sessions to introduce the standards.

Introduce a kind of an award for the programmer with the best compliance for the standard each month.

And if all fails, get rid of them.

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

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

• Обучения
• Коммуникации
• Обзоров

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

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

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

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

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

Каждый разработчик имеет свой собственный стиль программирования, основанный на его опыте работы с различными языками или в различных рабочих средах. Каждый человек развивает свой собственный стиль, основанный на многих факторах. Вы не можете СДЕЛАТЬ, чтобы кто-то следовал строгим правилам кодирования.

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

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

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

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

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

[править] Заменить или обучить управление. Управлению все равно, так зачем им.

Have you tried a wooden ruler across the knuckles? Worked for me in school :P

Seriously though, standards are there to be followed, if they're not being followed and you're in a position to follow through with training and disciplinary action, then follow disciplinary procedures. If you're not, and you can't convince your higher ups that this should be followed then it seems you have two options:

• Suck it up and make the best of it
• Start looking for another job

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

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

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

It sounds like you aren't respected enough.

Do code reviews, and discuss the coding standards with the team. Maybe they don't adhere because they don't agree. Be flexible.

Perhaps if you're doing a project for the third time, it's YOU that's doing things wrong.

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

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

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

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

РЕДАКТИРОВАТЬ: В ответ на ваше «находящееся под давлением» дополнение, руководитель проекта должен сделать все возможное, чтобы поглотить как можно большую часть этого давления. Лучшие менеджеры знают, на что способна их команда, и знают, как это сказать руководству. Вы должны быть связующим звеном между командой и руководством, и если руководство спешит, вы должны дать им понять, что качество пострадает. Если люди с деньгами не заботятся о качестве так же сильно, как о том, как это сделать ... ну, вы не можете быть разборчивы в отношении стандартов. Если им нужно качество, они выслушают уверенного менеджера, который скажет им, что его программисты не могут создать качественное, поддерживаемое приложение без применения стандартов.

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

If you have seniority over them, then do a code review and fail them for not adhering to the coding standard. If it continues you can give them a formal warning. If it then continues you can fire them and get people in that can spend 20 minutes reading a coding standards document once in their lives.

I don't know what IDE you use, but Eclipse lets you set up code formatters that you can distribute around your developers, so this might also be an idea.

However there may be an underlying problem - that the other developers dislike your coding standard. It might be best to first find out if this is the case. If your coding standard is actually not a common standard in your language then they might just be passive aggressive as long as they can get away with it. Maybe you should involve them in the development of a coding standard that they are all happy with, mostly.

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

Technical Solution если вы используете Team System, вы можете использовать правила регистрации для ее применения. Другие системы контроля версий, без сомнения, поддерживают подобные вещи. Для этого вам понадобятся TFS Server Power Tools .

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

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

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

Правила кодирования важны, но будьте осторожны, чтобы:

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

Дополнительно:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Go get more obedient devs.

On a serious note: I can say for myself that I tend to ignore (or reluctant to follow) practices I find downright unreasonable, too authoritarian or plain stupid. Try speaking to your guys and ask them what they don't like about the doc.

Were the developers consulted when the standards were written? I hate having to follow guidelines that someone came up with out of the blue and did not consult some of the devs. It happens all the time.

The other thing that bugs me is someone giving me guide lines to follow that does not actually work on production code. There is a big difference in the theoretical right way to do something and the practical right way to do something.

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

В частности,

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

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

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

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

Ответ состоит как минимум из двух частей:

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

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

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

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

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

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

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

Они ловят и подавляют Throwables

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

return nulls

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

конкатенировать Stringы в больших циклах

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

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

1. Почему это неправильно.
2. Как правильно это делать.

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

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

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

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

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

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

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

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