Поделиться

понедельник, 19 апреля 2010 г.

Письма: "Какой язык преподавать?"

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

Письмо, с которого началось обсуждение, было таким:
Меня критикует второй преподаватель по программированию у нас на кафедре, что я на "Языках программирования" даю С++ и С# в среде MS Visual. А потом он на 4 курсе дает методы программирования и прикладное программирование под Delphi, и получается не очень.

У меня здесь своя логика. Я провела небольшое исследование по поводу первоначальных навыков студентов первого курса. Так вот чаще всего в школе изучают Basic в 6 случаях из 10 и Pascal - в 3 из 10, потом Delphi 1 из 10. Есть редкие случаи, когда студент изучал С++ или С# - один из 100. Так вот, представляете приходит группа 30 человек на занятие, как выбрать язык, чтобы всем это было новым? Второй момент, это то, что в газетах в объявлениях редко бывает требуются специалисты в Delphi. Плюс второй язык изучать проще, чем первый, а третий - еще проще. Вот и решила с С++ начинать. Как Вы думаете нужно ли что-то поменять подходе?

Ответ был таким:
Я считаю, что сами вопросы неверные в корне. Изучение языка не должно быть для специалиста проблемой и для хорошего специалиста таковой не является. Ваш подход (с Ваших слов) показывает, что Вы выбираете язык, потому что его мало кто знает, то есть акцент на языке. А аргументация другого преподавателя также неуместна, поскольку раз при изучении какой-то дисциплины на Delphi получается "не очень", значит не среда программирования выбрана максимально подходящей под содержание дисциплины, а наоборот.

Вопрос в том, из чего состоит специальность, связанная с разработкой ПО? Она состоит не из научения 8-ми языкам. Она даже не исчерпывается программированием как таковым, далеко не исчерпывается. Есть анализ, проектирование, реализация, тестирование, сопровождение, документирование. Каждая из этих составляющих может быть организована по-разному и иметь свои разные стандарты и приемы, знания, необходимые для такой деятельности, а сами эти фазы/этапы/виды деятельности могут быть по-разному организованы, какие-то могут не присутствовать в конкретном случае, какие-то могут быть уникальны. Слишком сильный акцент на языке приводит к воспитанию специалистов, которые могут писать ПО в гараже или на коленке, но не в команде и не в промышленных условиях. В самом программировании опять же есть много уровней с очень большой вариативностью: прикладное/системное, ОС, язык, парадигма (ООП, структурная, функциональная и т.д.), технология (WinAPI, Windows Forms, Presentation Foundation, например, все позволяют делать оконные программы) и т.д.

Принципиальных проблем с ПО сегодня три, на мой взгляд:
  1. Сложность его разработки - на коленке уже гениальный шедевр не создашь.
  2. Разнообразие парадигм, технологий, языков, платформ и других средств, подходов к организации процессов разработки, что усложняет выбор (это, конечно, все замечательно, но все равно это трудность).
  3. То, что технологии очень быстро меняются и мутируют.
Еще одна, как я люблю говорить, "вообще, проблема современного мира": масса людей, либо не понимает, что поступает неправильно, хотя для всех остальных это очевидно, либо понимает, но тщательно делает вид, что не понимает. В данном частном случае, например, это выражается в абсолютном незнании выпускниками ИТ-шниками основ бизнеса, особенностей работы в команде, вообще всего, что выходит за рамки кодирования (конечно, в редких вузах есть редкие исключения). В результате у нас бизнес в этой сфере развивается, но либо ненадолго и неправильно, либо очень медленно. Откуда студенты будут это знать, если большая часть их преподавателей на практике никогда не работала? А ведь начать бизнес, хотя бы малый, в этой сфере - дело очень дешевое, на самом-то деле. Ведь программисты работают не с дорогостоящими станками и материалами, а с "чистой мыслью" (по выражению С. Макконнелла).Такая вот интересная картина. В связи со всем этим первое, что нужно сделать, когда составляется план обучения на пятилетку (или если по направлениям, то уж как решили: 3, 3.5 или 4 года + магистратура), нужно определиться с тем, что будет в этом плане. Не какие ЯЗЫКИ, а какое наполнение, включая кодирование, но включая и очень многое другое. И вот для этих целей и нужен декан (или директор института). Именно его видение специальности, его понимание готового к работе специалиста, по согласованию (или "с приправами", или корректировками) с заведующими кафедрами и преподавателями и является тем, что записывается в план и реализуется. Определиться с этим сами кафедры или преподаватели не могут по определению, поскольку не видят всей картины - её видно только тому, кто видит специальность в целом, а кафедры делятся в зависимости от специализации, научной школы, отрасли, но не специальности. При этом неважно, подчинены ли они факультету или нет: когда я там работал, кафедры в МЭСИ были подчиненными факультетам, а в МФПА (в период моей работы там) - общеакадемическими, то есть деканы не имели формальной власти над ними. У нас практически не было лишнего дублирования в дисциплинах, все текло гладко и логично, потому что я вычитывал каждую программу, работал с каждой кафедрой или преподавателем, разумеется, "неся свою веру" и видение и размахивая планом. И большое им спасибо за совместную работу. Это очень кропотливый труд, не скрою.Как определить содержание плана? Разные есть подходы: можно на основе того, что является востребованным отраслью ИТ или другими, можно на основе стандартов и рекомендаций наших (АПКИТ работает в этом направлении) или международных. Я брал за основу рекомендации по подготовке ИТ специалистов ACM Computer Curricula 2001 + в последние годы Swebok (так называемое "ядро знаний в области ИТ"). На 4-ом, 5-ом годах обучения в рамках дисциплин специализации уделял большее внимание тому, что актуально в отрасли на данный момент (5-10 лет назад это был Веб, потом Unix, потом Мобильные устройства, потом опять Unix и т.д.), тогда как на первых курсах больше давал того, что в большей степени неизменно. Таким образом сглаживалась эта истерическая изменчивость ИТ - если начинать ориентироваться на современные потребности рынка сразу, то через 5 лет окажется, что учили "не тому", а если кто из ребят пойдет работать прямо сейчас с младших курсов, то и сам поднаберется опыта.После того, как определено и согласовано "видение"/план вместе со списком, наполнением и порядком дисциплин - только после этого для каждой дисциплины в зависимости от того, что за чем идет, и, что для чего уместнее, выбирается среда или язык, в которых будет происходить обучение. Понимаете, что я хочу сказать - это не вопрос для неаргументированного спора двух преподавателей (и даже для аргументированного), на чем лучше учить, не вопрос двух дисциплин. Это очень серьезная вещь на уровне целой специальности в вузе (за которую я обычно беру деньги, но тут уж меня "приперло" поговорить). Ведь от того, насколько правильно, логично выстроена вся цепь дисциплин: и профильных, и "непрофильных", зависит в конечном итоге судьба людей. Лично мое мнение (резюме): С++ откровенно плох для первого курса, потому что на первом курсе обычно проходятся по базовым конструкциям и алгоритмам структурного программирования, и Pascal 7.0 - старый, добрый, или VB мне кажется куда уместнее, чем С++ со своими строками, массивами, указателями и ссылками - ни к чему он там с этими лишними сложностями. Мне очень понравилось высказывание в книге Кернигана, Ритчи и Денниса: "С - это язык не слишком высокого уровня". То есть обычно языки делят на "высокого" и "низкого уровня", а тут - ни 2, ни 1.5.С другой стороны, Delphi для четвертого курса, при условии, что это новая для большинства среда - тоже откровенно неправильный вариант. К этому моменту большинство уже попробовало визуальное программирование в той или иной среде, зачем делать акцент на изучении еще одной? Не понимаю. Но опять же, как я уже сказал, это нужно видеть программы (1), и это нужно видеть последовательность дисциплин (2), потому что раз возникают такие споры и такие решения, значит там явно не все гладко. Извините, что я так прям с плеча, но зато я предельно откровенен.Мы делали так (это один из вариантов - они менялись с годами): на первом курсе VB или Pascal (вот кстати, где можно использовать Delphi - все-таки внутри-то у нее Object Pascal, поэтому и попроще, чем С++ - с одной стороны, и введение в визуальное программирование - с другой, только если без заострения внимания на внутренних механизмах). Второй год - С (не С++), работаем с указателями и прочим. В параллель с изучением С идет полгода Ассемблера обязательно. Сколько бы ни говорили о его устаревании, нет ничего лучше для разбирательства с разными типами адресации, хорошее понимание которой, как воздух, нужно для С и С++ и ООП в целом (и специалисты отрасли мне лично говорили об этом и даже благодарили отдельно за это). Потом С++ с ООП... и понеслась. Дальше уже как Бог на душу положит в смысле языков: дело в содержании дисциплин - в парадигмах, технологиях, ОС, а язык подбирается под это содержание. Можно, например, дать все на одном языке или диверсифицировать - дать все на разных; тут уже все зависит от вкуса и контингента: насколько хорошо студенты воспринимают новое.В целом, я считаю так: хороший план - это как хорошая песня: должна быть зажигательная музыка (общая концепция), актуальные слова (набор и содержание дисциплин), четкий ритм (последовательность и объем дисциплин), голосистое исполнение (преподаватели) и аудитория, которая способна это все благодарно воспринять (студенты). :)

Комментариев нет:

Отправить комментарий