Как обеспечить соблюдение стандартов кодирования

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

Вы говорите, что

контрольный список[...]/флажки [не] идеальны

потому что

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

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

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

Рассмотрим следующие три диалога.

1. «Посмотрите в обе стороны, прежде чем переходить улицу». "Почему?" «Я не знаю, это просто то, что мне сказали ».
2. «Посмотрите в обе стороны, прежде чем переходить улицу». "Почему?" «Потому что это закон ».
3. «Посмотрите в обе стороны, прежде чем переходить улицу». "Почему?" «Потому что, если вы этого не сделаете, более вероятно, что вас собьет машина, что приведет либо к кровавой смерти, либо, возможно, к серьезным травмам, таким как травма позвоночника, из-за которой вы больше никогда не сможете ходить».

Теперь рассмотрим следующие три диалога:

1. «Никогда не объединяйте строки в SQL». "Почему?" «Я не знаю, это просто то, что мне сказал администратор баз данных ».
2. «Никогда не объединяйте строки в SQL». "Почему?" «Потому что это в контрольном списке ».
3. «Никогда не объединяйте строки в SQL». "Почему?" «Потому что, если вы соедините строку, содержащую пользовательский ввод, с вашим SQL вместо того, чтобы правильно его параметризовать, вы откроете себя для атаки SQL-инъекцией, которая может дать хакерам гораздо больше доступа к нашей базе данных, чем мы хотим им дать».
   • (Конечно, с последующим «Разве это не означает, что можно конкатенировать константные строки в SQL?» «Вы правы. Давайте обновим стандарт».)

Видите ли вы в них сходства и различия?

По моему опыту, самые эффективные стандарты кодирования — это те, которые диктуются непосредственно разработчиками.

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

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

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

• Линт (программное обеспечение)
• Список инструментов для статического анализа кода

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

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

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

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

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

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

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

В последнем спринте были некоторые стандарты, которые были пропущены разработчиком, а также пропущены рецензентом.

Почему пропустили? Было ли это связано с нехваткой времени или отсутствием намерения?

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

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

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

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

Технические проблемы и проблемы, особенно связанные с SQL, уже обсуждались в этой теме и являются действительными. Но и сама команда должна их в полной мере знать. «Выразите обеспокоенность тем, что «вы обеспокоены»», затем выслушайте , что произойдет дальше, и используйте это, чтобы проинформировать о своем следующем шаге. Если хотите, снова поднимите свои выводы в этом сообществе для получения дополнительной обратной связи. (Цель состоит не в том , чтобы взвесить их ответ по его техническим «достоинствам», а в том, чтобы дополнительно рассмотреть, как им управлять.)

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

Некоторые команды выделяют функцию приемки качества в отдельную команду.

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

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

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