Правильный подход к разработке личного проекта и его публикации на GitHub

Перевод статьи «The Right Way to Develop your Side Project on GitHub».

IT-сфера развивается очень быстро, и если вы хотите не отставать, вам придется постоянно изучать новые технологии и подходы. Самый лучший способ это делать — создавать собственные проекты. В этой статье мы поговорим о том, как создавать личные проекты правильно.

Почему именно на GitHub? GitHub это фактический стандарт для open-source-проектов. Там вы можете поделиться своим кодом с другими пользователями и найти единомышленников, которые захотят принять участие в вашем проекте. Кроме того, GitHub обладает определенным функционалом, способным существенно помочь разработчикам: Pull Request, Actions, Packages.

Найдите подходящую идею

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

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

Выберите технологический стек

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

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

Для проекта-однодневки можно остановиться на любой технологии. Если она вам не подойдет, вы можете в любое время поменять стек и полностью переписать проект на чем-то более подходящем.

Создайте файлы с README и лицензией

Окей, вы нашли подходящую идею и выбрали любимый стек технологий. Давайте настроим на GitHub новый репозиторий для вашего приложения. Пора поговорить о двух главных файлах в этом репозитории: README и LICENSE.

В вашем проекте с открытым кодом обязательно должен быть файл README, в котором будет содержаться справочная информация о вашем приложении. Что именно там должно быть?

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

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

Также будет удобно завести себе файл .gitignore, чтобы случайно не закоммитить в репозиторий ненужные файлы.

Photo by Pakata Goh on Unsplash

Создайте приложение Hello World и настройте GitHub Actions

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

Для существующего приложения Hello World будет проще создать GitHub Actions.

Что такое GitHub Actions? Это один из инструментов непрерывной интеграции, для автоматической сборки вашего приложения после отправки коммита или пул-реквеста и проверки устойчивости вашего кода путем запуска специального скрипта. Этот скрипт производит ряд проверок, и если какая-нибудь из них будет провалена, GitHub Actions проинформирует вас об этом. В случае с пул-реквестом при провале хоть одной проверки вы не сможете смержить его в репозиторий.

Как настроить GitHub Actions? Я уверен, что вы сможете справиться с этим самостоятельно. Поищите инструкцию в гугле и изучите ее, потому что подобные вещи это часть вашей работы;)

Проверка правильности вашего приложения

Что нужно сделать, чтобы верифицировать корректность приложения? Как минимум, две вещи:

  1. Проверить ваш исходный код на синтаксические ошибки.
  2. Запустить юнит-тесты и проверить, делают ли функции приложения то, что должны делать по плану (и нет ли багов при этом).

И еще кое-что. Если чувствуете себя в достаточной мере профессионалом, можете устроить еще пару проверок:

  1. Статический анализ. Проверьте, соблюден ли установленный стиль написания кода, нет ли уязвимостей в безопасности.
  2. Покрытие кода тестами. Проверьте, какая часть кода запускается юнит-тестами. Эта проверка будет провалена, если покрытие не дотягивает до установленного процента. Лучше всего, чтобы тестами было покрыто как минимум 80% кода. То есть, на 100 строк кода юнит-тесты должны запускать как минимум 80.

Автоматизируйте сборку пакета приложения

Написав минимально рабочее приложение, можно перейти к сборке пакета. Какой пакет это должен быть? Для сервисов это будет образ Docker, который вы можете запушить в GitHub Packages. Для CLI и прочих инструментов это будет запускаемый бинарный файл, который вы сможете приложить к GitHub Release assets.

После завершения каждой существенной функции публикуйте новый релиз на GitHub. Настройте еще один GitHub Action, который будет запускаться по тегу release и собирать пакеты приложения.

Постепенно дело дойдет до деплоймента приложения. Если вы используете Docker, напишите скрипт, который будет забирать последний образ Docker на ваш сервер.

Если у вас CLI-приложение, просто выкладывайте его на вашу рабочую станцию. Основная идея здесь — как можно раньше начать использовать свое приложение. После каждого релиза делайте деплоймент приложения и используйте последнюю версию: это позволит вам ускорить разработку и вылавливание багов.

Управление задачами в вашем проекте

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

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

Допустим, у вас уже есть набросок вашей программы и вы знаете, какого рода задачи у вас будут. Определите, какие функции приложения — самые важные. Они же будут обязательными частями вашей схемы. Разбейте эти части схемы на маленькие задачи, чтобы работа над каждой отнимала не больше часа.

Запишите где-нибудь все эти задачи и оцените их важность, а затем рассортируйте в порядке приоритетности. Поместите задачи в файл README или в ваш любимый to-do-список. Можно для каждой задачи создать issue на GitHub.

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

Пора браться за дело!

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

  1. Возьмите задачу с наивысшим приоритетом.
  2. Создайте для этой задачи ветку в git.
  3. Реализуйте решение задачи.
  4. Напишите несколько юнит-тестов (если не практикуете разработку через тестирование).
  5. Сделайте пуш этой ветки на GitHub.
  6. Откройте пул-реквест на GitHub.
  7. Подождите, пока GitHub Action соберет ваш коммит. Если сборка не удастся, вам придется исправить свой код и затем собрать его снова.
  8. Если сборка прошла нормально и все «позеленело», можно сделать merge этого пул-реквеста.
  9. Опубликуйте релиз, подождите, пока GitHub Action соберет пакеты приложения.
  10. Выполните деплоймент приложения.

После каждой реализованной задачи у вас должно оставаться развернутое где-нибудь корректно работающее приложение.

Заключение

Давайте еще раз пробежимся по самым полезным советам:

  1. Найдите интересную для вас идею приложения.
  2. Напишите подробный файл README, в котором будет описание проекта, гайд по установке и руководство пользователя.
  3. Выберите лицензию для своего открытого кода и создайте соответствующий файл.
  4. Напишите минимально рабочее приложение и настройте для него среду разработки.
  5. Используйте GitHub Actions для автоматизации сборки.
  6. Спроектируйте архитектуру приложения и нарисуйте ее схему.
  7. Составьте план задач, расставьте их в порядке приоритетности.
  8. Делайте деплоймент приложения после каждой реализованной задачи.
  9. Пользуйтесь своим приложением сами.

Вот и все! Не останавливайтесь и непрерывно улучшайте свое приложение!

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх