За время своей практики – и как программиста, и как преподавателя – я выявил
три значительные методические ошибки, которые возникают при обучении детей программированию в самых разных образовательных кружках, школах и сервисах.
Вот они – сначала коротко, а потом подробнее.
1.
Объясняются отдельные команды и синтаксис программы, а не её функционирование в целом.
2.
Объясняется управление «абстрактным исполнителем» типа черепашки Лого.
3.
Вместо программирования объясняется, как создавать анимационные истории
Ошибка 1: объяснение отдельных команд и операторов
Как выглядит?
Уроки при обучении посвящаются той или иной команде или оператору. Например, сегодня мы изучаем «цикл». Завтра – «условие». Послезавтра – «цикл с постусловием». Далее – «блок «движение к точке» и так далее.
В чем тут проблема?
Это похоже на ситуацию с английским языком. Известно, что в школе ему учат 10 лет, но, тем не менее, большинство выпускников не в состоянии поддержать элементарную беседу. С другой стороны, на хороших курсах студенты начинают говорить уже после 3 месяцев обучения.
Связано это с тем, что мозгу нужно сразу учиться употреблять изучаемые элементы в конкретных ситуациях. «Играть» с ними, проверять, как они работают – пусть даже с небольшими «шероховатостями». Изучение «от самых основ» только теоретически даёт полное понимание происходящего, на практике же мы скорее получаем учеников, которые боятся составить слова в предложения (в случае английского) или же операторы в программу (в случае программирования).
Почему так сложилось?
Тому есть несколько причин:
Во-первых, исторически образование ведет свои основы от обучения ремеслу. Никогда подмастерье не давали в руки сразу большую работу – он всегда сначала тренировался на дешевых «болванчиках», от самых малых элементов. Давать полноценную работу в руки было слишком расточительным расходом материала. Но ситуация, как мы понимаем, поменялась – тем более, если дело касается программирования. Люди, знающие принципы в целом, значительно нужнее, чем понимающие в деталях отдельные выражения – тем более, что тренировка по программированию не расходует физические материалы.
Во-вторых, так проще «среднему» преподавателю. Куда как проще формировать план занятий – для этого просто достаточно разбить изучаемые объект на элементы, и давать их простейшие определения. И «полученные знания» легко проверить – достаточно сделать тест с вопросом на определение «цикла с постусловием». Все довольны, знания получены... только вот на практике воспользоваться ими нельзя.
Что делать?
Искать тех, кто дает комплексные знания, объясняя принципы программирования на практике, от целого. В
нашей программе, например, за один модуль мы создаем пусть небольшую, но полноценную игру, в которой все элементы программы служат достижению общей цели. Мы просто показываем, как они используются.
Ошибка 2: метод «абстрактного исполнителя»
Как выглядит?
В ряде программных курсов можно заметить, что берется некий «исполнитель» и ученик должен запрограммировать его поведение. Например: «пройти шаг», «повернуть влево», «поднять перо» и пр.
В чем тут проблема?
Современное программирование ушло очень далеко от «управления исполнителем». Оно может быть очень разнообразным – посвященным управлению данными (Machine Learning и пр.), управлению объектами (MVC, программирование игр и пр.) и т.д. Но концепция «исполнителя» на практике встречается крайне редко и не даёт реального ощущения того, что программирование на самом деле может.
Проблемой является то, что при формировании уроков на базе концепта «универсального исполнителя»:
- Дается значительно более скучный концепт, который не мотивирует, не заинтересовывает ребенка
- Даются слишком базовые понятия, на основании которых сложно перейти к реальному программированию
Почему так сложилось?
Тут тоже есть две исторические причины:
Во-первых, одно из традиционных определений программирования звучит в духе «программа (алгоритм) есть набор однозначных команд, отдаваемых исполнителю/интерпретатору» Безусловно, формально это определение верно – и множество традиционных методов, сформировавшихся во времена, когда компьютеров на всех не хватало, а дети «программировали» на кусочках бумаги, упирали именно на то, что надо дать понять детям, что такое «формальная команда» (а не неформальная).
Во-вторых, методики обучения программированию сложились в 90-е годы, когда компьютеры обладали низкой производительностью, и в лучшем случае позволяли детям запустить среду «Лого». Собственно, оттуда и сформировалась целая серия методик – взять «черепашку Лого», повернуть её влево, вправо и т.д.
Современные компьютеры позволяют же запускать среды типа Scratch – с возможностью программировать сразу несколько объектов, передавать между ними сообщения, менять внешний вид, отслеживать столкновения, менять графику и звук... Мы считаем, что методика обучения должна значительно поменяться – идея о том, что «команда должна однозначно пониматься» в большинстве случаев ученикам сейчас очевидна.
Что делать?
Посмотреть программу занятий (
вот наша) и убедиться, что «черепашкой» занимаются не больше
1–2 модулей (месяц, максимум – два).
Честно говоря, «черепашка» может быть неплохим инструментом для первоначального освоения учениками синтаксиса, например, в Python, да и интересные методические наработки для неё есть. Но если ей занимаются долго – что-то явно не то.
Ошибка 3: анимации вместо программирования
Как выглядит?
Вы замечаете, что ребенок с курсов постоянно приносит анимационные истории про тех или иных персонажей, занимается созданием картинок к историям. Но при этом нельзя сказать, что его программа содержит какие-то интерактивные элементы (кнопки, возможности выбора, управление мышью) и/или цели, как в игре (собрать сколько-то элементов для выигрыша и т.д.)
В чем тут проблема?
Уметь создавать истории и рисовать не означает уметь программировать. Надо сказать, что ребенка увлекает то, что ему показывают – и создание анимаций, в общем-то, это неплохая и часто даже воодушевляющая ребенка задача.
Но
проблема заключается в том, что в этом случае чаще всего ребенок начинает использовать не самые удобные средства. Для создания анимаций (мы не говорим о таком редком направлении, как генеративная графика) лучше использовать специализированные инструменты рисования и анимации типа Flash и других профессиональных редакторов. Для программирования же умение создавать инструкции в духе «иди туда; постой две секунды; произнеси фразу» не является столь важным. Да, возможно, оно выглядит даже в меру интересно – но это не программирование, это создание историй с помощью систем команд.
Ситуация схожа с ошибкой 2 – по сути, в данном случае происходит обучение не программированию, а командам для управления отдельными объектами.
Почему так сложилось?
Причины похожи на причины предыдущей ошибки:
Во-первых, исторический фактор. Это то, что можно было легко делать на поколении машин в 90-е годы.
Во-вторых, данный подход хорошо ложится на продолжение концепции «универсального исполнителя» – мы детально указываем команды для поведения отдельных объектов (заметим: не для их взаимодействия, и не для взаимодействия их с пользователем).
В-третьих, так проще «среднему» преподавателю. Почти при любом варианте занятия ребенок с интересом будет занят рисованием и анимированием объектов на сцене. Урок пройдет, ребенок «чему-то научится». Немного людей заметит, что, вообще говоря, это «не совсем» программирование.
В-четвертых, к сожалению, анимационные ролики очень легко делать творческими проектами и очень легко их презентовать. Вроде как сразу видно, чем ребенок был занят и на что потратил время.
Что делать?
Посмотреть программу занятий и убедиться, что созданием анимаций занимаются не больше
1–2 модулей. В принципе, само по себе это не так страшно и даже интересно – например, в
нашей программе мы занимаемся созданием достаточно длинной 1.5-минутной истории в 5 модуле. НО! Мы заодно узнаем, как «отлаживать» подобные длинные цепочки команд с помощью сообщений.
Да, лучше посматривать, что делают на занятии и что делает ваш ребенок. Хорошо, если он занимается чем-то интерактивным
– т.е. взаимодействующим с пользователем – требующем ввода с клавиатуры или управлением мышью. Должна немного насторожить ситуация, когда ребенок постоянно рисует или анимирует. Кстати, у нас большая часть модулей посвящена именно интерактивным программам.
Заключение
В кинофильме «Ирония судьбы» был замечательный диалог:
— Ошибки врачей дорого обходятся людям.
— Да. Ошибки учителей не столь заметны, но в конечном счете они обходятся не менее дорого.
Ошибок, связанных с обучением, много. Невнимание к интересу ребенка. Слишком большое внимание к деталям. Обучение не тому, что нужно, а тому, что привычно.
Очень надеюсь, что благодаря этой статье Вам удастся найти хорошие курсы, а Вашим детям – избежать учительских ошибок.
Владислав Январев, автор курсов Goto2050
24 марта 2020 г.