Files
svc-api-x/analysis/project-history-analysis.md
T

147 lines
10 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Анализ истории и устройства проекта svc-api-x
## Краткий вывод
Это не маленький новый сервис, а зрелый и уже наследованный CFML/ColdFusion API-проект, построенный вокруг Taffy REST framework. По истории видно, что репозиторий появился не как пустая заготовка, а как большой импорт уже существующего кода и сопутствующих материалов, после чего в него вносили точечные правки, в том числе связанные с безопасностью и чисткой секретов.
На текущий момент в истории репозитория 364 коммита.
## Хронология
### 1. Старт репозитория: крупный импорт существующего проекта
Корневой коммит:
- hash: `ab5c944862b102e27a1f04da24ffe19c1e24093c`
- сообщение: `initial`
- дата: `2024-10-23 12:17:42 +0400`
- автор: `msyu <msyu@mail.ru>`
По содержимому корневого снимка видно, что в репозиторий сразу попал не пустой скелет, а уже насыщенное дерево файлов:
- `v1/Application.cfc`
- `v1/index.cfm`
- `v1/lib/*`
- `v1/resources/*`
- `taffy/*`
- `build/Dockerfile`
- `build/Jenkinsfile`
- `v1/etc/*`
- архивные и справочные HTML-файлы внутри `v1/etc/info`
Это типичный признак импортированного legacy-кода: сначала в git попала почти готовая рабочая система, а не минимальный bootstrap.
### 2. Последующее развитие: доработка прикладной логики и инфраструктуры
Структура текущего кода показывает, что проект дальше развивался как полноценный API-сервис:
- слой входа и конфигурации живет в `v1/Application.cfc`
- бизнес-утилиты и сериализация вынесены в `v1/lib`
- доменные сущности и REST-ресурсы находятся в `v1/resources`
- Taffy framework лежит локально в `taffy/`, то есть проект либо завязан на вендорнутую копию, либо хранит её как часть исходников
- сборка и деплой оформлены через `build/Dockerfile` и `build/Jenkinsfile`
Содержимое `v1/Application.cfc` показывает несколько важных вещей:
- приложение наследуется от `taffy.core.api`
- маппинги явно указывают на `resources`, `taffy` и `lib`
- конфиг тянется из разных окружений: `conf/prod.cfm`, `conf/stage.cfm`, `conf/dev.cfm`
- есть fallback-конфигурация на случай отсутствия внешнего конфига
- приложение завязано на IAM endpoint и Vault-переменные окружения
- используются глобальные заголовки CORS и версия API
Это говорит о том, что проект не просто «API», а реальный сервисный слой с окруженческой конфигурацией, аутентификацией и инфраструктурными зависимостями.
### 3. Современный этап: чистка и консолидация наследия
Текущий HEAD-коммит:
- hash: `74c073bd7e72926b842fa28a5d0fe78515531a91`
- сообщение: `deprecated secret clean`
- дата: `2026-04-29 18:25:11 +0400`
- автор и committer: `unknown <smishchuk@nubes.ru>`
Само сообщение коммита показывает, что в истории был отдельный этап чистки устаревших секретов или их следов. Это важный сигнал: репозиторий не только развивали, но и позднее приводили в более безопасное состояние.
## Что именно лежит в проекте
### Технологический профиль
Проект выглядит как CFML/ColdFusion сервис, работающий через Taffy REST framework.
Основные признаки:
- `v1/Application.cfc` содержит CFML-код и расширяет `taffy.core.api`
- `v1/index.cfm` явно служит заглушкой для Tomcat
- в `v1/lib` находятся утилиты и сериализаторы
- в `v1/resources` лежат REST-ресурсы и доменные модели
- `build/Dockerfile` и `build/Jenkinsfile` указывают на контейнерную сборку и CI
### Доменная структура
По именам файлов видно, что сервис работает с:
- инстансами
- сервисами (`svc`)
- пользователями
- ресурсными realm-ами
- параметрами и subparam-ами
- операциями и валидацией операций
- событиями и уведомлениями
То есть это не узкий утилитарный API, а довольно широкий метаданных/управляющий сервис.
### Следы наследованного кода и артефактов
В корневом снимке и в дереве репозитория есть признаки долгой жизни проекта:
- backup-файлы `*.bk`, `*.bak`
- архивированные или скопированные HTML-страницы и их ассеты
- файлы с промежуточными/сервисными именами
- плавающие старые документы и фрагменты справочного материала
Это обычно означает, что кодовая база росла поверх старой рабочей системы, а не создавалась заново по чистой архитектуре.
## История по смысловым этапам
### Этап A. Импорт и закрепление базовой платформы
Вероятнее всего, на старте в git попал уже существующий CFML-проект с Taffy и прикладной логикой. Коммит `initial` не выглядит как создание с нуля минимального прототипа, потому что в нем уже много файлов, конфигураций и старых материалов.
### Этап B. Развитие API и доменной модели
Дальше репозиторий, судя по структуре, развивали вокруг сущностей `instance`, `svc`, `resource realm`, `operation`, `param`, `user`. Это похоже на сервис управления конфигурациями и состоянием, а не на классический CRUD без доменной сложности.
### Этап C. Интеграция с инфраструктурой
В `Application.cfc` видны:
- выбор stand-окружения из базы
- маршрутизация на IAM service
- использование Vault переменных
- настройка CORS и общих HTTP-заголовков
Это этап, когда приложение стало частью окружения облачной инфраструктуры и перестало быть автономным кодом.
### Этап D. Поздняя санитарная правка
Коммит `deprecated secret clean` показывает, что в поздней фазе проводили гигиену репозитория: убирали deprecated secret material или следы чувствительных данных.
## Технические риски и особенности
1. `Application.cfc` перегружен ответственностями.
Там одновременно живут конфигурация, безопасность, выбор окружения, IAM-логика и часть инфраструктурных решений.
2. Есть жесткая зависимость от внешних окружений.
Сервис ожидает `conf/prod.cfm`, `conf/stage.cfm`, `conf/dev.cfm` и env-переменные для Vault и IAM.
3. В проекте много исторического наследия.
Backup-файлы и архивные HTML-ассеты усложняют чтение истории и затрудняют понимание того, что реально используется сейчас.
4. Архитектура явно эволюционная, а не чистая.
Это видно и по структуре, и по комментариям в коде, и по смешению кода, конфигов и инфраструктурных деталей.
## Итог
Если сжать всё до одной фразы: это старый, но активно живший CFML/Taffy API-сервис, который начинался как большой импорт уже существующего решения, затем обрастал инфраструктурными зависимостями, а позднее проходил чистку и локальную консолидацию.
Для дальнейшего анализа логично идти в одном из двух направлений:
- по коммитам разложить историю на этапы и найти ключевые тематические изменения
- отдельно разобрать архитектуру кода: вход, auth, ресурсы, сериализация, деплой, legacy-артефакты
---
Анализ выполнен моделью GitHub Copilot GPT-5.4 mini.
Дата и время формирования отчета: 2026-04-29 20:13:09 +0400.