Курс Java в МФТИ

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

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

Через две-три домашки мы на редкость задолбались и решили автоматизировать хотя бы проверки стиля и бизнес-логики. Готовые проверялки для ACM’ов или ШАДа на тот момент были малость сыроваты, но это лишь полбеды. Беда была в том, что они были ориентированы на засылку заданий в виде одного файлика, с последующей его компиляцией. А мы же ориентировались на более промышленный подход, с развесистой иерарией пакетов. Мы написали свою проверялку, которая чекаутила код из гитхаба и прогоняла по нему тесты «в закрытую». Мы обильно расписали тест-кейсы, Митя настаивал на проверке каждого штриха.

В итоге, получилось так, что тест-кейсы были сформулированы лучше, чем задания. Некоторые вещи, которые были описаны в них, не были однозначно указаны в задании. Особенно болезненно это отзывалось при тестировании самописных CLI и сетевого транспорта. Студенты, много раз обжегшись на подвохах задания, перешли к вырожденной форме TDD — написал что-то, запушил, посмотрел результат теста, переписал. В итоге, один из них написал эксплоит, который выкачал все исходники тестов с проверяющей машины, и на этом идея закрытых тестов кончилась.

В своем третьем курсе я пришел к тому, что самым удобным и полезным для проверки вариантом будет комбинация дотошной ручной проверки и мягкого автоматизированного тестирования. В этом году мы написали поверхностные юнит-тесты и поставляли их вместе с заданием. Там же запускалась проверка стилей и пр. Юнит-тесты студенты могли запустить локально, а после пуша они еще раз проверялись в Travis, так что преподаватель мог сразу их видеть. После того, как все функциональные тесты пройдены, решения проходили через ручную проверку. Проверялась архитектура, популярные ошибки, самописные велосипеды и пр. После мучительной сдачи нескольких заданий стиль кодирования большинства студентов менялся с «ночного кошмара теоретика» на «pet project ленивого программиста», что для 18-летних ребяток неплохо.

Я чувствую, что практически не раскрыл темы. Вероятно, однажды я еще к ней вернусь.