Ссылка: https://blog.manganin.dev/blog/reinventing-issue-tracking/
Идея сначала кажется почти тупой:
а что если каждая задача — это просто файл?
Например:
issues/
├── telegram-messages-stay-unread
├── slow-message-sending
└── fix-login
Внутри файла — описание задачи.
А история изменений, синхронизация, конфликты, offline mode — всё это уже умеет Git.
То есть буквально:
задача = файл
список задач = папка
история = Git
синхронизация = git push / git pull
И всё.
Но тут возникает очевидная проблема: а почему бы просто не положить
.issues прямо в репозиторий с кодом?Представим:
project/
├── src/
├── package.json
└── .issues/
Вы две недели сидите в
feature/new-chat.А за это время в
main коллеги:— создали 15 задач — закрыли 10 — поменяли описания — добавили комментарии
И теперь issue tracker начинает жить внутри ваших code branches.
Чтобы просто увидеть актуальные задачи, надо тянуть
main, ребейзиться и вообще смешивать две вещи, которые друг к другу отношения почти не имеют.Хуйня же получается.
Автор пошёл дальше и попробовал использовать внутренности Git:
refs/issues/1
refs/issues/2
refs/issues/3
Технически — красота.
Git и так умеет хранить refs, commits, trees, blobs. Почему бы не засунуть туда ещё и issues?
А потом выясняется, что чтобы просто изменить пару строк в задаче, начинается:
git hash-object
git mktree
git commit-tree
git update-ref
И в какой-то момент возникает очень правильный вопрос:
«А зачем же я вообще пытаюсь сделать из Git базу данных?»
И вот после этого автор приходит к финальному решению.
Два репозитория.
Один:
project.git
Там код.
Второй:
project-issues.git
Там задачи.
И второй репозиторий — буквально набор обычных файлов.
В итоге:
CODE ISSUES
│ │
code repo issues repo
│
обычные файлы
Клиент написал новый баг?
Изменился только issues repo.
Вы в этот момент пилите feature branch?
Вообще похуй. Ваша ветка кода никак не поменялась.
Закрыли задачу?
Коммит в issues repo.
Исправили код?
Коммит в code repo.
Два независимых потока изменений.
А сверху можно спокойно нарисовать привычный интерфейс:
○ Telegram messages stay unread
○ Slow message sending
✓ Fix login
И пользователь вообще может не знать, что под капотом это просто файлы в Git.
При этом не нужен отдельный Postgres, IssueService, REST API, синхронизация, история изменений и ещё двадцать слоёв хуйни, потому что половину этой работы Git уже умеет делать сам.
Но самое интересное в статье для меня даже не issue tracker.
А сам ход мысли.
Мы очень часто начинаем проектирование с вопроса:
«Как правильно построить архитектуру такой системы?»
И дальше понеслось:
сервис база API events queues repositories DTO
ещё какая-нибудь дичь
Хотя иногда полезнее сначала спросить:
«А какой workflow я вообще хочу получить?»
И уже потом думать, какая архитектура для него нужна.
Потому что иногда после этого оказывается, что вместо отдельного сервиса, базы данных и API вам достаточно:
файла, папки и Git.
И это прекрасно.