Как-то раз в одной неглупой статье один неглупый хабраюзер рассказал одну неглупую идею. Суть её была в том, что в его компании настроена система, контролирующая написанный программистами код в момент попытки добавления его в репозиторий и отклоняющая код, не проходящий по некоторым критериям. Мне идея понравилась. Я (и еще 3 человека) попросили автора развить мысль и написать статью об этом, но она так и не появилась. И я решил разобраться сам.
Преамбула
В начале я объясню, почему меня так захватила эта идея. При всей простоте она даёт целую кучу плюсов:
- Категоричность требования качества кода
В этом главное отличие от ворнингов и ошибок компялятора, советов коллег, выводов инструментов анализа кода — на них всех можно плюнуть и написать любую чушь. А тут программист просто НЕ МОЖЕТ коммитнуть плохой код. При этом у него нет шансов «смухлевать», нет надежды на «а вдруг никто не заметит», нет злости на начальника, который все-таки заметил и ткнул мордой в монитор. Спорить с роботом — это все равно, что разговаривать с телевизором. - Программисты-лентяи наконец-то прочитают внутренние соглашения компании по кодированию
Кем-то ведь они для чего-то писались когда-то! И одно дело когда было «прочитайте, пожалуйста, и придерживайтесь» и другое когда «а фиг вы работать тут сможете, если не прочитаете и не будете придерживаться» - Добросовестным программистам наконец-то не придется помнить наизусть соглашения по кодированию
Это документ, который непонятно-кто непонятно-когда и непонятно-зачем написал больше на надо знать напамять! Если что-то не так напишешь — тебе об этом будет автоматически сообщено. Круто. - Исчезает часть диалогов старших и младших программистов в стиле «Вася, ну ты дурак, я ж тебе говорил писать тут вот так...»
Не все, конечно, но часть исчезает. Об этом скажет робот. - Исчезают циклы «Вася поставил пробел после запятой ->Петя убрал ->Вася поставил->Петя убрал… Петя и Вася набили друг другу морду»
Меньше конфликтов — здоровее нервы. Обижаться на робота — бессмысленно. - В нужных местах кода появляются комментарии
Просто потому, что можно отказаться принимать в репозиторий класс, интерфейс или метод, перед которым не написан комментарий. - Разгрузка старших программистов
В ряде случаев джуниор-программист получает ответ на вопрос «А как надо написать: так или так?» от автоматической системы, не отвлекая старших товарищей отваркрафтаболее важных дел.
Реализация
Я уж было думал, что придется городить свой велосипед. Ничего подобного. Все уже украдено до нас.
Знакомьтесь: SVNStyleCop
Плюсы: установка за 5 минут, стабильная работа, гибкость настройки.
Минусы: только Windows и только C# (Возможно, есть решения и под другие языки и платформы, но, поскольку Windows и C# это как раз мой вариант, я дальше не копал).
Установка
1. Качаем архив и распаковываем куда-угодно на компьютере, где у Вас установлен SVN-сервер.
2. Правим файл SVNStyleCop.exe.config, прописывая в нем путь к утилите svnlook.exe (она лежит в папке SVN-сервера).
3. Правим файл SVNStyleCop.exe.config, прописывая в нем какие именно файлы будут подвергаться анализу. Я написал просто
<pathPatterns>
<clear />
<add value=".*\.cs$"/>
</pathPatterns>4. Кладем в папку к SVNStyleCop файл SVNSettings.StyleCop, предварительно созданный утилитой StyleCop (программа известная, детально описывать не буду) на основании принятых в компании соглашений по написанию кода. Если у вас таких соглашений нет — никому в этом не признавайтесь.
5. Устанавливаем хук на событие «pre-commit». В SVN-сервере Visual SVN это делается из контекстного меню репозитория, путем вставки в раздел «Pre commit hook» содержимого файла pre-commit.cmd из поставки SVNStyleCop (не забыть прописать в этом файле валидные пути!).
6. Делаем какую-нибудь дурость, нарушающую правила, пытаемся коммитить и видим что-то типа
Вуаля, работает!
Выводы
С этой штукой объективно лучше, чем без неё. Все, что я написал в начале статьи, действительно может помочь сэкономить время, нервы и получить код немного лучшего качества. Конечно же, описанная здесь система не панацея от всех бед и в коде все равно могут быть:
- Классы, методы и переменные, названные по правилам именования, но бессмысленно
- Комментарии с непонятной белибердой
- Существенные архитектурные глюки
- Несущественные программные глюки
- Куча всего другого
Идеал недостижим, но иметь правильно оформленный код, гарантированно отвечающий хоть некоторым требованиям и правилам — это лучше, чем просто надеяться на сознательность разных несознательных личность в столь сознательном деле, как программирование.