Многие программисты лихо управляются с кодом и знают мельчайшие подробности своих проектов. Но некоторым из них (в том числе и мне) недостаёт коммуникативных навыков.
Удивительное дело: программист может потратить час на подгонку внутренних и внешних отступов для одной-единственной кнопки и не найти каких-то 15 минут на файл Readme описания проекта.
Надеюсь, вы уже знаете, что такое файл readme.md и для чего он нужен.На всякий случай попробую объяснить.
Что такое Readme.md?
README (буквально означает «прочти меня») — это первый файл, который нужно читать, получив доступ к проекту на Github или любой Git-хостинговой площадке. Этот файл в первую очередь и предлагается вниманию пользователя, когда он открывает здесь репозиторий того или иного проекта. Такой файл содержит кучу полезной информации, так что его вполне можно рассматривать как справочное руководство по проекту.
Посмотрите, где у нас здесь файл Readme:
Файл Readme.md находится в корневой папке репозитория и автоматически отображается в каталоге проекта на github.
Расширение .md — это сокращение от слова markdown. Это язык разметки для форматирования текста. Его используют (как и язык разметки HTML) для нормального отображения документов.
Вот как выглядит файл разметки на github (здесь использован VSCode, который одновременно показывает нам файлы разметки и в режиме предварительного просмотра):
Здесь можно найти официальный гайд Githubдля формата разметки на тот случай, если вам захочется основательно разобраться в языке разметки.
Зачем тратить время на Readme?
Разъяснения закончены, теперь перейдём к делу. Итак, потратив несколько часов на проект, вы выкладываете его на GitHub в надежде, что кто-нибудь (коллеги, потенциальные работодатели или бывшая) его увидит. Вы правда думаете, что они станут заглядывать в root/src/app/main.js, чтобы оценить вашу прекрасную логику? Серьёзно?
Генерирование документации для ваших компонентов
Кроме readme проекта, для понятной кодовой базы необходимо документирование компонентов, благодаря которому упрощается сопровождение кода и повторное их (компонентов) использование. Для автоматического генерирования документации к компонентам, выкладываемым на bit.dev, можно использовать такие инструменты, как Bit (Github).
Создание краткого описания проекта
Для проекта надо подготовить хорошее описание. При составлении описания можно придерживаться такого плана:
- название (желательно и его изображение тоже. Отредактировать можно на canva.com, если вы не специалист по графическому дизайну);
- описание (с использованием слов и изображений);
- демо (изображения, ссылки на видео, интерактивные демо-ссылки);
- технологии в проекте;
- что-то характерное для проекта (проблемы, с которыми пришлось столкнуться, уникальные составляющие проекта);
- техническое описание проекта (установка, настройка, как помочь проекту).
Некоторые нюансы
Используемый здесь проект будем считать за образец. Ну, просто у него один из красивейших файлов readme, который мне приходилось видеть. Код файла Readme.md можно найти здесь:silent-lad/VueSolitaire
NOW WITH DRAG AND DROP Solitaire implemented by scratch on vue.js. It contains 3 types of solitaire namely spider(which…github.com
Чтобы показать код разметки, используйте значок карандаша:
1. Добавляем картинки
У вас может быть отличная фотографическая память, но интересующимся вашим проектом могут понадобиться фотографии его демо-версии.
Так, в описание нашего образцового проекта «Паук» в readme добавлены такие изображения:
Кроме изображений, вы можете добавить и видео-описание проекта. Вот только Github не разрешает добавлять видео в readme… Что же делать?
Используем gif
2. Элементы оформления
Элементы оформления создадут у читающего readme ощущение уникальности вашего проекта. Нестандартные или активно используемые элементы оформления для репозитория можно раздобыть здесь: https://shields.io
Персонализированные или настраиваемые элементы оформления, такие как количество звёзд в репозитории и процентный индикатор кода, берутся там же.
3. Добавляем интерактивную демо-версию
Если есть возможность, разместите проект на своих ресурсах и установите запускаемую демо-версию. Затем пропишите в README ссылку на демо. Кто знает, сколько людей могут заинтересоваться вашим проектом и решить протестировать его? А уж работодатели просто обожают интерактивные проекты. Этим вы покажете, что ваш проект не просто кусок кода, лежащий на github, но заодно продемонстрируете своё серьёзное отношение к делу.
Да, всё верно: в readme можно использовать гиперссылки, так что поместите ссылку на интерактивную демо-версию прямо под изображением с названием.
4. Форматируем код
Разметка даёт возможность форматировать текст, как код. Поэтому не пишите код, как обычный текст, а воспользуйтесь знаком `, чтобы придать коду аккуратный вид var a = 1;
Github также даёт возможность указывать язык, на котором написан код, и использовать соответствующее выделение текста, улучшая читаемость кода. Вот как это делается:
«`{название-языка}<пробел>{блок кода}«`
«` используется для многострочного кода и позволяет указывать язык блока кода. Сравните:
И
5. Используем HTML
Да, внутри можно использовать HTML. Не все функции, но большинство. Рекомендуется всё же придерживаться разметки, но некоторые функции, такие как выравнивание текста и изображений по центру, в readme доступны только с использованием HTML.
6. Творим
Всё остальное зависит от вас. Ведь каждому проекту нужен свой readme и свой тип описания. Так проявите изобретательность: те 15–20 минут, которые вы потратите на readme, могут произвести неизгладимое впечатление на посетителей вашего профиля на github.
Пример readme на github вы найдёте тут. И вот ещё одна ссылка к этому же проекту https://github.com/silent-lad/Vue2BaremetricsCalendar
Читайте также:
- Репозитории GitHub в помощь каждому веб-разработчику
- Знакомство с Git и GitHub: руководство для начинающих
- Как создать бесплатный сайт на GitHub Pages
Перевод статьи Divyansh Tripathi [SilentLad]: How to Write Beautiful and Meaningful README.md
