Pull to refresh

Как не дать программисту написать плохой код

Programming
Tutorial
image
Как-то раз в одной неглупой статье один неглупый хабраюзер рассказал одну неглупую идею. Суть её была в том, что в его компании настроена система, контролирующая написанный программистами код в момент попытки добавления его в репозиторий и отклоняющая код, не проходящий по некоторым критериям. Мне идея понравилась. Я (и еще 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. Делаем какую-нибудь дурость, нарушающую правила, пытаемся коммитить и видим что-то типа


Вуаля, работает!

Выводы


С этой штукой объективно лучше, чем без неё. Все, что я написал в начале статьи, действительно может помочь сэкономить время, нервы и получить код немного лучшего качества. Конечно же, описанная здесь система не панацея от всех бед и в коде все равно могут быть:
  • Классы, методы и переменные, названные по правилам именования, но бессмысленно
  • Комментарии с непонятной белибердой
  • Существенные архитектурные глюки
  • Несущественные программные глюки
  • Куча всего другого


Идеал недостижим, но иметь правильно оформленный код, гарантированно отвечающий хоть некоторым требованиям и правилам — это лучше, чем просто надеяться на сознательность разных несознательных личность в столь сознательном деле, как программирование.
Tags:SVNstylecopcSVNStyleCop
Hubs: Programming
Total votes 159: ↑141 and ↓18+123
Views6K

Top of the last 24 hours