Экспертиза документов проекта с помощью Claude Sonnet

Пришло предложение доработать проект: игрушка-тапалка. Разработчик покинул проект, утверждая, что всё на завершающей стадии, 90% работы сделано, осталось 3-4 дня на финальную доработку. Предоставлена ссылка на множество документов. Дан адрес репозитория и как его клонировать.

Решил с помощью Claude Sonnet 4.0 проверить что из себя представляет весь этот зоопарк. Открыл новый проект в Pro версии Claude. Скопировал туда первичную переписку, все доступные файлы. Дал задание нейросети.

Задание Клоду на аудит документов проекта

Как я писал раньше, работаю с Claude только на английском. Здесь всё привожу в переводе на русский.

Мне предложили проект для доработки.
Сначала ознакомься с предварительной перепиской.
Также даю ссылку на Яндекс диск.
Там много файлов:
Я скопировал оттуда основные. Там есть исходные файлы, рабочие файлы, весь проект. Можешь прочитать файлы по ссылке? Если нет — я скопирую их в документы проекта.

Мне нужна твоя экспертиза:
1) Общее представление о проекте. Каковы шансы на его успешное завершение?
2) Что у нас есть?
3) Что необходимо сделать? Приведи список. Что сложно или невозможно выполнить? Опиши взаимосвязь между предстоящими работами и их последовательность.
4) Какие подводные камни следует ожидать? Будем считать, что эти документы — все, что у нас есть. Не будет другого мнения, совета или какой-либо помощи от предыдущего разработчика.
5) Чего не хватает? Что из этого имеет решающее значение?
6) Как бы ты оценил время завершения, реалистичное и пессимистичное?
7) Какие дополнительные вопросы следует задать клиенту?

Экспертный ответ Claude Sonnet

Ознакомившись с вашей проектной документацией, я могу предоставить всестороннюю техническую оценку. Позвольте мне систематизировать все это, поскольку правильное понимание текущей ситуации имеет решающее значение для принятия обоснованных решений о дальнейших действиях.

1. Общая оценка проекта и шансы на успех

Похоже, что проект имеет прочную основу и хороший потенциал для завершения. Выбранная архитектура (Next.js, TypeScript, tRPC, PostgreSQL) представляет собой современный масштабируемый подход, который хорошо подходит для мини-приложения Telegram. Документированный набор функций демонстрирует продуманный дизайн игры, сочетающий механику кликера с элементами ухода за домашними животными.

Однако есть один важный нюанс: хотя предыдущий разработчик заявлял о “завершении на 90%”, техническая документация выявляет несколько фундаментальных проблем, которые предполагают, что эта оценка может быть чрезмерно оптимистичной. Когда основные функции, такие как кнопка подачи сообщений, не работают, а интеграция с базой данных сообщений нарушена, это указывает на более глубокие архитектурные проблемы.

Вероятность успеха: 70-80% – достижимо, но требует тщательного изучения существующей кодовой базы.

2. Что у нас есть на данный момент

Исходя из документации, реализованная основа включает:

Базовая архитектура: Next.js 14 с App Router, интеграция с TypeScript, tRPC для взаимодействия с API, обеспечивающим безопасность типов, база данных PostgreSQL с DrizzleORM и интеграция с Telegram Bot API.

Игровая механика: Базовая функциональность постукивания с анимацией, структура энергетической системы, система повышения уровня (4 уровня от egg до super), механизм сбора монет и инфраструктура таблицы лидеров.

Пользовательский интерфейс: компоненты адаптивного дизайна, индикаторы прогресса для различных статистических данных, интерфейс взаимодействия с персонажами, экраны магазина и профиля, а также поддержка тёмного режима.

Расширенные возможности: Создание реферальной системы, система промо-кодов, интеграция аналитики с PostHog и настройка развертывания для Vercel.

3. Остающаяся важная работа и зависимости

Предстоящая работа выполняется в определенной последовательности из-за технических зависимостей:

Этап 1 – Исправление основных ошибок (высокий приоритет)

Сначала мы должны устранить проблемы с интеграцией базы данных. Всплывающие сообщения, которые не загружаются из базы данных, указывают на проблемы с шаблонами асинхронной выборки данных. Это необходимо устранить, прежде чем другие функции смогут работать надежно. Неработающая кнопка подачи, вероятно, связана с аналогичными проблемами взаимодействия с API.

Этап 2 – Согласование пользовательского интерфейса и оптимизация для мобильных устройств.

В дальнейшем необходимо решить проблемы с оформлением индикатора выполнения и адаптивным дизайном. Они влияют на взаимодействие с пользователем во всех функциях, поэтому их исправление на ранней стадии предотвращает повторную работу.

Этап 3 – Отсутствие основных функций

Таймер истощения энергии представляет собой фундаментальную игровую механику, которая влияет на поведение пользователей. Система регистрации пользователей также имеет решающее значение для получения промо-кода и сохранения прогресса.

Этап 4 – Расширенные возможности

Интеграция магазина с реальными покупками, улучшенная механика привлечения рефералов и система достижений могут быть реализованы только после того, как будет создана стабильная основа.

4. Подводные камни и факторы риска

Проблема с отсутствующей кодовой базой: это ваш самый большой риск. Без доступа к реальному хранилищу кода мы, по сути, начинаем судебное расследование. Предыдущий разработчик, возможно, внедрил решения, которые не соответствуют документации, или качество кода может быть значительно хуже, чем ожидалось.

Накопление технической задолженности: Четыре месяца разработки с пропущенными сроками часто указывают на накопление технических недостатков. Мы можем обнаружить жёстко заданные значения, неполную обработку ошибок или архитектурные решения, которые изначально имели смысл, но стали проблематичными по мере добавления функций.

Сложность интеграции с Telegram: мини-приложения Telegram имеют особые требования к аутентификации, платежам и обработке пользовательских данных. Любые ошибки в этой интеграции могут потребовать существенной доработки.

Проблемы с миграцией базы данных: Требование добавлять новые параметры базы данных (специальные события, достижения, количество переходов), не вызывая проблем с переносом, предполагает, что текущая схема правильно спроектирована для обеспечения расширяемости. Что может оказаться неверным.

5. Критическая недостающая информация

Самый важный недостающий элемент: доступ к фактическому хранилищу кодовой базы. Без этого мы не сможем оценить качество кода, понять текущий подход к реализации или определить первопричины обнаруженных ошибок.

Документация по схеме базы данных: Несмотря на то, что у нас есть описания функций, нам нужна реальная структура базы данных, чтобы понимать взаимосвязи данных и безопасно планировать миграцию.

Текущее состояние развертывания: Есть ли рабочая версия, которую мы можем протестировать? Понимание того, что работает в данный момент, а что не работает, поможет определить приоритеты исправлений.
Документация по API: Какие существуют конечные точки? Как устроен маршрутизатор tRPC? Это влияет на то, как мы подходим к исправлению ошибок.

6. Оценка времени

Реалистичный сценарий (4-6 недель):
Предполагается, что кодовая база достаточно хорошо структурирована и утверждение о “завершении на 90%” имеет некоторую обоснованность. Это включает в себя 1 неделю на анализ кодовой базы, 2-3 недели на исправление ошибок и недостающих функций и 1-2 недели на тестирование и доработку.

Пессимистичный сценарий (8-12 недель):
Если мы обнаружим значительные архитектурные проблемы, низкое качество кода или неполные реализации, требующие существенной доработки. Это может произойти, если предыдущий разработчик использовал упрощенные методы или если основные системы нуждаются в перестройке.

В лучшем случае (2-3 недели):
Это возможно только в том случае, если обнаруженные проблемы действительно являются ошибками поверхностного уровня в надежной реализации.

7. Дополнительные вопросы к Клиенту

Технический доступ:
Можете ли вы предоставить доступ к репозиторию GitHub? Если предыдущий разработчик отозвал доступ, есть ли у вас локальная копия кода? Как насчет учетных данных для доступа к базе данных?

Проверка текущего состояния:
Есть ли развернутая версия, которую мы можем протестировать прямо сейчас? Какие конкретные функции работают, а какие нет в текущей сборке?

Уточнение бизнес-требований:
Являются ли пороговые значения уровня (500, 1000, 2000 нажатий) и экономический баланс (1 монета за нажатие) фиксированными требованиями или они могут быть скорректированы в зависимости от потребностей технической реализации?

Ожидаемые сроки:
Какова ваша целевая дата запуска? Существуют ли какие-либо внешние зависимости (маркетинговые кампании, партнерские отношения), которые влияют на сроки?

Бюджет и устойчивость к рискам:
Готовы ли вы к тому, что некоторые функции, возможно, потребуется перестроить, а не исправить, что потенциально продлит сроки?

Что касается ссылки на Яндекс Диск: К сожалению, я не могу получить доступ к внешним файлообменникам, таким как Яндекс Диск. Если эти файлы содержат фактический исходный код или дополнительную техническую документацию, вам нужно будет загрузить их непосредственно в наш чат, чтобы я мог их проанализировать.

Ключевым моментом здесь является то, что, несмотря на то, что концепция проекта продумана и выбранные технологии соответствуют требованиям, успех завершения в значительной степени зависит от качества и полноты существующей кодовой базы, которую мы еще не изучали. Могли бы вы предоставить доступ к самому хранилищу кода или загрузить исходные файлы напрямую?

Claude ошибся?

Сначала подумал: может Клод ошибся? Ведь есть ссылка на репозиторий. Дай-ка я её проверю. Копирую ссылку, вставляю. Результат — ошибка 404. Страница не найдена.

Смотрю внимательнее на ссылку. Ай-да покинувший проект разработчик! Вроде бы предоставил ссылку на репозиторий. НО: ссылка на репозиторий в общем, имеет вид:

“https://github.com/yourusername/project_name.git”

где project_name — название реального проекта,
yourusername — имя владельца репозитория на Github.

Так вот: если имя стояло правильно, вместо реального имени разработчика так и оставлено: yourusername!

Вроде бы ссылка есть, но неработающая!

По невнимательности можно и не заметить. Так что, Клод не ошибся, говоря, что доступа к кодовой базе нет!