Как я могу справиться с отношением программирования к культу груза?

У меня есть студенты-информатики на обязательном вводном курсе по программированию, которые рассматривают язык программирования как набор магических заклинаний, которые должны быть сотворены для достижения какого-то эффекта (вместо того, чтобы рассматривать его как гибкую среду для выражения своей идеи решения) ,

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

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

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

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

Примеры обоих видов упражнений можно найти, например, в « Программирование жемчуга » Джона Бентли. Также у Прагматичного Программиста есть некоторые хорошие проблемы.

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

Обновить

Отзыв от комментария Билли ONeal:

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

Вы правы, хотя я чувствую, что это больше относится к общей проблеме задания сложности курса на правильном уровне / группирования студентов с одинаковым уровнем квалификации вместе. Кроме того, можно организовать студентов в более мелкие группы, где они должны обсуждать и обсуждать проблемы и решения, а также решать проблемы вместе. Если кто-то не понимает, другие могут помочь (эта установка также улучшит навыки командной работы). И если кто-то пытается быть ленивым и позволить другим делать всю работу, это обязательно заметит учитель (который должен ходить, контролировать и наставлять учеников, а не играть в WoW на своем ноутбуке в углу ;-)

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

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

(Получите это неправильно || Эксперимент) == (Сбой оценки && Тратить время)

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

Вот мои предложения о том, как с этим бороться:

1. Используйте метод Боба Росса: докажите им , что возможно и быстрее начать заново, чем копировать и вставлять. Создавайте новые программы перед глазами на уроках - действительно покажите им, что программирование может быть как рисование картины.
2. Обеспечить задания, которые требуют творчества . Например, пусть каждый студент создает свои собственные структуры данных (какие объекты необходимы для создания зоопарка, зоомагазина, города, колледжа и т. Д.) На бумаге для использования на протяжении всего курса. Задание № 2 может заключаться в преобразовании этих структур в классы или объекты и т. Д. По сути, побуждайте их мыслить абстрактно - вознаграждайте их за творческий подход, а затем вознаграждайте их за превращение их творчества в компьютерную программу.
3. Используйте как можно меньше синтаксиса. Такие элементы, как создание классов и синтаксис языка, настолько распространены во введении в программирование, что часто вводят студентов в заблуждение, заставляя их думать, что все программирование просто знает, куда поместить фигурные скобки - они не понимают, что находится в середине фигурного Брекеты - это место, где течет творчество . Выберите простой язык и предоставьте образцы файлов (например, пустой файл класса) для студентов, которые все еще хотят что-то скопировать и вставить. Вы можете постепенно становиться более строгими в отношении синтаксиса и компилируемых заданий по мере прохождения курса.

Несколько вещей, которые приходят мне в голову:

• Дайте им задания, в которых им действительно нужно объяснить код, написанный кем-то другим (вами). Понимание предыдущего кода или, более конкретно, его отсутствие является одновременно главной причиной и опасностью программирования культа грузов. Попросите их использовать комментарии, если нужно, построчно, чтобы объяснить свою программу простым английским языком (или любым другим языком, который вы используете).

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

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

• Тогда и только тогда вы можете дать им задание самостоятельно написать кусок кода. На этом этапе они должны лучше понимать, что такое код на самом деле. Возможно, им даже будет немного легче сделать это самим.

Основная идея заключается в том, что программирование - это не просто написание кода, а его чтение. Чтение кода также должно преподаваться.

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

Ваша проблема в том, что ваши ученики ничего не повторяют, они копируют это из Интернета. В этом есть некоторая выгода, но выгоды минимальны. Фактическая распечатка кода - вот что привело меня к пониманию. Я начал видеть шаблоны в том, что я печатал, и понял, что я делаю.

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

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

Я преподавал вводные уроки в прошлом и, насколько я помню, оглядываясь сейчас назад:

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

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

1. Некоторое время было потрачено на объяснение некоторых вещей, таких как детерминизм, что означало для них, что в одной и той же среде с одинаковыми данными и кодом они будут иметь одинаковые результаты (рассеять «случайность»),

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

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

4. Я думаю, что это в Code Complete: «Даже если вы копируете и вставляете, код ваш». Если кто-то сделал это, это не должно быть в стиле груза. Каждая строка должна быть объяснена мне (индивидуально) или другому ученику (так же) или классу.

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

Когда я познакомился с программированием, наше первое задание называлось « Робот Рик ». У нас был лист бумаги с аэрофотоснимком города с интересными точками, такими как банки, продуктовые магазины и т. Д. У нас был чувак по имени Рик, и у нас были такие действия, как «сделать один шаг», «посмотрите налево», «смотри прямо», «переходи дорогу», и мы могли бы использовать такие вещи, как «повторить» и «если что-то, то сделать что-то». (Это не 100%, так как я не смог найти это задание) Идея заключалась в том, что Рик мог использовать только то, что ему дали, и ему нужно было добраться до разных мест на карте.

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

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

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

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

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

Рассматривали ли вы снабдить их кодом для начала? Каким бы простым лесам не требовалось назначение, например, пустая основная функция (я не знаю, какой язык вы используете). То, что компилируется и запускается и ничего не делает. Затем они могут начать добавлять свой код с некоторой степенью уверенности в том, что хотя бы его часть работает.

Это на самом деле довольно распространено в «реальном мире»; множество IDE и других инструментов создают пустые проекты с уже имеющимися типичными библиотеками / шаблонами / файлами конфигурации.

Любой вид менталитета грузового культа (включая сами культы груза ) происходит из-за недостатка фундаментального понимания вовлеченной технологии.

Программирование Cargo-Cult должно рассматриваться не как проблематичная привычка, а скорее как признак основного замешательства, с которым сталкивается программист.

Что еще более важно, предположение о том, что отсутствие у студента понимания является просто результатом его неуверенности, в корне неверно и не решает основную проблему.

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

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

Измени свое представление о проектах!

В мире программирования мы редко создаем новые проекты для каждого возникающего решения. Большую часть времени мы модифицируем старые.

Измените свое представление о проекте с одного решения для каждого задания на одно решение на весь семестр. Каждое назначение основывается на предыдущем назначении.

пример

Проект: Построить систему лифта

• Задание 1: Распечатать текущий этаж
• Задание 2: Создать структуры данных для класса лифта и распечатать этаж на основе лифта
• Задание 3: Создать код, который «перемещает лифт», распечатывая пол. Принять ввод с клавиатуры (> введите этаж:)
• Задание 4: Обработка нескольких лифтов

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

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

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

Я лично преподавал ML на моем вводном курсе программирования CS. В течение многих лет Лисп преподавали как введение в программирование в MIT. Оба являются отличным выбором. Некоторые из преимуществ, которые они имеют

• Интерактивный переводчик. Очень важно, так как это позволяет разведку.
• Очень лаконично. Нет шаблонов вообще. Это позволяет студентам сосредоточиться на идеях, которые они пытаются выразить.
• Относительно неясный и чуждый (по крайней мере по сравнению с Java, C или другими основными языками, с которыми у студентов уже может быть некоторый опыт). Да, я перечисляю это как профессионал. Это выравнивает игровое поле для студентов, так как, вероятно, никто не будет иметь предыдущий опыт. И это снижает вероятность того, что они смогут просто копировать и вставлять решения для домашней работы из Интернета.

Я провел некоторые исследования проблем начинающих программистов в 80-х годах. Исходя из моего опыта работы с начинающими программистами сегодня, мало что изменилось. У новичков нет полезной мысленной модели того, что на самом деле делают компьютеры. Они прибегают к магическим заклинаниям, потому что сама машина волшебна.

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

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

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

Вы могли бы задать им вопросы о фрагментах кода, которые требуют письменных ответов? Как "Что делает этот код?" "Почему программист решил это так?" «Есть ли лучший способ?» И т. Д.?

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

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

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

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

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

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

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

...

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

К сожалению, так работает мозг многих людей. Так что поймите это понимание, что есть люди, которых вы не можете «вылечить» от этого. Есть много людей, которые не могут работать на уровне умственной точности, необходимой для программирования. Некоторые люди просто не предназначены для этого. Я не говорю, что разочаровывайтесь в студентах - я говорю, не думайте, что вы терпите неудачу, если не все подберут это.

Не зная больше о контексте класса, я бы сказал, что с этими проблемными учениками нужно больше сосредоточиться на самых базовых структурах - простых if / thens, циклах и т. Д. Простые процедуры для вывода нечетных чисел, каждого десятого числа и т. Д. Ничего более 10 строк кода каждая. Если они «волшебное мышление», они, очевидно, еще не освоили эти основы. Попросите их выполнить множество простых процедур, пока они не поймут, что происходит. Кто-то еще упомянул написание кода на бумаге - я думаю, что это также был бы отличный способ сделать эти простые процедуры.

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

В идеале, в первой лекции, начните с чего-то совершенно абстрактного: пусть они (как группа, с вами как лидер) напишут инструкции о том, как делать покупки из списка, и постепенно разбирайте инструкции высокого уровня пока они не достигнут просветления.

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

Алистер Кокберн рассказывает о концепции Шу-Ха-Ри и ее применении к программированию, http://alistair.cockburn.us/Shu+Ha+Ri . Я думаю, что важно иметь в виду, где находятся ваши ученики в этом континууме. Во-первых, это поможет ослабить некоторые ваши разочарования. Копирование / имитация - это очень естественный ответ и принятый режим, когда вы начинаете что-то изучать. Во-вторых, это может помочь вам получить некоторые идеи о том, как двигаться вперед. Например, вы можете рассмотреть возможность выбора проблемы, которая может быть решена несколькими способами (циклы против рекурсии, консоль против веб / графического интерфейса), а затем явно попросить их сначала решить ее одним способом, а затем другим способом - бонус, который они могут изучить. о законном повторном использовании кода, компонентизации, создании повторно используемых библиотек и т. д.

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

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

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

Просто быстрое предложение. Всякий раз, когда у меня возникает проблема программирования, которую нужно решить или отладить, мне нравится смотреть на мой код и «играть на компьютере», где я в своей голове отслеживаю переменные и их значения, а также ожидаю их появления при запуске каждой строки. , Так что, если я скопировал некоторый код откуда-то, если он не завершен сам по себе, и мне просто нужно сослаться на него, я хотел бы идти построчно, чтобы точно понять, что происходит. По сути игра на компьютере. VBA Debugger существенно облегчает эту задачу, но если вы заставите ваших учеников сделать это на бумаге, это может дать им такие же основы. Что на самом деле делает эта строка?

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

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

Я построил маленький компьютер с чипом Intel 8008, немного СППЗУ и несколько микросхем. Я запрограммировал его на небольшой дуэт, когда микросхема ввода-вывода была подключена к паре динамиков. Я бы объяснил, как работает маленькая программа, с внутренним циклом для обратного отсчета счетчика. Это будет действовать как задержка. Затем он переключит выходной бит и сделает это снова. Это будет делать это некоторое время, а затем переключаться на другую задержку, давая еще один шаг и так далее. У микросхемы памяти был небольшой таймер, и, если бы я подключил провод конденсатора к одному из входов таймера, программа работала бы очень медленно . Класс мог слышать, как ораторы щелкают, щелкают, щелкают ... Я хотел, чтобы класс понял, что компьютер делает очень простые вещи по шагам за раз, Тогда я бы отсоединил провод конденсатора, и «музыка» разразилась. (аплодисменты)

Затем я построил симулятор для очень простого десятичного компьютера, имеющего 1000 ячеек памяти, каждая из которых содержит 4-значное десятичное число со знаком. У него были очень простые коды операций, такие как «добавить в аккумулятор», «прыгать, если отрицательный», и так далее. Я бы попросил их написать небольшие программы на этом «машинном языке», например, добавить два числа или добавить список чисел. Затем они могли наблюдать за его работой, пошагово или удерживая клавишу Enter, чтобы посмотреть, как он работает «быстро».

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

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

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

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

Поправь меня, если моя наивная идея неверна. Что вы хотите сделать, это notзапретить вашим студентам использовать «шаблоны проектирования», но найти способ убедиться, что они понимают, что они из CnP? Затем бросьте вызов своим студентам, чтобы управлять анимацией. Чтобы настроить вывод анимации, необходимо понимать, что происходит на каждом шаге. Что касается вашей заявленной озабоченности, я полагаю, что хорошо продуманный анимационный проект проявится очевидным образом, когда учащийся «получит его» - когда он осуществил преобразование, которого вы не ожидали, или настроил некоторые связанные, взаимозависимые переменные.

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

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

Я уверен, что это было в Нью-Йорк Таймс. Быстрый поиск не нашел его. Аналогичным примером является Международный конкурс студенческого программирования ACM. В этом конкурсе особое внимание уделяется быстрому программированию: «Быстрое программирование в командных соревнованиях - это определенно странное умение, и совсем не то, что многие ищущие работу поместили бы на вершину резюме». Таким образом, я бы рекомендовал абстрагирование от реальных проблем, это ответ.

Также,

HP Code Wars

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

Вы также можете относиться к ним нелегко.

Найдите способ сделать копипасту вредной для них. У меня нет точного примера, но если вы создадите первое упражнение, решение которого, если оно будет вставлено в похожее второе упражнение, принесет учащимся-культовым грузам очень долгую и мучительную ошибку «нестабильная нестабильность» или «искажение данных без вывода сообщений». Между тем, «не грузный культ», основанный на двух мнениях, принес бы очевидное решение даже худшему ученику (если бы он не видел первое решение для упражнения). Тогда, возможно, есть некоторая возможность, что они могли бы выучить урок и дважды подумать, прежде чем копировать код вставки в третье упражнение.

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

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

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

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

Никогда не давайте им одинаково звучащие задания.

Или, более сумасшедший, изучите их TDD с самого начала. Это подталкивает к написанию (не копированию, написанию) большого количества кода (а именно тестов), который фактически помогает сформулировать решаемую проблему.

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

Когда я начал программировать, мне тоже было трудно, и я много копировал в классе. Затем дома я начал делать маленькие игры, потому что хочу стать программистом игр, и я обнаружил, что их гораздо проще создавать. Хотя они были намного сложнее, чем то, что мы видели в классе. Просто потому, что меня это заинтересовало.

Еще несколько человек в моем классе прошли экзамены с 40-50% до 90-100%, потому что они сделали то же самое.

Когда я проходил вводный курс программирования, инструктор требовал, чтобы все написали алгоритм на английском языке, распечатали и включили его, прежде чем мы начали писать код. Затем мы должны были бы поместить множество комментариев, таких как «Создать переменные», «Получить ввод от пользователя», «Выполнить вычисления», «Вывод на печать» и т. Д. Я был несколько раз пристыкован к нехватке комментариев, когда думал, что их было много, поэтому я начал добавлять Больше. Это заставило меня задуматься о том, что я делаю, написать решения и продолжать переводить туда-сюда английский и Java.