Скидки до 28% + 2-ая профессия бесплатно и подарки на 50 000₽

Главная | Все статьи | Код

Как использовать значки GitHub, чтобы не чувствовать себя нубом

Время чтения статьи ~5 минут 41
Как использовать значки GitHub, чтобы не чувствовать себя нубом главное изображение

Это перевод статьи Cameron Barts How to use GitHub badges to stop feeling like a noob.

Cиндром самозванца – это реальная штука, и он поражает новых разработчиков. Мы проходим через туториалы, буткемпы или даже полноценное университетское образование, но всё равно стесняемся делиться своим кодом. Мы боимся плохой оценки качества нашего кода. Никто не страдает от этого сильнее разработчиков с самообразованием. Поскольку у нас нет «фактического» или «задокументированного» опыта или мы не стажировались, мы оцениваем свой код ниже среднего.

Несколько месяцев назад я был таким. Я перечитывал Test-Driven Development With Python Гарри Персиваля. Несмотря на то, что всё делал по книге, я стеснялся делиться своим кодом. Пусть моё приложение и работало так, как было задумано, я не хотел делиться прогрессом. Я не хотел, чтобы кто-то указал мне на какую-то очевидную ошибку, на которую я не обратил внимание. Я хотел, чтобы мой продукт приносил удовольствие другим людям, но не хотел, чтобы они видели, насколько я слабый разработчик.

Я отложил свой проект, и после недолгой паузы стал просматривать другие проекты на GitHub. Я нашёл несколько, у которых был маленький значок на страницах README.

img

Как настоящий чайник, я подумал, что это просто картинка, которую Линус Торвальдс выдаёт на флешке, когда вы заканчиваете школу "Настоящего разработчика". Мне ни разу не приходило в голову щёлкнуть по ней. Я думал, что это статическая картинка, размещённая где-то в репозитории. Позже я наткнулся на проект, который показывал, что билд провалился.

img

Почему кто-то потратил время на то, чтобы добавить изображение, на котором говорится, что их билд не удался? Зачем удалять одну картинку, чтобы заменить её на такую, которая показывает, что ваш проект сломан и демонстрировать это всему миру? Из чистого любопытства я открыл сырой README и увидел такой код:

[![Build Status](https://travis-ci.com/username/projectname.svg?branch=master)](https://travis-ci.com/username/projectname)

В маркдауне я достаточно сообразительно отреагировал на сигнал, что это ссылка с возможностью кликнуть по ней. Поэтому я нажал кнопку, и это привело меня в Travis-CI. Сразу всё стало на свои места. Эту кнопку сам разработчик проекта не обновлял, её обновил Travis-CI. Эта кнопка – динамическая.

Мой первый значок

Как только я узнал о значке билда от Travis-CI, я захотел разместить его в своём проекте. В конце концов, весь мой проект был созданием тестов и тестированием. Так почему бы не обладать чем-то, что будет запускать их автоматически?

Я настроил Travis-CI, чтобы он прогонял юнит-тесты, когда я пушу изменения в GitHub. На самом верху страницы, где Травис-CI их запускает, есть значок. Я щёлкнул по нему и получил маркдаун. Я добавил его в свой README. Перешёл на страницу проекта на GitHub и вуаля! Там появился мой первый значок. Меня зацепило!

Охота

img

Мне понравилось, что значок явно указывал на текущее состояние моего проекта. Я захотел узнать больше, поэтому пошёл охотиться за другими бейджами. Ещё один общий значок, который я нашел, это покрытие кода. Отчёт о покрытии может быть отправлен Travis-CI инструменту CodeCov. Можно получить значок, обозначающий объём покрытия тестами, который непосредственно зависит от того, насколько хорошо протестировано ваше приложение.

img

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

img

Благодаря своему опыту в армейской безопасности, я знаю, что чаще всего уязвимости приносит устаревший софт. Как начинающий разработчик, я знаю, что это также касается софта, от которого зависят ваши приложения. Я услышал о PyUp в подкасте Майкла Кеннеди Talk Python to Me. Когда я зашёл на сайт, я увидел слова, которые мне начали нравиться: «Free For Open Source». Я охотился за новыми бейджами, и мне повезло. Разумеется, они дают значок – безусловно, я добавил его в README.

img

Наконец, я обнаружил, что можно иметь значок стиля. Я раньше баловался с Black. Я нашёл пример стилевого значка, зная, что и он у меня тоже должен быть. Из принципа, я хотел быть уверенным, что мой код всегда соответствует стилю Black. Я узнал о пре-коммите, чем вполне мог воспользоваться для форматирования кода перед коммитом. После того, как я углубился в самые дебри пре-коммита (который ещё и прогоняет код через bandit для безопасности, сортирует мои импорты и требования), я почувствовал уверенность, добавив чёрный значок в свой README.

Результат

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

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

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


Прим. редакции:

Первый проект на Хекслете посвящен в том числе настройке окружения, и в ходе работы вы будете подключать Travis CI и codeclimate, добавляя соответствующие значки в свой репозиторий.

Аватар пользователя Natalia Bass
Natalia Bass 17 сентября 2018
41
Похожие статьи
Рекомендуемые программы
профессия
Верстка на HTML5 и CSS3, Программирование на JavaScript в браузере, разработка клиентских приложений используя React
10 месяцев
с нуля
Старт 26 декабря
профессия
Программирование на Python, Разработка веб-приложений и сервисов используя Django, проектирование и реализация REST API
10 месяцев
с нуля
Старт 26 декабря
профессия
Тестирование веб-приложений, чек-листы и тест-кейсы, этапы тестирования, DevTools, Postman, SQL, Git, HTTP/HTTPS, API
4 месяца
с нуля
Старт 26 декабря
профессия
Программирование на Java, Разработка веб-приложений и микросервисов используя Spring Boot, проектирование REST API
10 месяцев
с нуля
Старт 26 декабря
профессия
новый
Google таблицы, SQL, Python, Superset, Tableau, Pandas, визуализация данных, Anaconda, Jupyter Notebook, A/B-тесты, ROI
9 месяцев
с нуля
Старт 26 декабря
профессия
Программирование на PHP, Разработка веб-приложений и сервисов используя Laravel, проектирование и реализация REST API
10 месяцев
с нуля
Старт 26 декабря
профессия
Программирование на Ruby, Разработка веб-приложений и сервисов используя Rails, проектирование и реализация REST API
5 месяцев
c опытом
Старт 26 декабря
профессия
Программирование на JavaScript в браузере и на сервере (Node.js), разработка бекендов на Fastify и фронтенда на React
16 месяцев
с нуля
Старт 26 декабря
профессия
Программирование на JavaScript, разработка веб-приложений, bff и сервисов используя Fastify, проектирование REST API
10 месяцев
с нуля
Старт 26 декабря
профессия
новый
Git, JavaScript, Playwright, бэкенд-тесты, юнит-тесты, API-тесты, UI-тесты, Github Actions, HTTP/HTTPS, API, Docker, SQL
8 месяцев
c опытом
Старт 26 декабря