Внедрение и внедрение стандартов кодирования

Question

Моя команда (из которой я являюсь самым новым и самым младшим членом) увеличилась в размерах с 3 до 9 разработчиков всего за 1 год. Наш основной продукт усложнился, и мы собираемся провести годовой перенос / переписывание в Silverlight. В прошлом не было никакого определенного стиля / стандарта.

Я предложил своему боссу, что сейчас самое время для внедрения таких стандартов. Я передал ему документ IDesign , и ему понравилась идея. У него 2 проблемы.

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

2. Каков наилучший способ обеспечить это. Это не вопрос попытки диктовать; дело в том, чтобы люди привыкли к разработке по определенному стандарту. В команде есть как минимум 2 человека, которые уже несколько лет развиваются до нынешнего нестандартного уровня. Чтобы решить эту проблему, я хотел бы посмотреть, есть ли инструмент, который можно настроить для обеспечения соблюдения этих стандартов, или как минимум предупредить о «нарушениях» стандарта во время компиляции или во время разработки. Я нашел Microsoft StyleCop, но из того, что я смог определить, он не настраивается и настроен в соответствии со стандартом Microsoft, который не полностью совпадает с IDesign.

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

Answer 1

Сочетание ReSharper, FxCop / StyleCop (есть способ определить пользовательские правила, по крайней мере, для FxCop), четкие руководящие принципы кода и ежемесячные обзоры должны сделать работу для команды из девяти человек, я думаю. Если кто-то нарушит правила, у вас не будет другого выхода, кроме как использовать кнут:)

Answer 2

Регулярные проверки кода были бы хорошим способом ...

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

Хорошо бы использовать инструмент вместе с обзорами кода.

Answer 3

Заметки из моего опыта получения поддержки стандартов кодирования в моей нынешней компании (небольшой по размеру разработчик нескольких проектов, каждый с 1-6 программистами на штуку; мы в основном C ++, но я думаю, что ответы все еще будут применяться):

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

Разделите ваши отзывы . Некоторые коммиты требуют официальных отзывов, некоторые нет. Мы используем несколько типов:

• Обзоры Mini-Design-Doc , где короткие комментарии (обычно одна или две страницы в вики) комментируются группой до начала реализации. Отлично подходит для раннего "изобретения колеса".
• Руководствуясь теплые рецензии , где один или несколько пиров сидят с оригинальным автором перед коммитом (отлично подходит для распространения опыта, ускорения сотрудничества / стажеров). Автор оригинала обычно обнаруживает больше проблем, чем рецензенты. =) * * 1 018
• Официальная пост-фиксация холодные обзоры , где кто-то без руководства (кроме комментариев о регистрации и любой документации) просматривает код. Это имеет тенденцию выявлять проблемы логики или обработки ошибок, а также граничные ошибки.

Автоматизируйте и нажмите, не тяните полезная информация. Мы рассылаем отчеты с нашего сервера сборки - он обычно создается один раз за коммит (в зависимости от того, насколько он занят). Эти отчеты могут включать, например, различия между текущим Gimpel PC-Lint и последним. Это решает проблему «слишком много информации»: вы получаете только предупреждения / ошибки , за которые вы , возможно, несете ответственность, вместе с описанием. Когда информация сужается и становится понятной, люди используют ее в качестве учебного пособия.

Я не могу подчеркнуть это немного: не парься по мелочам . (См. Пункт № 0 изумительной книги по стандартам C ++.)

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

Наконец, поощряют участие и изменяют ваш стандарт кодирования с течением времени. (Это то, где вики может быть полезна.) Если у кого-то есть веская причина не следовать какой-то части стандарта (либо у него есть что-то лучшее, либо слишком много PITA, чтобы следовать), слушайте и отвечайте. Если люди действительно активно вносят вклад и понимают стандарт, а не просто получают его, вы получите гораздо лучший ответ.

Answer 4

Трудно переоценить важность стандартов кодирования. Ключ в том, что у вас должна быть согласованная кодовая база, которую каждый может быстро прочитать и понять. Менее важно, какой набор стандартов вы выберете (при условии, что все подпишутся), но если вы выберете широко используемый стандарт, то меньше разработчиков придется менять свой стиль. Рекомендации по проектированию Microsoft для разработчиков библиотек классов мои любимые (и очень ReSharper дружественные).

Мой коллега ( Говард ван Ройен ) и его команда разработчиков открытого кода разрабатывают превосходный StyleCop для ReSharper , который показывает вам нарушения стиля в реальном времени, выделяя их как Вы печатаете! Был недавний выпуск , который настоятельно рекомендуется.

Answer 5

StyleCop был бы большой помощью.

Answer 6

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

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

Кроме того, вы обеспечили должное участие команды?

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

public bool compare (Object other){
  if(other == null) throw new NullPointerException("You twit, don't give me a null pointer");
  if(!(other instanceof CustomerObject)) throw new UnsupportedArgumentException("Give me the right argument, dammit");
  ...

Поскольку такие вещи теперь занимают три строки и поэтому не пишутся (или, если это так, не дают программисту понять, что делает метод).

Answer 7

Я только что написал блог о совместном использовании ReSharper и StyleCop и применении его через Continuous Integration (используя NAnt).

http://www.robertbeal.com/archives/47

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

Мне однажды отправили это в ответ, Ночные сбой Гитлера: http://www.youtube.com/watch?v=Azl4nqLn4-Y

Answer 8

Спасибо всем за совет. Я хотел бы услышать больше. Так получилось, что когда я смотрел в Resharper в соответствии с рекомендациями Илья Рыженков , мне пришлось заново загрузить стандарт IDesign, который поставляется в виде zip-файла со ссылкой на эту запись в блоге, Хорошей частью является то, что по умолчанию используется стандарт, который я хочу использовать. Это недорого (читайте бесплатно, если вы не жертвуете), и Ihappend, чтобы быть большим поклонником Code-Rush! и Refactor , поэтому я уже загрузил DXCore!

Answer 9

Попробуйте ReSharper, он может отформатировать ваш код в соответствии с вашим стилем. Даже переформатировать все решение сразу.

Answer 10

Используя TFS и VS 2010 с базой c #, мы делаем это так:

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

Мы поддерживаем один набор определений Code Analyses и Style Cop, которые мы запускаем в сборках выпуска с нулевым допуском.

Мы также поддерживаем совместимое определение корня Resharper, которое позволяет разработчикам быстро форматировать свой код в соответствии со стилем, работая с ним. Это облегчает их рабочий процесс, поскольку им больше не нужно ждать предупреждений SA / CA от проверок во время сборки.

Мы разрешаем разработчику переопределять определение корня.

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