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

Question

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

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

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

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

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

Answer 1

В нашей компании мы используем справочные карты для C #. Справочные карты сделаны в Powerpoint с использованием 2 слайдов. Передний и задний ход (печать 2 страниц). Каждый слайд имеет 3 столбца (настройка газеты). Между каждой колонной делается 1 см белого цвета для достижения складок.

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

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

Answer 2

Не зная, как выглядит ваша настройка управления конфигурацией, я бы сказал, что вам следует сначала поискать инструменты, которые интегрируются с вашей системой управления версиями, которые оценивают код до того, как код будет добавлен в хранилище. Я сделал это с нашей настройкой SVN и видел, что это было сделано и с CVS ... это в определенной степени эффективно, потому что заставляет разработчика отправлять "правильный" код и сохраняет ваш репозиторий в чистоте. Простым примером этого было бы отклонение коммита, если пользователь не указал конкретную информацию в сообщении коммита (т. Е. Ошибка #, задача проекта и т. Д.).

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

Answer 3

Если ваша команда имеет непрерывную сборку (например, с использованием Hudson ), вы можете применить ограничения стиля, отказав от сборки или сделав ее нестабильной, когда кто-то фиксирует изменения, нарушающие правила стиля. У Hudson есть плагин Violations , который можно использовать с такими инструментами, как Checkstyle и StyleCop.