Введение

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

Добро

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

Простой пример пользовательского сценария, который я планирую написать для работы с Django, — это поиск любого URL-адреса в любых html-файлах, добавленных git. Любые локальные ссылки или активы, использующие прямые ссылки, должны быть пойманы на крючок. Это плохая практика, которая впоследствии может привести к головной боли, если статическая директория изменит имя или изменится URL-адрес страницы. Я сталкивался с этим в прошлом, когда хотел сделать URL-адреса веб-сайта более удобными и единообразными. В старых шаблонах везде были прямые ссылки на страницы, поэтому мне приходилось исправлять их вручную. Я назвал каждый URL-адрес и вместо этого использовал тег URL-адреса Django. Таким образом, если мы решим изменить URL-адрес одной из наших страниц, мы можем просто изменить одну строку в файле urls.py. После этого каждая ссылка на эту страницу будет генерироваться на лету с помощью тега. Я также хотел бы добавить еще одну проверку, которая просматривает все имена файлов, которые не заканчиваются на « ThirdParty.html », и вообще не допускает никаких прямых ссылок. Остальное можно хранить в процессоре контекста, чтобы было одно место для всех внешних ссылок, не принадлежащих стороннему коду.

Плохо

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

Уродливый

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

Приведенный выше хук можно разбить на несколько разделов:

  1. Проверьте наличие дубликатов файлов миграции на юг. Это используется, чтобы избежать слияния ветвей в мастер с тем же номером миграции, что и у существующей миграции. Это затруднит откат кода и может случиться с длинными ветками.
  2. Запустите файлы python через flake8 для проверки стиля и простых проверок (т. е. ненужного импорта), а также для проверки операторов печати и отладки.
  3. Запускайте файлы coffee script и javascript через линтеры jshint и coffee-jshint.
  4. Запускайте JSON-файлы через jsonlint, подходит для node, grunt и bower.

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

Вещи, которые я хотел бы сделать:

  • Используйте кешированную версию добавленных файлов, которые может выводить git diff. Вместо этого я передал бы их в линтеры, чтобы я мог анализировать только копии, подготовленные для фиксации, а не локальную копию в папке.
  • Работайте с файлом jshintrc, чтобы js linter не использовал настройки по умолчанию, а выполнял только те проверки, которые я хочу.
  • линтинг CSS/LESS; Я не уверен, что это имеет огромное значение, но есть несколько вещей, которые я мог бы добавить в пользовательские сценарии для проверки.
  • URL-адреса и прямые ссылки в html-файлах проектов Django.