ЯдроКодаподготовка к экзаменам
Учебная платформа

Загружаем материалы

Подготавливаем материалы и навигацию по разделу.

Мини-проект на Python: дневник оценок

Автор: · Обновлено

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

Ядро проекта

def summarize(scores):
    if not scores:
        return None

    average = sum(scores) / len(scores)
    return {
        'average': average,
        'best': max(scores),
        'worst': min(scores),
        'fives': scores.count(5),
    }


scores = list(map(int, '5 4 3 5'.split()))
summary = summarize(scores)

if summary is None:
    print('Нет оценок')
else:
    print(f"Средний балл: {summary['average']:.2f}")
    print('Лучшая:', summary['best'])
    print('Пятёрок:', summary['fives'])

Ожидаются средний балл 4.25, лучшая оценка 5 и две пятёрки. Пустой список обрабатывается до деления.

Валидация до расчёта

Оценка должна находиться от 2 до 5. После чтения проверьте all(2 <= score <= 5 for score in scores). Неверные данные нельзя тихо включать в среднее. Функция summarize принимает уже проверенный список — так у каждой части одна ответственность.

Итерация проекта

Добавьте ввод пользователя, сообщение о худшей оценке и рекомендацию: при среднем не меньше 4.5 — «отличный результат», иначе — «есть что улучшить». Напишите assert для пустого списка, одной оценки и набора 5 4 3 5. Затем сохраните отчёт в файл только после успешной проверки данных. Не пытайтесь сразу строить меню: сначала добейтесь надёжности одной операции.

Следующая версия дневника

Разделите проект на функции parse_scores, validate_scores, summarize и format_report. Для каждой задайте вход, выход и по два теста. Добавьте сохранение отчёта только после успешной валидации и не позволяйте функции расчёта читать input самостоятельно. Затем реализуйте повторный запуск с новым набором, проверяя отсутствие старого состояния. В журнале изменений зафиксируйте первую рабочую версию до расширения. Если новая функция ломает тест, исправляйте её локально. Проект становится ценным не от количества меню, а от ясных границ компонентов, корректных данных и воспроизводимых проверок.

Практикум: дневник оценок с критериями приёмки

Разделите проект на parse_scores, validate_scores, summarize и format_report. Для каждой функции запишите вход, выход и по два теста. Требования: оценки от 2 до 5, пустой список не делится на ноль, среднее выводится с двумя знаками, число пятёрок корректно при повторах. Сначала получите отчёт для 5 4 3 5, затем добавьте чтение и сохранение в файл. Повторный запуск с новым набором не должен использовать старое состояние. Фиксируйте изменения маленькими проверяемыми шагами.

Контрольная точка

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

Частые вопросы

Почему проект не стоит начинать с меню?

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

Источники