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

У мене є кілька студентів з інформатики в обов'язковому вступному курсі програмування, які розглядають мову програмування як набір магічних заклинань, які повинні бути відіграні для досягнення певного ефекту (замість того, щоб бачити це як гнучкий засіб для висловлення своєї ідеї рішення) .

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

Чи є якісь вправи чи аналогії, щоб зробити ці студенти впевненішими, що вони можуть і повинні розуміти структуру та значення кожного написаного ними коду?

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

Інша можливість - хоча це не суворо завдання програмування - це попросити їх оцінити різні речі. Наприклад, скільки води протікає через дельту Міссісіпі за секунду? На такі запитання немає відповіді, тим більше, що потрібно зробити певні припущення, щоб дійти до переконливого (діапазону) значення. І хоча відповіді на багато цих "класичних" справді можна гуглювати, ви легко можете скласти нові, яких ще немає в мережі.

Приклади обох цих видів вправ можна знайти в напр. Програмування перлів Джона Бентлі. Також Прагматичний програміст має деякі хороші проблеми.

Третім завданням буде представити їм якийсь фрагмент коду з (однією або декількома) помилками в ньому, який вони повинні знайти та виправити. Це знову змушує їх використовувати свої аналітичні навички та міркування про те, як програма працює насправді.

Оновлення

Відгук від коментаря Billy ONeal:

Проблема з "серією вправ" полягає в тому, що учні, у яких є проблема з попередньою вправою, повністю перекручені для решти вправ.

Ви маєте рацію, хоча я вважаю, що це стосується загальної проблеми встановлення складності курсу на потрібний рівень / групування учнів подібного рівня вмінь разом. Більше того, можна організувати учнів на менші групи, де від них вимагається обговорити та обговорити проблеми та рішення та вирішити проблеми разом. Якщо хтось цього не отримує, інші можуть допомогти (ця настройка також покращить навички роботи в команді). І якщо хтось намагається бути лінивим і нехай інші роблять всю роботу, це, безумовно, помічає вчитель (який, як передбачається, ходить, контролює та наставляє учнів, не граючи WoW на своєму ноутбуці в кутку ;-)

Також можна налаштувати вправи, щоб вмістити учнів з різними рівнями кваліфікації. Початківці можуть йти повільніше, досвідчені швидше.

Ви б’єтесь над актом врівноваження студентів над їх потребою піклуватися про ваш предмет та їхню потребу в проходженні оцінок . Багато студентів вважають, що:

(Неправильно || Експеримент) == (Невдалий рівень та час відходів)

Як тільки студент відчує, що їхній час чи оцінка загрожує небезпеці, навіть цікавий предмет вони перестають навчатися і переходять прямо до "Мені все одно, просто дай правильній відповіді вчителю". Ваші студенти намагаються вирізати куточки (або так вони думають) , думаючи якомога менше про проблему і просто рубаючи її, копіюючи та вставляючи.

Ось мої пропозиції щодо вирішення цього питання:

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

Кілька речей, які мені спадають на думку:

• Дайте їм завдання, де їм насправді доводиться пояснювати код, який написав інший (ви). Розуміння попереднього кодексу, а точніше його відсутність, є як найбільшою причиною, так і небезпекою програмування культового культу. Попросіть їх використати коментарі, якщо потрібно, рядок за рядком, щоб пояснити свою програму простою англійською мовою (або якою людською мовою ви користуєтесь).

• Лише після того, як вони пояснять код, попросіть його змінити, щоб внести певні зміни. Наприклад, якщо ви надали їм функцію сортування, яка сортує за спаданням, попросіть їх зробити сортування за зростанням. Або щось більш вимогливе. Але переконайтесь, що це щось вимагає розуміння даного коду.

• Ви можете, якщо хочете, покласти в код кілька писанок. Рядок чи два, що взагалі нічого не корисного і навіть не пов’язаного з проблемою. Підкажіть їм, що такі рядки існують, і надайте додаткові бали тим, хто їх видаляє.

• Тоді і лише тоді ви можете дати їм завдання самостійно написати фрагмент коду. У цей момент вони повинні мати набагато краще розуміння того, що насправді є кодом. Вони можуть навіть трохи легше зробити це самостійно.

Основна ідея полягає в тому, що програмування - це не просто написання коду, а й його читання. Коду читання також слід навчати.

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

Проблема у вас полягає в тому, що ваші студенти нічого не повторюють, вони копіюють це з Інтернету. У цьому є певна користь, але прибуток мінімальний. Акт фактичного введення коду - це те, що привело мене до місця розуміння. Я почав бачити візерунки в тому, що я друкував, і зрозумів, що роблю.

Один із варіантів - структурувати свою лабораторію у вигляді доджо коду. Запропонуйте учням по черзі спарювати один одного з однієї проблеми. Виберіть проблему, на вирішення якої потрібно від 10 до 15 хвилин. Повторіть цю проблему в декількох лабораторіях та введіть новий поворот до проблеми, коли рівень класу зростає. Можливо, запустіть лабораторію, змусивши учнів спостерігати, як ви програмуєте рішення, і змусити їх повторити. Перемикання пар з кожною ітерацією.

Для ваших тестів є кодовий код, де кожен студент працює через проблеми з семестру перед рештою класу. Зосередьтеся не лише на правильності, а на формі та креативності. Я думаю, це дозволить глибше зрозуміти, як програмувати, ніж давати домашні завдання.

Я викладав вступні заняття в минулому, і, як я пам'ятаю, озирався зараз:

Деякі студенти вважають, що програмування подібне з різних причин. Я колись добре пам’ятаю хорошого малюка, який багато вабив, що я робив:

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

1. Деякий час було витрачено на пояснення деяких речей, таких як детермінізм, який означав для них, що в одному середовищі з тими ж даними та кодом вони матимуть однакові результати (розвіяють "випадковість"),

2. Оскільки розв’язання задач залежить від того, які дії школяра, а не що-небудь інше, слід приділяти увагу вирішенню проблеми та не знаходженню правильного заклинання,

3. Вони знаходяться в освітньому середовищі, тому проблеми розробляються для того, щоб запропонувати досвід навчання, результат - навчитися програмувати (або в деяких випадках, наприклад, заняття для системних адміністраторів, як працюють програми, які відрізняються), а не дай мені рішення. ("Світ не потребує іншого калькулятора, це вправа"), тому їхні проблеми можна вирішити за наявними матеріалами (приклад: надані примітки),

4. Я думаю, що це в Code Complete: "Навіть якщо ви копіюєте та вставляєте, код - ваш". Якщо хтось це зробив, то це не повинно бути вантажно. Кожен рядок потрібно було пояснити мені (індивідуально) або іншому студенту (тому самому) або класу.

Чи розпочали ваші студенти на правильному "рівні абстракції" на початку курсу? Наприклад, домашнє завдання, яке знайомить їх з основними структурами програмування, такими як петлі та умовні умови, не записуючи жодного рядка коду?

Коли я взяв участь у програмуванні, наше перше завдання називалося « Рик робот ». У нас був аркуш паперу з повітряною картою міста з цікавими точками, як банки, продуктові магазини тощо ... У нас був чувак, який називався "Рік", і проводив дії на кшталт "зроби один крок", "дивись ліворуч", "дивись правильно", "переходиш дорогу", і ми можемо використовувати такі речі, як "повторити" і "якщо щось, то роби щось". (Це не на 100%, оскільки я не міг знайти це завдання). Ідея полягала в тому, що Рік міг використовувати лише те, що йому дано, і йому довелося дістатися до різних місць на карті.

Це була весела вправа і щось, що познайомило вас з основами (які іноді найскладніше зрозуміти новачкам). Немає жодної хорошої відповіді на цю проблему (її гра) і немає рішень для копіювання та вставки. Щось подібне може також дозволити вам пограти з їх творчістю трохи більше, не залякуючи їх кодом.

Нарешті, ідея полягає в тому, що ви починаєте з абстрактного і рухаєтесь до конкретного . Вони не можуть скопіювати конспект вставити. Вони повинні зрозуміти це для вирішення проблеми.

Те, що ви їх просите, - це продемонструвати аналіз та синтез у когнітивній галузі Bloom's Taxonomy , де вони наразі лише демонструють застосування.

На жаль, це така собі ситуація, як "вести коня у воду". Аналіз та синтез також дуже важко зробити, коли ти все ще борешся з розумінням. Без розуміння, діяльність з аналізу та синтезу буде діяти скоріше як бур'ян, ніж навчальна діяльність.

Моя особиста думка полягає в тому, що не варто сподіватися на заняття з програмування нічого іншого, ніж застосування. Це перший раз, коли студенти стикаються з цими поняттями, тому це як навчати дітей читати, перш ніж просити їх написати твір. Ці навички вищого порядку дотримуватимуться у своїх наступних заняттях.

Чи розглядали ви поставляти їх з деяким кодом , щоб почати з? Незалежно від потрібних простих будівельних лісів, як порожня основна функція (я не знаю, якою мовою ви користуєтесь). Щось, що компілює і працює і нічого не робить. Тоді вони можуть почати додавати свій код з певною мірою впевненості, що принаймні частина його працює.

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

Будь-яка культура менталітету (включаючи самі вантажні культи ) випливає з недостатнього розуміння технології.

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

Що ще важливіше, припущення про те, що нерозуміння студентом є просто наслідком його невпевненості в собі, є принципово неправильним і не вирішує основну проблему.

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

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

Змініть свою ідею проектів!

У світі програмування рідко ми створюємо нові проекти для кожного рішення, яке існує. Більшу частину часу ми модифікуємо старі.

Змініть свою ідею проекту з одного рішення для кожного завдання на одне рішення протягом усього семестру. Кожне завдання спирається на попереднє завдання.

Приклад

Проект: Побудувати ліфтову систему

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

Справа в тому, що ви спираєтесь на попереднє завдання замість того, щоб переробляти старі завдання для нового завдання.

Подумайте про використання мови дуже високого рівня, що вимагає мінімум кодового коду.

Для мене часто кодовий код у великих рамках або багатослівних мовах відчуває себе магічними заклинаннями і перешкоджає розумінню.

Мене особисто навчали МЛ на моєму вступному курсі програмування CS. Протягом багатьох років Лісп викладався як впровадження в програмування на MIT. Обидва - чудовий вибір. Деякі переваги у них є

• Інтерактивний перекладач. Дуже важливо, оскільки це дозволяє досліджувати.
• Дуже лаконічно. Відсутня котельня. Це дозволяє студентам сконцентруватися на ідеях, які вони намагаються висловити.
• Відносно незрозумілий та чужий (принаймні порівняно з Java, C чи іншими основними мовами, з якими студенти вже можуть мати певний досвід). Так, я перераховую це як професіонала. Він нівелює ігрові умови для студентів, оскільки, ймовірно, ніхто не матиме попереднього досвіду. І це робить меншою ймовірність того, що вони зможуть просто копіювати та вставляти рішення в домашні завдання з Інтернету.

Я робив кілька досліджень проблем початківців програмістів у 80-х. Виходячи з мого досвіду з початківцями програмістами, багато чого не змінилося. Новачки не мають корисної ментальної моделі того, чим займаються комп'ютери. Вони вдаються до магічних чарів, тому що сама машина магічна.

Програмування вимагає розбиття природних простих завдань на неприродно малі кроки. Оскільки новачки не поводяться з такою тонкою деталізацією в повсякденному житті, їм важко розібратися, якими мають бути маленькі кроки, особливо коли не зрозуміло, які маленькі кроки робить машина доступною. Але навіть якщо їм все-таки вдасться це зрозуміти, вони зіштовхуються з синтаксисом і обмеженою семантикою мови програмування.

Оскільки вони не можуть встановити зв'язок між логічним рішенням проблеми та функціональністю машини, вони зосереджуються на задоволенні вимог мови. Перша мета - написати щось - що-небудь, що складається. Друге - налаштувати цю програму - все, що вона насправді робить, - щоб уникнути її збоїв. Потім, якщо у них є час, енергія та інтерес, вони намагаються змусити програму отримати результати, схожі на те, що вимагає проблема. Попутно вони можуть випадково створити добре написаний код.

Ймовірно, новачки, які вчаться програмувати, досягають успіху, тому що вони зробили корисну розумову модель комп’ютера, а не тому, що їм навмисно дали та інтерналізували її.

Ви можете задати їм запитання щодо фрагментів коду, які потребують письмових відповідей? На кшталт "Що робить цей код?" "Чому програміст вирішив це так?" "Чи є кращий спосіб?" Тощо?

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

• Киньте виклик їм, щоб створити найкоротші можливі рішення проблеми.
• Нагородіть більш стильні рішення заохоченням.
• Створіть вправи, які повністю обертаються навколо коду рефакторингу
• Запропонуйте студентам торгувати завданнями та знущатися над їх оцінкою щодо ефективності та чистоти коду, а також використовуйте деякі з найменш ефективних в якості прикладів на проекторі.

Аналогічно ідеї JoelFans, щоб вони виконали початкові завдання на папері, використовуючи створений вами псевдо-код (мова). Ви можете додати структури так, як вважаєте за потрібне, і вони не турбуються про чарівну скриньку.

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

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

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

Коли я взяв клас по складанню, вчитель сказав би нам про кожну вправу, чи хоче він, щоб ми написали код для швидкості, розміру чи використання пам'яті, і він відзначився, якщо ви не наблизилися до оптимізації того, що він запитував для.

...

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

На жаль, таким чином працює багато мозку людей. Тож увійдіть у це розуміння, що є люди, яких ви не можете "вилікувати" від цього. Є багато людей, які не здатні працювати на рівні розумової точності, необхідної для програмування. Деякі люди просто не призначені для цього. Я не кажу, що здавайся студентам - я кажу, не припускаю, що ти зазнаєш невдачі, якщо не всі підхоплюють це.

Не знаючи більше про контекст класу, я б сказав більше зосередитись із цими проблемними учнями на самих основних структурах - прості if / thens, циклі тощо. Прості підпрограми для друку непарних чисел, кожного десятого числа тощо. Нічого більше 10 рядків коду кожен. Якщо вони "магічне мислення", вони, очевидно, ще не освоїли ці основи. Дозвольте їм зробити багато різних простих процедур, поки вони не зрозуміють, що відбувається. Хтось ще згадав про написання коду на папері - я думаю, що це також був би чудовим способом зробити ці прості процедури.

Ви також можете подумати, щоб вони вивчили графік потоку. Для деяких людей здатність бачити потік алгоритму, а потім, як це з'єднується з кодом, може бути корисним для їх підключення коду до потоку.

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

Це допомагає сказати їм, що цих вказівок буде дотримуватися буквально робот, який не знає, як зробити висновок. Це має бути дуже практичним заняттям, коли ви керуєте ними керуванням.

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

Ще один успішний спосіб, який я бачив, - це створення декількох проектів, які будуються один на одному, що робить робочу версію за замовчуванням доступною на кожному кроці після вручення завдань, щоб люди не відстали. Кожен крок процесу повинен вводити щось нове. Я дозволю вам, що це можливо зробити простіше в класі дизайну, ніж клас програмування, але все-таки це слід зробити. Одне приємне в цьому полягає в тому, що ви явно даєте їм хорошу (сподіваюся) реалізацію для порівняння з їх на кожному кроці. Розкрийте це порівняння як завдання, тобто зробіть огляд міні-коду власного коду проти своїх зусиль. Ви можете скористатися одним із декількох додаткових варіантів кредитування.

Хоча я, як правило, не маю великого значення щодо "коментарів", ви можете зробити документацію коду одним із класів. Запропонуйте їм скласти документ "Теорія роботи" для кожного проекту, який описує їх підхід, як кожен компонент вписується та як вони разом вирішують проблему. Як правило, я хотів би, щоб код багато чого робив самостійно, але це би спонукало їх надягати шапки для мислення та ставити їх на папір.

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

Просто швидка пропозиція. Кожен раз, коли у мене є проблема програмування, яку потрібно вирішити або налагоджувати, я люблю переглядати свій код і "грати в комп'ютер", де в голові я відслідковую змінні та їх значення, і що я очікую від них, коли буде запущено кожен рядок . Тож якщо я десь скопіював якийсь код, якщо він не є повноцінним, і мені просто потрібно посилатися на нього, мені подобається переходити по черзі, щоб зрозуміти, що саме відбувається. По суті грає комп'ютер. Відладчик VBA по суті полегшує цю задачу, але змушення своїх учнів робити це на папері може дати їм такі основи. Що насправді робить цей рядок?

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

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

Я побудував маленький комп'ютер з чіпом Intel 8008, деяким EPROM та кількома схемами. Я програмував його на невеликий дует, коли мікросхема вводу / виводу була підключена до пари динаміків. Я б пояснив, як мала програма працювала, з внутрішньою петлею, щоб відлічити лічильник. Це діяло б як затримка. Тоді він буде перемикати вихідний біт і робити це знову. Це зробить це на деякий час, а потім переключиться на іншу затримку, даючи ще один крок тощо. У мікросхеми пам'яті було трохи таймера, і якщо я вставив конденсаторний відвід під один з входів таймера, програма запускала б веєеері повільно . Клас міг чути, як динаміки клацають, клацають, клацають ... Я хотів, щоб клас зрозумів, що комп'ютер робив дуже прості речі один крок за часом. Тоді я би відключив провід конденсатора, і "музика" вибухнула б. (оплески)

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

Сенс цього полягав у тому, щоб створити концепцію, що комп'ютери можуть виконувати лише дуже малу кількість різних основних операцій, і вони роблять їх по одному. Це полягає в тому, щоб протистояти враженням, що комп’ютери складні, і що вони все роблять одночасно, і читають вашу думку в угоді.

Звідти ми перейшли до програмування "справжньою" мовою (BASIC :), починаючи з дуже простих, але цікавих програм, опрацьовуючи умовні умови, цикли, масиви, файли, об'єднуючись тощо. Завданням було встановити достатній набір навичок, щоб вони могли взяти на себе проект за власним вибором, адже це єдине, що робить програмування цікавим - використання, до якого ви можете його поставити. Я б викинув кілька ідей для проектів, а потім вони їх звідти візьмуть. Я б просив писати ідеї, а потім звіти про хід, щоб не відкладати їх на останню хвилину, а потім панікувати. Я думаю, що проекти були найкращою частиною, адже вони навчалися під власні сили.

Це початкове обгрунтування в дуже конкретному розумінні того, що роблять комп'ютери, значно полегшило викладання концепцій, які в іншому випадку були б реальними ударами швидкості, як масиви або (в подальшому курсі) покажчики. Ми схильні прославляти поняття "абстракція" як цю чудову річ, але її потрібно будувати на конкретному фундаменті, а не на повітрі.

Saself - вчив програміст Я вважаю , що анімація буде найбільш складним з точки зору знаючи , що робить код. Коли програма містить алгоритми та математичні перетворення, що виконують абстрактні маніпуляції, єдиний спосіб зрозуміти, що математика робить у будь-якій точці (якщо ви геній), вимагає розуміння виконання самого коду.

Виправте мене, якщо моя наївна ідея неправильна. Що ви хочете зробити, це notне дозволяти вашим студентам використовувати «шаблони дизайну», але знайти спосіб переконатися, що вони розуміють, що вони є CnP? Потім киньте виклик своїм учням маніпулювати анімацією. Щоб налаштувати вихід в анімації, необхідно зрозуміти, що відбувається на кожному кроці. Що стосується Вашого занепокоєння, я думаю, що добре продуманий проект анімації проявиться очевидними способами, коли студент "отримує це" - коли вони здійснили трансформацію, яку ви не очікували або не змінили певні пов'язані, взаємозалежні змінні.

Не знаючи педагогічних меж і цілей, над якими ви працюєте, я не можу сказати, що анімація є повною відповіддю. Цілий навчальний план анімації поза професією анімації - це, мабуть ризикувати, не можна. Кілька проектів все-таки можуть призвести до чогось майстерного та чудового, що непогано.

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

Я впевнений, що це було в NY Times. Швидкий пошук не знайшов. Аналогічний приклад - Міжнародний конкурс колегіального програмування ACM. Цей конкурс підкреслює швидке програмування: "Швидке програмування блискавки в командних змаганнях - це рішуче химерна майстерність. Не так багато хто, хто шукає роботу, розмістив би на вершині резюме". Тому я б рекомендував абстрагуватися від реальних проблем - це відповідь.

Також,

HP Code Wars

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

Ви можете також ставитися до них важким шляхом.

Знайдіть спосіб зробити копію-пасту шкідливою для них. Я не маю точного прикладу, але якщо ви складете першу вправу, рішення якої, якщо її вставити в подібну схожу другу вправу, привезе студент-культ у дуже довгу і болісну помилку "нестабільної нестабільності" або "мовчазної пошкодження даних". Тим часом "2-мільйонне" культове мислення принесло б очевидне рішення навіть найгіршому школяреві (якби він не бачив першого рішення з вправ). Тоді, можливо, є певна можливість, щоб вони могли засвоїти урок, і подумати двічі, перш ніж скопіювати вставлення коду в третю вправу.

Я сумніваюся, що така поведінка через віру в те, що програми - це магічні заклинання - скоріше, це лінь і відсутність мотивації.

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

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

Запропонуйте їм виконувати завдання перед вами в класі без доступу до Інтернету (нехай школа відключить це, не дозволяйте користуватися телефоном також під час уроку). Принаймні зробіть це для тестів. Зовсім немає підстав для того, щоб вони користувалися Інтернетом для проведення основних програм програмування. Книга повинна бути достатнім ресурсом для вступних вправ. Дозвольте користуватися Інтернетом, коли ви перебуваєте в просунутому класі, і вони вже навчилися думати.

Ніколи не дайте їм аналогічних звуків.

Або, більш божевільний, вивчити їх TDD з самого початку. Це підштовхує до написання (не копіювання, написання) багато коду (а саме тестів), що фактично допомагає сформулювати проблему, яка вирішується.

Щось мені здається дуже корисним для людей мого класу, - це написати невеликий проект на їхню тему, яку вони можуть вибрати самі.

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

Ще кілька людей у ​​моєму класі пішли від 40-50% на іспитах до 90-100%, тому що вони зробили точно те саме.

Коли я був на вступному курсі програмування, інструктор вимагав від кожного написати алгоритм англійською мовою та роздрукувати його та ввімкнути його, перш ніж ми почали писати код. Тоді нам доведеться розмістити безліч коментарів, таких як Створення змінних, Отримати введення від користувача, Виконання обчислень, Виведення друку тощо. Мене пару разів стикали за те, що мені не вистачало коментарів, коли я вважав, що їх багато, тому я почав додавати більше. Це змусило мене думати про те, що я роблю, і писати рішення і продовжувати перекладати туди і назад між англійською та Java.