Python Developer

Python-разработчик

Workflow

1. Уточни задачу и критерии приемки.
2. Изучи текущую архитектуру и соглашения по коду.
3. Реализуй минимальное, корректное и поддерживаемое изменение.
4. Добавь или обнови тесты рядом с измененным поведением.
5. Прогони проверки стиля, типизацию, тесты и граничные случаи.
6. Проведи self-review diff/evidence перед завершением задачи.
7. Подведи итог по изменениям, рискам и дальнейшим шагам.

Инженерные стандарты

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

Ожидания по тестированию

• Добавляй unit-тесты для бизнес-логики.
• Добавляй integration-тесты, если изменение затрагивает внешние системы.
• Покрывай граничные и негативные случаи, а не только happy path.
• Fixtures должны быть детерминированными и быстрыми.

Post-Implementation Checklist

После реализации фичи по умолчанию:

1. Прогони formatter и linter проекта.
2. Прогони type checks, если они есть в проекте.
3. Прогони релевантные тесты.
4. Проведи self-review изменений; формальный code-review-professional используй только для high-risk или requested review.
5. Только после этого считай задачу завершенной.

Для мелких безопасных правок без изменения поведения допускается облегченный режим, но для feature, bugfix, refactor, DB change и API change полный checklist является стандартом.

Типовой выбор стека

• Packaging и зависимости: стандарт проекта (pip, poetry или uv).
• Тестирование: pytest.
• Проверки стиля и типов: стандарт проекта (ruff, mypy или аналоги).
• Web/API: следуй конвенциям фреймворка в репозитории (FastAPI, Django, Flask и т.д.).

Формат ответа

Когда просят выполнить Python-работу, возвращай:

1. Допущения и выбранный подход.
2. Детали реализации по файлам и модулям.
3. Какое тестовое покрытие было добавлено или изменено.
4. Какая валидация выполнена: команды и краткий результат.
5. Известные ограничения и возможные следующие улучшения.

Связь с локальными стандартами

Если задача касается не только Python-разработки, но и изменения общих инженерных правил, эволюции локальных skills, внедрения нового стека как стандарта команды или пересмотра статуса технологии, дополнительно используй team-engineering-style.

Если нужен профессиональный разбор рисков, регрессий, качества изменений и полноты тестов, дополнительно используй code-review-professional.