Оценивание кода и программных работ

Оценивание кода и программных работ

В коде легко оценить только «работает или нет». Но качество включает читаемость, тесты и документацию: с таким кодом сможет работать другой человек. Проверка должна занимать предсказуемое время и не зависеть от привычек преподавателя. Ниже — как выстроить критерии.

Что оценивать в коде

Работа программы, читаемость, тесты, документация. Отдельно — понимание решения. Оценка должна отражать качество кода, а не совпадение с привычным стилем преподавателя.

Работа программы

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

Читаемость

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

Тесты

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

Документация

Короткий файл: что делает, как запустить, какие зависимости, что ожидать. Проверьте, что инструкция работает. Ограничьте объём одной страницей. Это часть работы, а не дополнение.

Понимание

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

Стиль

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

Групповая работа

Опишите, кто что сделал. Проверьте вклад по истории изменений или по краткому описанию. Не оценивайте всех одинаково. Зафиксируйте роли заранее.

Типичные ошибки

Оценивать только «работает или нет», требовать идеального покрытия тестами, снижать за стиль без предупреждения, не проверять инструкцию, не задавать вопросов о решении. Каждая ошибка искажает оценку.

Безопасность

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

Как учить

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

Инструменты

Если используете автоматическую проверку, опишите правила. Не полагайтесь только на неё: тесты можно обойти. Сочетайте с разговором о решении.

Обратная связь

Укажите конкретную строку и предложение. Не пишите «плохо». Отметьте, что сделано хорошо. Это влияет на следующую работу сильнее, чем балл.

Доступность

Уточните, какое оборудование нужно. Дайте альтернативу, если у студента нет нужной среды. Проверьте, что задание выполнимо за отведённое время.

Как проверить

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

Хранение

Сохраняйте работы и комментарии. Укажите срок. Не публикуйте код студентов без согласия. Используйте примеры для обучения обезличенно.

Итог

Код оценивают по работе программы, читаемости, тестам и документации, с проверкой понимания. Инструкция запуска — часть работы.

Как оценивать чужой код

Попросите студента прочитать фрагмент незнакомого кода и объяснить, что он делает. Это проверяет навык, который нужен в работе. Оценивайте по критериям понимания, заранее описанным. Не превращайте в проверку памяти.

Как поступить с заимствованным кодом

Уточните правила использования готовых библиотек и фрагментов из сети. Если разрешено, требуйте указания источника. Если нет — проверьте понимание. Решение принимайте по фактам, а не по стилю.

Как связать с курсом

Задание должно опираться на материал. Проверьте, что студенты знают нужные конструкции. Если нет, дайте короткую справку. Не оценивайте то, чему не учили.

Как работать с медленной проверкой

Ограничьте объём кода: одна-две функции или небольшой проект. Задайте шаблон структуры. Проверяйте в одинаковом порядке: запуск, читаемость, тесты, разговор. Это экономит время.

Как связать с практикой

Попросите студента описать, как он проверял программу. Спросите, какие случаи не покрыты. Это показывает зрелость подхода. Учтите в критерии «тесты».

Как оценивать командную разработку

Уточните, кто отвечает за какой модуль. Проверьте вклад по истории изменений или краткому описанию. Оценивайте и общий результат, и личную часть. Зафиксируйте веса заранее.

Как работать с чужими библиотеками

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

Чек-лист

• Запуск проверен.
• Граничные случаи проверены.
• Читаемость оценена.
• Тесты учтены.
• Документация проверена.
• Понимание проверено.
• Стиль объявлен заранее.

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

Нужны ли тесты?

Да, хотя бы для ключевых сценариев.

Оценивать ли стиль?

Только если требования известны заранее.

Что важнее всего?

Работа на нескольких наборах и понимание решения.

Пример

Студент сдал программу, которая работала на его данных и падала на пустом файле. На вопрос о структуре он ответить не смог. После введения требования инструкции и проверки на трёх наборах работы стали устойчивее, а разговоры о «непонятных» оценках прекратились.

Итог

Код оценивают по работе на разных данных, читаемости, тестам и документации, а понимание проверяют разговором.