Опыт обучения школьников программированию

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

Но еще интереснее оказалась часть проекта, ориентированная на работу со школьниками. Я принимаю непосредственное участие именно в этой части, поэтому хочу рассказать о ней.

Проблема школьного обучения программированию

Почему нужно работать именно со школьниками? Мне кажется, что наибольшего успеха можно достичь, начиная обучать учеников 8-9 класса — в дальнейшем обучаемость снижается. Детей успевают «научить плохому» школьные учителя информатики, в том числе они часто отбивают интерес к программированию, в результате остаются только те, кто готов учиться «не благодаря, но вопреки» — те, кто в любом случае будут стремиться стать программистами, «технарями». Имеющие же меньшую тягу к этой области, но весьма способные ребята, к сожалению, отсеиваются уже на этом этапе.

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

Но программирование ведь нужно не только «избранным». На уроках программирования дети учатся в первую очередь работать с информацией, структурировать её, управлять ею, а эти навыки жизненно необходимы в условиях все нарастающего «информационного вала» современной жизни. Даже приблизительное понимание, как устроен компьютер, как он работает и исполняет программы, каковы его возможности и ограничения, — важный навык в нынешних условиях, когда компьютеры проникли буквально повсюду и все больше и больше становятся для обычного человека какой-то магией («я только кнопочку нажал, и тут тако-о-ое!!!»). Даже если ребенок и не станет программистом, приобретенные во время занятия программированием навыки будут для него хорошим подспорьем в будущей жизни. От компьютеров ведь он никуда не уйдет.

Методика И. Р. Дединского

Поиск методик преподавания, отличных от современных школьных шаблонов, вывел нас на замечательного, увлеченнейшего человека — Илью Рудольфовича Дединского. Он работает старшим преподавателем в московском Физтехе (МФТИ) плюс учителем в физматшколе, и добивается со школьниками потрясающих успехов — его ученики уже в 9-11 классе пишут программы, по сложности соответствующие 3-4 курсу технического вуза (!) — компиляторы, трехмерные движки, моделируют физические процессы, осознанно работая с проектами значительно большего объема, чем можно ожидать даже от студентов. Причем, что важно, Илья Рудольфович добивается таких результатов регулярно. Это не звезды, это обычные ученики (правда, из физматшколы). Как говорит он сам, «методику нужно судить по середнякам». «Звезды» будут всегда, отстающие, увы — тоже. Уровень же, достигнутый основной частью группы — вот истинный показатель качества применяемой методики и работы учителя.

Мне довелось встретиться с Ильей Рудольфовичем, пообщаться с ним лично, послушать рассказ о его методике «из первых рук». Взяв ее за основу, мы разработали собственный вариант его программы обучения, основанный на тех же принципах. К сожалению, использовать оригинальную методику Ильи Рудольфовича для нас очень сложно в силу нехватки педагогического опыта. Вполне вероятно, что мы пока не оценили всех её преимуществ и возможностей, поскольку Илья Рудольфович оттачивает свою программу обучения не один год. Полагаю, что с опытом придет понимание, что можно улучшить в нашей программе. Но, как вы понимаете, программа обучения — не та вещь, которую можно бездумно копировать, её нужно понять на собственном опыте. Ниже изложены принципы, которые положены в основу нашей программы обучения, как я их понимаю и применяю в своей практике (с оригинальным изложением принципов авторской методики вы можете ознакомиться на сайте И.Р. Дединского в разделе «Основные материалы»):

1. «Учить только хорошему». Дети должны сразу, с первого занятия видеть перед собой правильные, хорошие цели и правильные, хорошие примеры. Если не обратить внимания на какие-то вещи (например, форматирование кода), пустить их на самотек, дети сделают это так, как «поймут» сами. Впоследствии их придется переучивать, а это всегда намного менее продуктивно, чем учить правильно с самого начала. Поэтому на первом же занятии дети узнают, как правильно пользоваться пробелами и отступами, и почему важны пустые строки, разбивающие программу на логические фрагменты. С первых же занятий вводится понятие качества имен, и от детей требуется использовать понятные имена для переменных и функций.
2. «Учить программированию, а не языку». Все понятия, даваемые детям, выводятся как инструмент решения проблемы. Даже не совсем так: сначала формулируется проблема, дается возможность её «пощупать», попробовать решить имеющимися средствами (в качестве домашнего задания или вместе с преподавателем в классе). Например, мы умеем рисовать на экране домик (у нас уже есть такая функция). Давайте нарисуем на экране 5 домиков друг за другом. Задачу, безусловно, можно решить, вызвав функцию 5 раз. Но, проверяя технологию, мы задаем вопросы: а если надо будет 10 домиков? 50? 100? А если 4? А если столько, сколько поместится на экране? Или столько, сколько введет пользователь программы? Затем детям предлагается обсудить, как можно было бы решить эту проблему, и обычно они сами, с некоторой помощью преподавателя, формулируют с той или иной степенью приближения идею цикла. Лишь только затем рассказывается синтаксис оператора цикла в выбранном для обучения языке программирования.

Последовательность задач

Последовательность знаний и умений, получаемых детьми, ориентирована на их практическое использование. Как я уже писал выше, конструкции даются как результат возникающих у детей в процессе обучения проблем. Разумеется, задания подбираются именно так, чтобы проблемы эти возникали в определенном порядке — в этом состоит одна из задач преподавателя. Задачи подбираются по принципу: чем важнее навык, тем раньше он изучается. Важность понимается как частота употребления конструкции в промышленном коде. Именно поэтому функции, важнейший элемент программирования, изучаются как можно раньше.

Одна из проблем современного школьника, даже математически образованного, иллюзия компетентности в работе с компьютером (все знают, как скачать музыку или установить Skype) и одновременно страх и неуверенность перед программированием («это сложно, мне никогда не понять»). Поэтому для снятия этого страха на первом же занятии детям предлагается поиграть в деловую игру, которая на первый взгляд не имеет отношения ни к компьютерам, ни к программированию¹. В ходе игры участники воображают себя владельцами рекламного агентства, в которое приходит некий заказчик (преподаватель) и хочет заказать рекламный баннер. Но какой именно, не объясняет, ссылаясь на усталость, и предлагает задавать ему вопросы, из ответов на которые и будет составлен контракт. Такое вот завуалированное обсуждение ТЗ. На все вопросы о деньгах, установке баннера, разрешениях на установку и прочем успокаивает: «Это не проблема. Деньги есть, разрешения есть, не первый раз такую рекламу вешаем, рабочие уже вызваны». Подвох в том, что баннер нужен завтра, а его размер — 100 на 400 метров. Что же он с ним таким огромным будет делать?

Зачем нужен баннер (монолог вредного заказчика)

«Понимаете, я владелец крупной торговой сети «Чайник анлимитед». Мы продаем любую посуду — от коллекционных чашечек тончайшего фарфора до металлических чайничков. Вот недавно продали в Эмираты сервиз… миллионов за 50, из платины. Сейчас переговоры с Китаем на крупные поставки недорогой посуды. Так вот, я открываю магазин в вашем городе, и так получилось, что совершенно забыл про рекламу. Помощник заболел, а у меня из головы вылетело. Дату открытия сдвинуть не могу — все распланировано, заказано, будет ущерб для репутации… Я, честно говоря, сегодня с этим вопросом был у ваших конкурентов, мы много говорили, пили чай, все было очень мило, но… в последний момент они сказали, что у них какие-то сложности, и заказ они не возьмут. И я пришел к вам. В общем, нужен баннер. Хотя бы один. Я немного устал от разговора у ваших конкурентов, поэтому не хотел бы снова излагать детали заказа, и поэтому давайте так — если вы что-то хотите спросить или уточнить, то спрашивайте, и это и составит текст нашего договора.»

Далее следуют ответы заказчика на вопросы школьников, описание, что нужно изобразить и как и т.д. Тут-то дело и доходит до чертежа, размеров и сроков. Если игра происходит в Москве, то этот огромный баннер предлагается прилепить к стене небоскреба — так его будет издалека видно. В моем случае, за неимением небоскреба даже в проекте, пришлось прифантазировать аэростат, на котором реклама будет висеть над городом.

Кто же это сделает?

После неожиданных ответов о размерах и сроках этого у ребят наступает легкий шок. Это важный момент: они узнают, как существенно выяснить все детали до начала работы, даже если их не было в явном виде в задании. Фактически, это игровой тренинг на составление ТЗ. Когда эта фаза закончена, преподаватель «выкатывает на сцену» «секретное оружие» — выясняется, что у дизайнерской фирмы есть знакомый художник, который-таки может нарисовать требуемый баннер в срок. Но живет этот художник в дальней глуши, и единственный способ с ним связаться — позвонить по телефону. Тип он вредный, разговаривать с ним нужно аккуратно и точно, а то чуть услышит незнакомое слово — бросит трубку и придется звонить снова. Дальше идет список фраз, которыми с ним нужно разговаривать: установи холст, установи цвет, нарисуй линию и т.д. Фактически, так вводится абстрактный исполнитель («Тупой художник») и его система команд. Но не лишь формально, а с привязкой к ситуации, что воспринимается учениками гораздо более естественно.

Далее дети сообща «звонят» «тупому художнику» (роль которого играет преподаватель) и команда за командой управляют «художником», который выполняет их действия — ну или «обижается» на синтаксическую ошибку и бросает трубку, и тогда диалог начинается снова. По сути это исполнение первой программы на псевдокоде исполнителем в режиме интерпретации. После 4-5 неудачных попыток программа написана.

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

Включи библиотеку <em>(включи в свою голову знания из нее о том как рисовать)</em>

Главная работа
Начало
  Установи холст 100 400

  Установи цвет красный
  Линия 25 300 75 300
  Линия 25 300 50 100
  Линия 50 100 75 300

  Установи цвет зеленый
  Окружность 65 200 40

  Установи цвет синий
  Линия 40 180 20 80

  Вернуть результат
Конец

#include "TXLib.h"

int main()
{
  txCreateWindow(100, 400);
  
  txSetColor(TX_RED);
  txLine(25, 300, 75, 300);
  txLine(25, 300, 50, 100);
  txLine(50, 100, 75, 300);

  txSetColor(TX_GREEN);
  txCircle(65, 200, 40);
  
  txSetColor(TX_BLUE);
  txLine(40, 180, 20, 80);

  return 0;
}

Как уже говорилось, при записи этой программы особое внимание уделяется форматированию — пустым строкам, делящим программу на логические фрагменты, отступам и пробелам, позволяющим легко читать программу. В дальнейшем преподаватель придает этому очень большое значение и ворчит, пока ученик не оформит код должным образом: «Спрашиваешь, почему вот этот твой код не работает? Да кто ж его знает —в нем сходу не разберешься. Имена все однобуквенные, пробелов нет, отступы поставлены случайно… Сделай, чтобы программу было легко читать, тогда помогу найти ошибку».

Кратко о дальнейшем обучении

Домашним заданием после этого занятия является написание программы, рисующую несколько героев будущего мультфильма. Функция main сразу распухает до 50-100 строк, а у некоторых увлеченных учеников и больше. Поэтому на втором же занятии вводим понятие «функция» — пока без параметров, вида void DrawMan(),— и таким образом разбиваем программу на части. Для часто использующихся цветов вводим понятие «константа» и называем появляющиеся в программе константы понятным образом. Упор делается именно на понятность имен функций и констант. Фактически, это занятие о группировке кода и именовании.

Далее пробуем нарисовать один и тот же объект в разных местах экрана, разным цветом и т. д. Вводим понятие «функция с параметрами», добавляем в написанные на прошлом шаге функции параметры — это типичный рефакторинг. Упор делается на понятность имен, на «гибкость» получающейся функции и на взаимную независимость ее параметров.

После этого пробуем сделать анимацию — движущиеся объекты, простейший «мультик». Вводим понятие «цикл» (и здесь же локальные переменные). Опять упор на понятные имена переменных, на отступы в цикле. Пишем цикл, в котором рисуются персонажи мультика. Уже на этом этапе дети начинают рисовать достаточно сложные и эффектные сцены: например, у одного из моих учеников был нарисован домик, над которым «пролетало» солнце от восхода до заката, затем луна. Цвет всего рисунка менялся в зависимости от положения солнца (луны) на небе. Словами это описать непросто, но выглядело весьма эффектно.

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

Затем обсуждается возможность использовать написанный код повторно, для создания другого мультика с теми же персонажами. Вводится понятие «библиотека» (на этом этапе все складывается в один .h файл, раздельной компиляции не вводим, так как это весьма трудно для понимания всеми начинающими). Предлагается оформить функции в библиотеку, использовать её самим в программе, документировать, снабдить примерами работы с ней и дать пользоваться товарищам. Товарищи же, получив чужую библиотеку, пробуют её использовать и пишут рецензию, по итогам которой выпускается новая версия библиотеки (фактически, это выпуск SDK и peer review).

Развитие проекта превращает мультфильм в простую компьютерную игру (в нашем случае был выбран «Арканоид»). В процессе написания игры приходится иметь дело с функциями, меняющими состояние своих параметров, и, пользуясь этим, вводится понятие «указатель» и передача параметров по указателю. В нашем случае через некоторое время потребовались еще и массивы. (Важно: адресной арифметики здесь не даем.)

В процессе написания игры возникает необходимость обработать нажатия клавиш пользователем — появляется такая конструкция как «ветвление». В принципе, ветвление может появиться и раньше, но у меня необходимость в нем возникла только в этом месте. Сравните с классическим курсом, где if дается чуть ли не первым же оператором, а о функциях говорят ближе к концу, отчего ими пользуются мало, «развивая» в себе умение писать «макаронный» код. Позднее появление if вызвано спецификой выбранного проекта — «мультфильм», при другой последовательности учебных задач, оно может быть введено даже раньше цикла. Но в этом проекте движение (цикл) более актуально чем вариативность (ветвление) и работа условия в цикле более наглядна.

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

В дальнейшем дети узнают об указателях на функции, строках, классических алгоритмах, начинают знакомиться с синтаксическим разбором арифметических выражений. Но это уже очень большая и длинная история.

Итог

Я занимаюсь со школьниками по этой программе примерно один учебный год (с прошлого октября). Режим занятий — 2 раза в неделю, одно занятие — 3 академических часа (120 минут, включая десятиминутный перерыв). Группа разновозрастная, от 8 до 11 класса. Но результатом я могу гордиться — дети действительно научились решать задачи самостоятельно. Уверен, что мои ученики 8-9 класса школьные разделы по программированию 10-11 класса пройдут с легкостью. Последний раз, когда было дано задание написать программу «Угадай число» (компьютер загадывает, игрок угадывает по принципу «больше-меньше» — двоичный поиск) все справились с ней самостоятельно. Я просто ходил и наблюдал, как дети итеративно накручивают функционал — почти все начали с главной проверки (if на совпадение/больше/меньше), потом «обернули» её в цикл, потом начали добавлять «украшения». В результате, после нескольких замечаний, получился код, за который мне никак не стыдно. Разумеется, это далеко не самая сложная задача, которую ученики способны решить, но этот пример оказался для меня очень показательным, поскольку дал возможность увидеть самостоятельную работу с начала и до конца за один урок.

Могу сказать, что, по моему мнению, взятая нами за основу методика обучения И. Р. Дединского, — это большой прогресс в области обучения детей программированию. Она подводит базу под процесс обучения, позволяет систематизировать его, заинтересовать детей, показать им, что программирование — это очень интересно, позволяет дать детям больше знаний и навыков в области программирования, чем традиционная школьная программа. Но хочу отметить, что эта методика предъявляет немалые требования к преподавателю. Многие не всегда осознаваемые нюансы (например, выбор преподавателем чересчур абстрактного имени для функции или переменной ради сокращения записей, или введение глобальных переменных для «упрощения» объяснения работы функций) имеют далеко идущие неприятные последствия, которые нужно хорошо осознавать. Преподаватель должен обладать опытом практического программирования, чтобы внятно объяснить, почему нужно делать именно так, а не иначе, и очень желательно на примерах из практики (а не через запреты без объяснений). Он должен уметь быстро разбираться в коде учеников, оценить его состояние и последствия его развития, представить себе, мог ли подобный фрагмент кода быть использован в реальном проекте. Допустим, оставленная неинициализированной переменная: на учебной машине она не всегда приводит к ошибке, но при смене компилятора/версии компилятора/версии ОС/фазы луны может приводить к неопределенному поведению программы. Неудачные имена переменных, нарушение стиля: почему здесь все с большой буквы, а тут с маленькой? почему здесь «верблюжий» стиль, а здесь через подчеркивание? —вот некоторые из «мелочей», из которых складывается не только функционально рабочий, но и чистый, правильный, профессиональный код, и на это преподаватель должен обращать особое внимание. К сожалению, без практического опыта этот навык приобрести довольно сложно. Практический опыт, кроме того, хороший аргумент. При объяснениях я часто использую пример «… и улетели вы в отпуск на Таити. А тут — бац, ошибка в вашем модуле! Коллеги в панике, разобраться в вашем коде быстро не могут, вас срочно отзывают из отпуска —и вот вы прямо в пляжных шортах оказываетесь на рабочем месте». Немного преувеличено, конечно, но суть передает.

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

Ссылки

Сайт Ильи Рудольфовича
Библиотека TXLIb
Документация на TXLib
Презентация Дединского по методике преподавания (pdf)
Доклад Дединского «Аналитический подход к довузовскому преподаванию программирования»
Учебные программы (pdf)

Автор: Akela_wolf

Источник