Модуль 04 — README и документация проекта

Как писать документацию, которую читают: структура, стиль, проверка и выгрузка в другие форматы

Прогресс курса Модуль 4 из 5

Что вы освоите в этом модуле

01

README: первая страница проекта

README отвечает на вопросы человека, который впервые открыл репозиторий: что это, зачем, как запустить и к кому обращаться. Хороший README позволяет развернуть проект, ни разу не спросив автора.

# Портал заданий

Сервис приёма и проверки учебных работ для курсов Nevabit.

## Возможности

- сдача работ текстом и файлами
- проверка по критериям с комментариями
- журнал оценок по группам

## Требования

- Debian 13
- PostgreSQL 17
- PHP 8.4

## Установка

1. Склонируйте репозиторий
1. Скопируйте `config.example.php` в `config.php` и укажите доступ к базе
1. Выполните установку:

   ```bash
   php admin/cli/install_database.php
   ```

## Использование

Краткий пример основного сценария или ссылка на [руководство](docs/usage.md).

## Документация

- [Установка на сервер](docs/install.md)
- [Частые вопросы](docs/faq.md)
- [История изменений](CHANGELOG.md)

## Контакты

Вопросы и ошибки — в задачи репозитория.

Правила

  • Первая строка — название, вторая — одно предложение о назначении проекта
  • Установка — нумерованным списком, команды — в блоках кода, которые можно копировать целиком
  • Длинные разделы выносятся в docs/, в README остаётся ссылка
  • Никаких паролей, токенов и внутренних адресов: README видят все, у кого есть доступ к репозиторию, и он остаётся в истории git навсегда
  • Устаревший README хуже отсутствующего: меняется порядок установки — меняется README в том же коммите
02

Документация проекта и журнал изменений

project/
├── README.md          что это и как запустить
├── CHANGELOG.md       история изменений по версиям
├── CONTRIBUTING.md    как предлагать изменения
└── docs/
    ├── install.md     установка на сервер
    ├── usage.md       руководство пользователя
    ├── faq.md         частые вопросы
    └── img/           изображения для документации

Журнал изменений удобно вести по соглашению Keep a Changelog: новые версии сверху, изменения сгруппированы по типу, для ещё не выпущенных изменений есть раздел Unreleased.

# Changelog

## [Unreleased]

### Added
- Выгрузка ведомости в Excel

## [1.1.0] - 2026-09-20

### Added
- Оценочные листы для заданий курса «Базы данных»

### Fixed
- Сброс нумерации в инструкции по установке

## [1.0.0] - 2026-09-13

### Added
- Первая версия портала

Группы изменений

  • Added — новое, Changed — изменено, Deprecated — скоро удалится
  • Removed — удалено, Fixed — исправлено, Security — исправления уязвимостей
  • Даты — в формате ГГГГ-ММ-ДД: однозначно и сортируется
  • Журнал пишется для людей: «исправлена ошибка входа при смене пароля», а не список сообщений коммитов
03

Единый стиль и проверка

Markdown прощает многое: неаккуратный документ всё равно как-то отобразится. Чтобы документация команды выглядела одинаково и не ломалась на другой платформе, стиль проверяют линтером — markdownlint. В VS Code он ставится расширением и подчёркивает нарушения прямо при наборе.

ПравилоЧто требует
MD001уровни заголовков увеличиваются по одному
MD009нет пробелов в конце строк
MD012нет нескольких пустых строк подряд
MD022пустые строки вокруг заголовков
MD040у блоков кода указан язык
MD041первая строка файла — заголовок первого уровня

Правила, которые команде не подходят, отключают в файле .markdownlint.json в корне проекта — например, ограничение длины строки MD013 для русских текстов часто выключают:

{
  "MD013": false
}

Соглашения, о которых стоит договориться

  • Маркер списков — -, выделение — * и **
  • Имена файлов — латиница в нижнем регистре через дефис: install-guide.md
  • Один документ — одна тема; больше 300–400 строк — повод разбить
04

Переносимость и конвертация

Переносимость

  • Документ, который должен работать везде, пишется на CommonMark и таблицах GFM
  • Сноски, Mermaid, вики-ссылки [[...]], цветные блоки-предупреждения — возможности конкретных сервисов; используйте их, только если платформа известна и не изменится
  • Проверка — предпросмотр на целевой платформе, а не в редакторе

Не всем удобно читать документацию в репозитории: заказчику или учебной части нужен файл Word. Для этого есть Pandoc — конвертер между форматами, устанавливается из репозитория пакетов системы (в Debian: apt install pandoc).

# Markdown → Word
pandoc README.md -o README.docx

# Markdown → самостоятельная HTML-страница
pandoc -s docs/install.md -o install.html

# Несколько файлов в один документ
pandoc README.md docs/install.md docs/usage.md -o manual.docx
Источник правды — Markdown в репозитории. DOCX и HTML — производные файлы: их не правят руками, а пересобирают командой. Иначе через месяц версия в Word и версия в git разойдутся.

Запомните главное

  • README: что это, как запустить, где подробности — без секретов
  • Документация меняется в том же коммите, что и код
  • CHANGELOG — для людей, новые версии сверху, Unreleased для будущего релиза
  • Стиль проверяет markdownlint, исключения фиксируются в .markdownlint.json
  • DOCX и HTML собираются из Markdown через Pandoc, а не правятся вручную
Практические задания — на учебном портале. Задания, критерии оценивания, сдача работ и оценки преподавателя — в курсе на portal.nevabit.ru. Учётную запись выдаёт преподаватель.
Модуль 03: Код и таблицы Все модули Итоговый проект