Перевод статьи «How to Write an Awesome GitHub README».
Я прочел самый ранний (из тех, что смог найти) файл README. Он был написан в 1975 году Вильямом Дж. Эрлом из CS-отдела UIC. Текст суховат, но удивительно актуален даже 44 года спустя. «Из-за бага в компиляторе эта функция неправильно компилируется».
README это индикатор того, как поддерживается репозиторий. Причем, когда этот файл хороший, это не значит, что проект активный, не содержит багов и прекрасно покрыт тестами. Это показывает, что собственник репозитория заботится о вас, пользователе (или будущем мейнтейнере). Хороший README расскажет вам, как пользоваться этим проектом и как принять в нем участие. Он продает проект, но дает знать посетителям, что, возможно, им нужно другое решение. Таким образом этот файл как бы выражает уважение автора к читателям и экономит их время.
При использовании GitHub-профайла как части приложения файлы README приобретают особое значение. Они демонстрируют навыки технического письма – способность к хорошей коммуникации и умение собирать воедино документ, описывающий программу.
Трудно ожидать, что кто-то захочет погрузиться в ваш код, если ему не предоставили общего описания проекта. Поэтому файлы README просто необходимы.
Четкое описание
Люди должны иметь возможность использовать созданное вами программное обеспечение, даже если не прочтут ни строчки вашего кода.
Для начала, измените дефолтное название, которое дает GitHub. Например, смените python-ml-project-for-cat-lovers-2 на Cat Crawler — Classify Cat GIFs. Следующий шаг – объяснение вашего проекта в простейшей форме. Многие люди используют однострочный комментарий в самом верху. Например: «Бот для скачивания и индексации GIF-файлов с котами».
Следует учитывать, что чем длиннее описание, тем больше риск умственной перегрузки читателя.
Отредактируйте ваш текст. Используйте заголовки, переносы строк, разбивку на абзацы (два перевода строки, чтобы начать новый абзац, и <br> для разрыва строки. Шпаргалка.). Не стесняйтесь использовать логотипы продуктов и скриншоты. В отличие от прочей технической документации, здесь мультимедиа работает хорошо.
Если ваш репозиторий содержит что-то интересное и веселое, это должно отражаться в его описании! Безусловно, изложение текста в соответствии с правилами стилистики и композиции имеет значение, однако интернет это место, где классные программисты могут проявлять свое творческое начало. Обратите внимание на README проекта not-paid (спасибо большое его создателям), который помогает разработчикам сайтов обезопасить себя от недобросовестных клиентов.
Использование
Каким образом следует использовать ваш проект? Если это API, у вас должен быть приведен отрывок кода с самыми основными взаимодействиями. Более полная документация может быть изложена ниже или где-то в другом месте. Например, facebook/react в своем README дает небольшой фрагмент кода – маленький пример использования React. Используйте одинарные левые кавычки (`) для выделения кода и по три таких кавычки для разделения блоков кода. Для специфической подсветки синтаксиса указывайте язык сразу после первого экземпляра трех кавычек.
Покажите результат работы кода. Если можно приложить GIF – сделайте это! Файлы GIF очень помогают людям разобраться в том, что именно вы хотите им показать. Это великолепно использовано в README проекта alexfoxy/laxxx (библиотека для плавных web-анимаций).
Для создания GIF-файлов я использую инструмент с открытым кодом ShareX. Он просто выбирает область вашего экрана. Могу посоветовать и другое решение, тоже open source, – LICEcap.
Установка
Допустим, ваш посетитель хочет установить себе ваш проект после того, как увидел его в действии. Раздел с описанием установки иногда называется Getting Started («как начать»). Он должен быть в каждом проекте, даже если весь процесс установки заключается во введении в терминале команды npm install catcrawler.
Если ваш проект – статический сайт, скажите об этом! Напишите что-то вроде «Разместите родительский каталог на веб-сервере». Укажите, знание каких базовых инструментов понадобится читателю для установки. Не нужно пояснять, что такое pip или npm, просто перечислите все команды, которые нужно будет запускать при установке и первоначальной настройке.
У DEV есть очень основательный раздел о сборке и запуске. Это отличный пример, которому смело можно следовать, если хотите, чтобы ваш продукт был доступен людям. Хорошая практика при этом – запустить виртуальную машину и самому попробовать воспользоваться своим руководством по инсталляции.
Значки (Badges)
Значки на GitHub, главным образом стандартизированные при помощи badges/shields, это одна из первых вещей, на которые обращает внимание посетитель, прокручивая страницу. Значки со статусом сборки описывают стабильность проекта. Другие значки могут показывать активность репозитория, указывая количество коммитов за месяц или число мейнтейнеров. Все эти значки не обязательны, но, как и GIF, являются большим преимуществом.
У shields.io есть API для создания ваших собственных значков, а также npm-пакет, приятный в использовании. С его помощью я сделал и запустил несколько значков меньше, чем за час. Другая npm-альтернатива это badger. У Python есть pybadges от Google.
Участие в проекте (Contributing)
Если вам нужны соратники, то очень желательно добавить раздел для потенциальных контрибуторов. На GitHub есть стандарт добавления файла CONTRIBUTING.md в корневую папку. Там может быть изложен кодекс поведения и общие рекомендации по поиску проблем и созданию пул-реквестов. Такие пошаговые руководства могут помочь большому количеству новичков, жаждущих принять участие в open source проектах. Я знаю, что некоторые из моих друзей поддерживают только репозитории с четко прописанными правилами для мейнтейнеров.
Если вы не уверены, с чего начать, мне недавно попался генератор кодексов поведения, который, как мне кажется, очень хорошо исполнен.
Лицензия
Когда я ищу решение для каких-то рабочих вопросов, первое, на что я обращаю внимание, это лицензия. При создании репозитория на GitHub есть опция выбора лицензии, благодаря чему для вас будет сгенерирован файл LICENSE.md. У GitHub также есть страница, посвященная этому файлу, а еще они создали choosealicense.com – фантастическое руководство по всем возможным вариантам.
Лично я для своего открытого исходного кода использую лицензию MIT. У некоторых людей есть свое сложившееся мнение относительно лицензирования, особенно, когда речь идет о GPL. «Любые модификации программы, включающие код, лицензированный по лицензии GPL, также должны быть доступны под лицензией GPL вместе с инструкциями по сборке и установке».
Шаблоны
Существует много шаблонов README-файлов. Это прекрасный вариант «на крайний случай», но я обнаружил, что «из коробки» они не совсем подходят для небольших проектов. Конечный вариант получается слишком холодным. Шаблоны больше пригождаются более крупным, состоявшимся проектам, но с учетом времени, вложенного в разработку, все равно имеет смысл сделать собственное решение.
Вот это мой фаворит среди шаблонов. Мне он нравится, поскольку там все сделано четко и по сути, а кроме того есть два подраздела для тестов. Если у вас есть какие-то тесты, следует упомянуть об этом в вашем README. Первое, что я делаю при клонировании проекта, это запускаю тесты. Это позволяет удостовериться, что для разработки все готово.
Другие разделы
Разобравшись с основными разделами, можно дополнить README по своему вкусу. Возможно, я окажусь в меньшинстве, но мне нравится бродить по GitHub в поисках новых вещей и разбираться, как они устроены. Я благодарен репозиториям, в которых есть подробные файлы README с большим количеством примеров кода. Чтобы увлечься проектом, я должен видеть, что мейнтейнерам он интересен по крайней мере не меньше, чем мне.
Чтобы получить какое-то представление о стандартном оформлении, рекомендую исследовать тренды вашего языка программирования. А для вдохновения обратите внимание на два моих последних фаворита: Gatsyby и lax.js. Сделайте так, чтобы ваша документация стала просто песней!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]