Обучение программированию 2019, или в поисках идеальной программы: Последовательность

    МУРОМ


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


    Предисловие


    Осенью 2019-го я в третий раз участвовал в курсе обучения ребят 10-15 лет программированию в качестве одного из преподавателей. Наши курсы проходили с середины сентября по середину декабря. Каждое занятие было в субботу с 10:00 до 12:00. Подробнее о структуре каждого урока и деталях создаваемой на курсе игры можно узнать из статьи за 2018-й год.


    Лично для себя я выделил две основные цели, к которым иду с помощью курсов:


    • создать удобный инструмент для создания простейших игр, понятный заинтересованным людям в возрасте от 10 лет;
    • создать программу обучения программированию, позволяющая заинтересованным людям в возрасте от 10 лет самостоятельно делать простейшие игры.

    Игра


    Игра


    Простейшей игрой уже второй раз является игра на память, суть которой в поиске совпадающих элементов на игровом поле. Детально механика игры разобрана в статье за 2018-й год. Поиграть в созданную на курсе игру вы можете прямо из браузера по этой ссылке.


    Инструмент


    Среда


    Основным критерием при создании инструмента для меня являлась неприхотливость, выражающаяся в следующем:


    1. работает на любой операционной системе
      • разработка на Linux, macOS, Windows
      • воспроизведение результата на ПК, планшете и мобилках
    2. не нужно ничего настраивать: открыл ссылку в браузере и начал работу
    3. фактически не нужен интернет: можно работать локально, т.к. нет какого-либо сервера на стороне
    4. результат доступен всем
      • если положить на GitHub Pages, то достаточно дать ссылку
      • если кинуть файл по Skype, то его можно открыть локально

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


    1. слева находится панель кода выбранного модуля;
    2. посередине — панель с кнопками перезапуска, сохранения результата и управления модулями;
    3. в правом верхнем углу — результат;
    4. в правом нижнем углу — список всех модулей: как относящихся к ИСР, так и созданных для игры.

    Ввиду того, что у нас лишь один файл, нам нужно уметь запускать его в двух режимах:


    1. воспроизведение
      • является режимом по умолчанию
      • достаточно просто открыть файл HTML
    2. редактирование
      • доступно при добавлении символов ?0 в адресной строке

    Временное хранение изменений осуществляется с помощью хранилища браузера (IndexedDB). Для сохранения изменений на постоянной основе, например, для публикации, необходимо скачать этот же самый файл с изменениями, нажав на соответствующую кнопку в средней панели.


    Первые занятия


    Для первого занятия я подготовил 80 строк кода на JavaScript, распечатал их и раздал каждому. Каждый ученик должен был набрать распечатанный код в инструменте. Набором кода я преследовал две цели:


    1. узнать скорость набора текста учениками;
    2. показать API инструмента.

    Скорость набора оказалась чрезвычайно низкой: от примерно 14 символов в минуту (ученик успел набрать лишь половину) до примерно 39 символов в минуту. Сам я этот код набирал со скоростью 213 символов в минуту, поэтому от результатов учеников опешил: у меня появилось подозрение, что написать необходимые 300 строк игры за 1 час мы к концу курса не осилим физически.


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


    Can't unsee


    С третьего по шестое занятия я уменьшал код вплоть до 10 строк, выдавал инструмент уже с частично набранным кодом, в котором нужно было найти и исправить ошибки. Ничего не помогало: ученики просто не воспринимали написанное, как-будто вместо чего-то членораздельного на экране видели иероглифы.


    Успешное седьмое занятие


    Прошло уже больше половины курса, а я не продвинулся ни на йоту. В очередной попытке найти хоть какой-то способ объяснить код игры я ещё раз переписал игру. На этот раз с модулем под интригующим названием последовательность.
    К моему удивлению, на занятии был оглушительный успех: мы успели до "звонка", и ребята буквально горели энтузиазмом. Горели настолько, что устроили под конец занятия мозговой штурм о том, чего бы ещё добавить в появившуюся в ходе занятия игру:


    Мозговой штурм


    Итак, давайте разберём это занятие подробнее.


    Доска


    Предыдущие занятия у нас строились в формате "преподаватели подходят к каждому ученику и помогают ему индивидуально". За шесть занятий мы — два преподавателя — осознали, что подход к каждому и погружение в частные опечатки/ошибки занимает времени больше, чем объяснение нового материала.


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


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

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


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

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


    Модуль последовательность для игры на память выглядит следующим образом:


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


    Последовательность позволяет записать алгоритм в виде событий и реакций:


    • события (начало, выбор и т.д.) расположены без отступа слева;
    • реакции (настроить ThreeJS, показать заставку) расположены под соответствующими событиями с отступом.

    Таким образом, при запуске игры (событие начало) мы настраиваем ThreeJS (реакция настроить ThreeJS), показываем заставку (реакция показать заставку) и т.д.


    Занятие мы начинали с практически пустым модулем последовательность, присутствовали заранее лишь события без реакций:


    События


    Эти же события я выписал на доске, оставив свободное место для записи реакций (замазано уже в GIMP для удобства иллюстрации):


    События на доске


    Реакции мы искали в модуле память.реакции:


    Реакции


    Каждая реакция модуля последовательность представлена в модуле память.реакции функцией-конструктором. Например, реакции проверить окончание однозначно соответствует функция ПроверитьОкончание:


    function ПроверитьОкончание(мир) // 1.
    {
        мир.состояние["скрыто сфер"] = 0; // 2.
        this.исполнить = function() // 3.
        {
            мир.состояние["скрыто сфер"] += 2; // 4.
            var скрыто = мир.состояние["скрыто сфер"]; // 5.
            var сфер = мир.состояние["сферы"].length; // 6.
            if (сфер == скрыто) // 7.
            {
                мир.события["конец"].уведомить(); // 8.
            }
        };
    }

    Рассмотрим эту функцию подробнее:


    1. Функция принимает на вход мир (словарь), используемый для общения функций друг с другом. мир состоит из трёх областей (ключей словаря):
      • состояние содержит переменные значения для обмена данными;
      • настройки содержат константные значения для настройки функций;
      • события содержат издателей для организации возможности подписать функции на события.
    2. Экземпляр функции-конструктора создаётся оператором new при разборе модуля последовательность. Фактически всё, что не входит в метод исполнить, является телом конструктора. В частности, здесь мы создаём переменную скрыто сфер для учёта количества скрытых сфер.
    3. Метод исполнить вызывается на каждое уведомление о событии.
    4. Т.к. реакцию проверить окончание вызывают на событие сокрытия пары сфер, то счётчик скрыто сфер увеличиваем на 2.
    5. Просто задаём короткий псевдоним для счётчика скрыто сфер.
    6. Получаем общее количество сфер на игровом поле.
    7. Сравниваем количество скрытых сфер с общим их количеством.
    8. Если они равны, т.е. все сферы скрыты, уведомляем о завершении игры с помощью события конец.

    Поиск функций в модуле память.реакции ученики осуществляли по очереди:


    • ученик ищет функцию в модуле (для упрощения я разделил функции символами // // // //);
    • при нахождении озвучивает название функции и выходит к доске;
    • на доске пишет название функции в общий список найденных функций (допускается пользоваться любыми средствами для запоминания названия, кроме подсказки преподавателя).

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


    После выписывания названий всех функций на доску мы сопоставляли события с реакциями (функциями) схожим образом:


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

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


    Последовательность на доске
    Функции на доске


    так и в инструменте:


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


    Следующие занятия


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


    var кот = "9";
    console.log(кот);

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


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


    Последнее занятие


    На последнем занятии вместо стандартного круга приветствия я попросил каждого (включая себя) высказаться, что понравилось в курсе (+), а что стоит изменить (-). Получилась следующая таблица:


    Ретро


    Как ни странно, ребятам не нравилось писать на доске, несмотря на то, что она увеличивала эффективность изложения материала. С одной стороны, была "объёмная программа", а с другой — "одно и то же каждый урок", т.е. повторение пройденного ранее материала.


    Раз в несколько занятий мы сохраняли результат на GitHub. Давалось это тоже нелегко: мы тратили до получаса на то, чтобы каждый вошёл в свою учётную запись. Как всегда, никто не помнил свой пароль (причём каждый раз) либо для подтверждения захода с нового устройства требовался доступ к почте, пароль от которой либо тоже никто не помнил, либо почта была родительская (ребята звонили родителям).


    Так или иначе, у каждого ученика к концу курса осталась собственная версия игры с персональными заставкой и концовкой:


    Адрес


    Выводы


    С одной стороны, были явные успехи:


    • инструмент оказался неприхотливым и полностью работоспособным;
    • концепция последовательностей была хорошо принята.

    С другой стороны, были явные неудачи:


    • инструмент предполагает навык работы с JavaScript, чем ученики не обладали;
    • программа обучения буксовала практически все занятия.

    Поэтому в ходе курса обучения программированию 2020-го года я попробую ответить на следующие вопросы:


    1. Будет ли другой язык (Python, Lua) проще для объяснения и работы?
    2. Можно ли скрыть работу с Git внутри инструмента, чтобы сохранять результат на Git, не покидая инструмента?
    3. Можно ли сделать декларативный API по аналогии со SwiftUI?
    4. Как всё-таки объяснить переменные и массивы?

    Ответы на эти и другие вопросы будут через год ;)


    Группа


    PS English version is available here.

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 23

      +1

      Сегодня отчётливо понимаешь, почему в школах и университетах программирование стартует с древних бейсиков и паскалей, а не с более современных языков. И если раньше я думал, почему мы учимся на таком старье (в школе это были БК, в универе — 386-ые), то сегодня опять же понимаешь, что чем проще — тем лучше для обучения

        0
        Переменные и массивы, на мой взгляд, объяснить довольно просто. Переменные — ящичек, куда мы что-либо кладем и потом достаём, например. Массивы — ряд из ящичков одного типа. Важно заинтересовать этими самыми ящичками и рядами и уметь удерживать внимание такой аудитории. «Лиха беда начало», а так — всё получится! Успехов!
          +2

          Пробовал объяснять с помощью ящиков, но не видел понимания.
          Пробовал показывать стакан с разными ручками, тоже не сработало.
          Тут нужно что-то другое :)
          Спасибо.

            +2

            Абстракция "на ящичках" ломается вот таким примером:


            int a = 0, b = 3, c = 5;
            a = b;
            c = b;
            Console.Write(c);

            Если мы "вытащили" число из b и положили это число в a, то что случилось во второй команде?

              0
              Флэшки и файлы на них? Или уже поздно и мало кто из школьников понимает, что такое флэшка?
                0

                Интересный пример. Попробую его. Спасибо.

              +2
              Переменные и массивы, на мой взгляд, объяснить довольно просто. Переменные — ящичек, куда мы


              У меня нет опыта преподавания, если не считать объяснения домашних заданий одноклассникам, лабораторных однокурсникам и объяснения всего остального, программирования в том числе, своему ребенку, поэтому мой подход возможно не всегда и не везде работает, но. Я считаю, что в таких объяснениях важнее не принципы и аналогии (ящички, карманы, ряд ящиков и т.д.), а проблемы которые решаются с помощью тех конструкций, которые надо объяснить. То есть идти от задачи. Я не помню точно с помощью какой аналогии я объяснял смысл переменной, кажется говорил как раз про коробку или ящик, но зато лучше помню как я объяснял необходимость переменной. Мы написали программу печатающую «Привет, Миша! Как дела». Чтобы программа могла потом напечатать «Привет, Маша! Как дела?» или «Привет, Петя… » можно переписать cтрочку в коде. И мы так сделали несколько раз. А можно передавать имя в программу. И вот это имя надо где-то хранить. И для хранения нужны переменные. Похожим образом показал пользу от циклов, которые позволяют не писать двадцать раз почти одинаковый код, рисующий картинку на экране (но сначала эти двадцать строчек все же написать и потом еще отредактировать, и ошибиться специально в паре мест) и так далее.

              С программированием, правда, все эти объяснения пока на уровне пролета из одного уха в другое. Ребенок маленький еще и сам писать не пытается, только терзает вопросами, через плечо смотрит и говорит мне что делать (наверное у меня растет не программист а ПМ). Но с арифметикой я стараюсь использовать такой же подход и мне кажется, что это работает. Например, сложение в столбик получилось объяснить очень быстро потому что сначала у нас было много примеров на сложение двузначных чисел, которые сын пытался делать в уме и на пальцах. После этого смысл и польза столбика были очевидны. Мне кажется, если бы я сначала стал объяснять сам прием, то он бы спросил «а зачем? большие числа складывать? а это точно надо? никто ведь не просит пока»
                +1
                Ваш подход очень эффективный! На мой взгляд, самое важное, что ребенку становится интересно! Вы показываете, рассказываете что-то, ребенок начинает это повторять. Это самое важное — заразить интересом. Все остальное — дело наживное. Я думаю, за годы такого вот «хобби» вырастет отличный программист.
                  0

                  Т.е. вы говорите о том, что нужно ученика научить его собственным опытом, чтобы он понял. Очень интересно, попробую. Спасибо.

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

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


                На мой взгляд, не нужно сразу бросаться на помощь в поиске опечаток. Лучше по кусочкам дать эталон, а потом превращать поиск ошибок в игру "найди 10 отличий". Почему в этом месте ошибка, а в этом — все работало?


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


                Я однажды присутствовал на занятии, где преподаватель вызвал ученика к доске и пытался вытянуть из него ответ. Со стороны выглядело как пытка из анекдота про эзотериков и диффуры


                18+

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


                Содержание курсов напомнило рисование совы.


                той самой

                image


                Сложилось впечатление, что автору было интереснее делать IDE с вышеописанными ограничениями, чем непосредственно учить.
                Это нашло отражение и в целях обучения:


                Лично для себя я выделил две основные цели, к которым иду с помощью курсов:
                • создать удобный инструмент для создания простейших игр, понятный заинтересованным людям в возрасте от 10 лет;
                • создать программу обучения программированию, позволяющая заинтересованным людям в возрасте от 10 лет самостоятельно делать простейшие игры.

                Вольно или невольно, но автор вообще не ставил целью научить детей чему-то.
                Да и вся статья не про "обучение", а про то, какая получилась IDE и какие возникали проблемы у ее пользователей.

                  0
                  Лучше по кусочкам дать эталон, а потом превращать поиск ошибок в игру "найди 10 отличий". Почему в этом месте ошибка, а в этом — все работало?

                  Попытки такие тоже были, но в ответ была лишь тишина, ибо ученики не умеют программировать, они не знают законы/принципы/правила.


                  Ученик может быть и пишет сам. Но это частенько превращается в "написал под диктовку".

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


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

                  Курс занимает в сумме 20 часов: 10 дней по 2 часа на урок. Причём в курс ещё вклиниваются пару недель, когда в выходные либо праздники, либо каникулы. Успеть что-то за 20 часов в принципе довольно сложно, а если уменьшить их ещё и переменками, то врядли выйдет толк. С другой стороны, если эти переменки плавно встроены в тему конкретного урока и усиливают его, то, может быть, в них будет толк. Спасибо за мысль, попробую пошерстить Интернет на этот счёт.


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

                  Учитель может помогать лишь через класс, а класс должен контролировать написанное на доске. Конкретно этот контроль работает на практики отлично, и вызывает немало смеха и положительных эмоций.


                  Непонятно зачем судить о внимательности. Какие конкретно следствия у того факта, что некоторый ученик забывает точки с запятыми?

                  Хороший вопрос, на который у меня пока нет ответа. Есть мысли, что усердность прямо пропорционально заинтересованности. Возможно, по оценке усердности есть смысл отсеивать перед началом курса.


                  Я однажды присутствовал на занятии, где преподаватель вызвал ученика к доске и пытался вытянуть из него ответ.

                  Насильно учителя не вызывали учеников, да и они сами не выходили, если не были уверены в себе. На практике либо кто-то в классе знает ответ, либо нет. Если нет, то… это как раз те случаи, когда объяснение не работает, поэтому я тут и пишу в попытке получить помощь :)


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

                  На самом деле, нет критерия "я научил учеников чему-то". Есть критерий "ученики более-менее самостоятельно могут использовать инструмент X для того, чтобы сделать Y". В прошлой статье за 2018-й год инструментом был Scratch, и игру ученики смоги сделать. В 2019-м году я попробовал свой инструмент, в котором я постарался убрать всё лишнее и мешаюшее процессу обучения вроде настройки окружения, установки зависимостей, сборки и т.п… Всё это получилось убрать, однако, в отличие от инструмента Scratch, где вместо языка программирования используются визуальные блоки, я хотел попробовать настоящее программирование на настоящем языке. Безусловно со своей архитектурой, т.к. эта архитектура тоже задумывалась как помощь.


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

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

                  Заставлять писать код ручками на доске — решение более чем спорное. У меня, например, без подсветки синтаксиса и автодополнения сразу -10 к интеллекту, что уж говорить про детей, которые только-только учатся.

                  Для первого занятия я подготовил 80 строк кода на JavaScript, распечатал их и раздал каждому. Каждый ученик должен был набрать распечатанный код в инструменте. Набором кода я преследовал две цели: узнать скорость набора текста учениками;

                  А это и вовсе какие-то дикие метрики. Набрать распечатанный код? Скорость набора? О_о

                  В общем, что-то подобное было у меня лет в 11 в школе с Паскалем — примерно такой же подход с доской и переписыванием кода, который я встретил стеной непонимания. Пришлось отложить обучение программированию на 5 лет, и только потом осознать, что вообще-то программирование это здорово и весело.
                    0

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

                    +1

                    Спасибо вам за статью. Сам занимаюсь преподаванием и немного затрагиваю программирование. Очень интересно читать как вы преподаёт и с какими трудностями сталкиваетесь.
                    Желаю успехов.

                      +2
                      Сам преподаю программирование в школе. Имею набитые болячки и натёртые мозоли.

                      Хотел ответить кратко, но это уже лонгрид. Может кому будет интересно.

                      Самая важная мысль: определитесь, вы хотите чему-то научить или заинтересовать? От ответа на этот вопрос зависит … всё! Это две совершенно разные цели с совершенно разными дорогами и сложностями.

                      Вы в статье часто употребляете слово «обучение», я исходил из этого.

                      Общие мысли.
                      Вы хотите за очень короткое время научить чему-то осознанному – это довольно трудная задача, причём здесь есть как минимум 3 больших подводных камня:
                      1) Вы пишете «дети 10-15 лет» — как раз в этом месте ОЧЕНЬ большая разница между детьми: и в восприятии материала, и в понимании, и в самостоятельности и тд.тп. (причём, это никак не исключает частного случая, что кто-то в 10 мыслит лучше, чем другой в 15. – но тогда нужен отбор или нечто подобное. Вести разноуровневую группу ещё более сложно.)

                      2) Цели и мотивация. Зачем они пришли к вам?
                      Опыт из жизни: однажды на кружок робототехники привели мальчика со словами «он бредит роботами, вы должны его взять». Взял. Действительно бредит. Рисует очень детальные красивейшие рисунки всевозможных роботов. Ни одной инженерной задачи в кружке не решил, но ходил долго и упорно.

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

                      3) Очень важно понимать, что за ограниченный срок у вас не получится научить всех. Будут откровенно тормознутые дети (даже среди тех кто пришёл осознанно!), которым вы можете хоть 100 раз разными словами объяснять – бесполезно. И тут важно соблюсти некую «общую скорость группы» чтобы те, кто идёт вперёд не сильно тормозили. А кого-то придётся тащить как бесполезный балласт.
                      Основное правило урока: каждый ребёнок должен быть занят делом. А задача препода создать массу различных дел в едином русле обучения, и выдавать их детям в зависимости от уровня и текущих успехов. Классические ситуации: очень трудная задача = нечего делать, очень лёгкая задача – лень = нечего делать. Лучше всего иметь отдельные задачки тем, кто бежит вперёд – посильнее и поинтереснее, а тем, кто отстаёт – попроще. Причём задачки могут быть и «в бок» — не в основном русле программы.

                      Ещё из общего: очень понимаю вас с созданием собственного инструмента без заморочек, так как нет ничего хуже, чем тратить время урока на решение технических проблем с компами и тдтп. Но есть и обратная сторона медали – какова для них ценность освоения именно этого инструмента? Вопрос, наверное, не первого плана, но он есть.

                      «Для первого занятия я подготовил 80 строк кода на JavaScript, распечатал их и раздал каждому. Каждый ученик должен был набрать распечатанный код в инструменте.»

                      Занятие, кажущееся полезным, но сталкивающееся с суровой реальностью: они НЕ набирают текст (в обычной жизни), соответственно не знакомы с этим _типом деятельности_. С поиском опечаток – тем более. Новый тип деятельности требует тренировки. Тренировки довольно быстро убивают современную мотивацию «хочу быстрый и яркий результат». Общие мысли тут простые: делим на мелкие куски, причём после каждого куска желателен визуальный результат – «конфетка». Тогда это более-менее сработает. Но и не перебарщивать в целом. Кому-то можно выдавать частично готовый код.

                      «За шесть занятий мы — два преподавателя — осознали, что подход к каждому и погружение в частные опечатки/ошибки занимает времени больше, чем объяснение нового материала.»


                      Тоже сталкиваемся с этими проблемами. Опечатки – это мелочи, по сравнению с логикой работы программы. Опечатки – это то, что дети в состоянии найти и сами. Тратить время занятия на поиск опечаток преподами – очень расточительно. Я бы посоветовал делить на куски, и отдавать на самостоятельную проработку дома.

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

                      Мы в нашей программе чётко разделяем, и явно задаём «парадигмы написания кода».
                      Опыт из жизни: приходилось сталкиваться с интересным явлением: дети считали, что программа это _цельный текст_ и робот/компьютер «читает его целиком на своём языке, и пытается понять, что ты от него хочешь». Понимания, что программа выполняется по шагам и можно это проверить-увидеть не было. (теперь это исправлено) При переходе на новую парадигму программирования тратится значительное время на объяснения и перестроение мышления.

                      Парадигмы: Лапша код, Лапша-код с ветвлениями/циклами, Функции и процедуры, Событийно ориентированные программы(+ ООП), Многозвенные приложения.

                      ИМХО. Сюда же отнесу бесполезность GitHub на данном этапе. Нужно сосредотачиваться и учить чему-то одному с контролем результата. Тратить время на правильные логины в гитхаб мне кажется расточительным.
                        0
                        они НЕ набирают текст

                        Да, имея намного более успешный опыт обучения с итерфейсом Scratch в виде "щёлкни здесь, перенеси туда", я уже задумываюсь о том, чтобы кардинально поменять инструмент в сторону визуального программирования в виде основы, а настоящего текста лишь для заданий со звёздочкой.


                        в наших головах счастливо и плодотворно живут названные и ещё десятки неназванных абстракций

                        Я тут скорее хочу найти такой набор инструментов программирования, который будет доступен и ребятам от 10 лет, и суровым мужикам (нам) для более серьёзной работы :)


                        Спасибо за дельные мысли!

                          0
                          По поводу визуального программирования.

                          Имею отрицательный опыт написания больших программ в таком стиле.
                          Для себя понял, что начиная с некоторого объёма, перестаю воспринимать программу.
                          При этом текстом воспринимается намного бОльший объём. Возможно это лично моё ограничение.
                            0

                            Согласен с объёмом, однако, в приведённом мною выше примере функции, думаю, визуальное представление вполне может быть проще. Основная идея тут в упрощении набора кода, т.е. заменить собственно набор перетаскиванием, на практике у ребят это получается быстрее.

                        +1

                        Я в любой непонятной ситуации беру маркер и начинаю рисовать на доске, так что с доской полностью согласен! :)
                        Я преподаю школьникам (7-11 кл) С++.
                        Переменные, массивы я объясняю так, как есть. Рисую полосу, две черты по краям и говорю, что это участок памяти в компьютере. Потом в "выделенном участке памяти" я обвожу квадратик и говорю, что здесь лежит переменная (квадратик сверху подписываю). И все действия с переменными я объясняю по квадратикам! С массивами аналогично, только добавляю специфическую для С++ информацию. С таким подходом мне удается донести суть указателей, ссылок и т.п. (на необходимом для школьников уровне).

                          0

                          Тут вопрос в том, насколько они понимают это. Я понял, что лишь горящие глаза однозначно говорят о понимании. А тихое "вроде понятно" скорее говорит о том, что ничего не ясно :)

                            +1

                            Не могут "горящие глаза" говорить о понимании. У человека могут быть горящие глаза на занятии, а дома во время самостоятельной работы боль, тлен и самокопания.
                            Я понимание оцениваю только по тому, удалось ли ученику сделать задачу по теме самостоятельно без моей помощи.

                              0

                              Согласен с вами!

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое