Текущие глобальные и не очень проблемы архитектуры pvm.
Сейчас есть единая абстракция для "создание коммитов", через платформу, через гит и по сути эта же абстракция используется для изменения файлов локально.
Тут есть проблемы:
- Иногда нужно все таки явное разделение, где мы работаем, локально или общаемся с platform api.
- В основом pvm-core работает с локальным рабочим деревом,
и при создании тега через платформу мы получим рассинхрон между рабочим деревом и тем что наработали через vcsPlatform.
Можно при этом явно делать
git fetch, но про это надо знать, что увеличивает когнитивную нагрузку.
Нет моделей взаимодействия различных компонентов системы, чтобы при добавлении новой функциональности, иметь возможность покрывать самые важные или время от времени прогонять недетерменированные комбинации взаимодействия моделей.
- нет возможности делать вложенные транзакции beginCommit – rollbackCommit.
- создание тегов для пакетов происходит после пуш фазы, – в случае vcs=git просто не доедут до origin. Но это по сути deprecated behavior и лучше просто удалить возможность создания отдельных тегов для пакетов.
- rollbackCommit откатывает только fs - изменения, транзакционная модель в этом плане не полная – теги остаются как есть.
- Глупый _isSomethingForCommit – его лучше делегировать вниз
Надо грамотно использовать ресурсы. Легко свалится в кейс когда в цикле выполняется 600 io операций, где по факту нужно сделать всего два, а остальное отдать из кеша. Например кейс с lastReleaseTag – он используется при расчете версий но кешировать совсем его нельзя, нужен механизм инвалидации.
Также тут можно добавить что не хватает тестов и мониторинга производительности на уровне мерж-реквестов.
UpdateState содержит мапы уровня Pkg -> value. Для внутренних нужд и нужд возле обновления это ок, но не ок для вшненего потребления, т.к. сущность пакета дифферинцируется в том числе по ref'у. По имени пакета данные получить будет уже проблематично при такой необходимости.