Обучение методу

Вперед к новой педагогике для программистов

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

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

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

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

Стратегия "от потребителя к производителю"

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

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

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

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

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

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

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

Абстракция

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

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

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

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

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

Ученичество

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

Этот подход является продолжением тенденции, уже повлиявшей на обучение некоторым темам в программистском образовании, таких как конструирование компиляторов, еще до того, как объектная технология стала популярной. В семидесятых и в начале восьмидесятых годов типичный семестровый курс по компиляторам включал написание компилятора (интерпретатора) с нуля. Однако первые же задачи лексического анализа и разбора требовали столь больших усилий, что на практике компилятор мог быть построен только для игрушечного языка. Обычно дело не доходило до наиболее интересных вещей: семантического анализа, генерации кода и оптимизации. Когда же появился и стал широко применяться инструментарий для лексического анализа и разбора, такой как Lex и Yacc, то это позволило студентам тратить на эти задачи существенно меньше времени. Наша стратегия обобщает этот опыт.

Обращенный учебный план

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

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

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

Политика многих семестров

Стратегия "от потребителя к производителю" имеет интересный вариант применения в курсах, ориентированных на приложения, таких как Операционные системы, Графика, Конструирование компиляторов или Искусственный интеллект.

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

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