204 lines
7.7 KiB
Markdown
204 lines
7.7 KiB
Markdown
# Этапы разработки
|
||
|
||
## Общий принцип
|
||
|
||
Не делаем сразу тяжелую доменную платформу.
|
||
|
||
Идем вертикальными поставками:
|
||
1. сначала транспорт и создание задачи
|
||
2. потом source-side представление
|
||
3. потом синхронизация
|
||
4. потом уведомления и полировка
|
||
|
||
## Этап 0. Термины и навигация
|
||
|
||
### Цель
|
||
|
||
Подготовить интерфейс и словарь сущностей без ломки backend-логики.
|
||
|
||
### Что входит
|
||
|
||
- `Рабочие элементы` -> `Внутренний контур`
|
||
- новая вкладка `Внешние контуры`
|
||
- подготовка i18n-ключей и текстов
|
||
- фиксация терминов в продуктовой документации
|
||
|
||
### Результат
|
||
|
||
В проекте уже есть новая структура навигации, но бизнес-логика еще не внедрена.
|
||
|
||
## Этап 1. Маршрутизация запроса в целевой проект
|
||
|
||
### Цель
|
||
|
||
Сделать рабочий сценарий отправки задачи из source project в target project.
|
||
|
||
### Что входит
|
||
|
||
- новая create-form во `Внешних контурах`
|
||
- выбор целевого проекта
|
||
- выбор исполнителя из целевого проекта
|
||
- orchestration endpoint
|
||
- использование intake bridge как backend-моста
|
||
- немедленный перевод в default-state целевого проекта
|
||
- создание target issue
|
||
- запись source/target metadata
|
||
|
||
### Что не входит
|
||
|
||
- полноценная синхронизация файлов
|
||
- полноценная зеркальная история
|
||
- сложные уведомления
|
||
|
||
### Критерий приемки
|
||
|
||
- пользователь отправляет внешний запрос
|
||
- в целевом проекте появляется обычная задача
|
||
- задача не зависает в triage
|
||
- source-side список уже видит факт отправки
|
||
|
||
## Этап 2. Source-side список и статусная пришлепка
|
||
|
||
### Цель
|
||
|
||
Дать инициатору читаемый контроль за отправленными запросами.
|
||
|
||
### Что входит
|
||
|
||
- список `Открытые`
|
||
- список `Завершенные`
|
||
- текущий статус задачи как пришлепка
|
||
- отображение целевого проекта
|
||
- отображение исполнителя
|
||
- отображение даты обновления
|
||
- индикатор новых изменений
|
||
|
||
### Критерий приемки
|
||
|
||
- в проекте-источнике виден список отправленных запросов
|
||
- у каждой записи отображается актуальный статус целевой задачи
|
||
|
||
## Этап 3. Source-side детальный экран и зеркалирование изменений
|
||
|
||
### Цель
|
||
|
||
Сделать так, чтобы отправитель видел ход исполнения не только по одной плашке статуса.
|
||
|
||
### Что входит
|
||
|
||
- детальный экран внешнего контура
|
||
- блок `Исходный запрос`
|
||
- блок `Текущий статус`
|
||
- mirrored activity stream
|
||
- mirrored comments
|
||
- mirrored files
|
||
- mirrored description updates
|
||
|
||
### Важное правило
|
||
|
||
Исходный запрос не должен теряться.
|
||
|
||
Поэтому target-изменения лучше показывать отдельным блоком истории, а не просто затирать исходное описание.
|
||
|
||
### Критерий приемки
|
||
|
||
- если в target issue добавили файл, инициатор видит его в source-side карточке
|
||
- если в target issue поменяли статус, это видно в source-side карточке
|
||
- если в target issue написали комментарий, это видно в source-side карточке
|
||
|
||
## Этап 4. Уведомления
|
||
|
||
### Цель
|
||
|
||
Не заставлять инициатора вручную проверять изменения.
|
||
|
||
### Что входит
|
||
|
||
- in-app notification на:
|
||
- принятие
|
||
- перевод статуса
|
||
- добавление файла
|
||
- новый комментарий
|
||
- завершение
|
||
- отмену
|
||
|
||
### Критерий приемки
|
||
|
||
- инициатор получает уведомления по ключевым событиям жизненного цикла внешнего запроса
|
||
|
||
## Этап 5. Полировка и правила эксплуатации
|
||
|
||
### Что входит
|
||
|
||
- edge cases
|
||
- повторная отправка
|
||
- отмена
|
||
- защита от удаления target issue
|
||
- аудит прав
|
||
- тест-кейсы
|
||
- регламент эксплуатации
|
||
|
||
## Технические решения, которые желательно держать с самого начала
|
||
|
||
### 1. Не ломать штатный intake
|
||
|
||
Он остается отдельным продуктовым модулем.
|
||
|
||
### 2. Явно хранить source/target связь
|
||
|
||
Даже если первая версия идет через `IntakeIssue.extra`, связь не должна быть неявной.
|
||
|
||
### 3. Использовать фактический статус target issue
|
||
|
||
В source-side плашке лучше показывать не abstract intake status, а реальный текущий статус исполнения.
|
||
|
||
### 4. Не пытаться делать полную двустороннюю редакцию сразу
|
||
|
||
На старте безопаснее сделать:
|
||
- создание из источника
|
||
- исполнение в цели
|
||
- синхронизацию результата обратно в источник
|
||
|
||
## Открытые вопросы
|
||
|
||
### 1. Source-side сущность
|
||
|
||
Нужно принять решение:
|
||
- достаточно ли source-side проекции
|
||
- или нужна отдельная таблица/модель для внешних контуров
|
||
|
||
### 2. Файлы
|
||
|
||
Нужно решить:
|
||
- показываем ли мы source-side ссылку на target asset
|
||
- или физически копируем файл в source representation
|
||
|
||
### 3. Комментарии
|
||
|
||
Нужно решить:
|
||
- комментарии зеркалируются односторонне из цели в источник
|
||
- или источник тоже может отвечать прямо из source-side карточки
|
||
|
||
### 4. Уровень realtime
|
||
|
||
Нужно решить:
|
||
- хватит ли near-realtime через polling и existing refresh
|
||
- или сразу нужен realtime через live-события
|
||
|
||
### 5. Доступ к target issue
|
||
|
||
Нужно решить:
|
||
- должен ли инициатор иметь прямую ссылку на target issue
|
||
- или доступ к target issue должен быть скрыт, а source-side карточка должна быть единственной точкой просмотра
|
||
|
||
## Рекомендуемый порядок фактической разработки
|
||
|
||
1. Этап 0
|
||
2. Этап 1
|
||
3. Этап 2
|
||
4. Этап 3
|
||
5. Этап 4
|
||
6. Этап 5
|
||
|
||
Это даст быстрый полезный результат и не загонит проект в ранний тяжелый refactor.
|