CC BY
31
№ 1 (37) 2012
В. В. Артюхин, канд. экон. наук, доцент, ведущий научный сотрудник ВНИИ ГОЧС, Москва
И. А. Семёнов, заместитель начальника отдела Интерфейсов и приложений ООО «Контент Мастер», Москва
Обучение программистов:
подход на основе парадигмы специалиста
Перед тем как планировать учебный процесс и наполнять его конкретными языками программирования, библиотеками и методиками, имеет смысл определиться с тем, выпускника какого типа вуз желает в итоге подготовить. Авторы работы предлагают подход на основе парадигмы специалиста, который позволяет решить эту задачу и может применяться совместно с другими подходами.
Введение
Существует немало подходов к выстраиванию учебного плана высшего профессионального образования по специальностям и направлениям,связанным с информационными технологиями (ИТ). Рассмотрим некоторые из них.
Формальный подход заключается в неукоснительном соблюдении требований государственного образовательного стандарта (ГОС) по соответствующей специальности или направлению. В этом случае наполнение дисциплин и курсов включает то и только то, что есть в стандарте — не больше, не меньше. В той же части, где стандарт предоставляет вузу свободу, план формируется исходя из того, какие преподаватели имеются в вузе. Целенаправленная «разведка» рынка труда и тенденций развития ИТ не осуществляется (а это сама по себе сложная научная работа — спрогнозировать, что будет нужно знать специалисту через 5 лет), работа по организации взаимодействия с отраслевыми компаниями не проводится (или проводится эпизодически, например в преддверие студенческой практики, бессистемно, для галочки). Формальный подход бесконечно далек от совершенства во многих отношениях и по многим причинам.
Подход на основе технологий. В этом случае во всем, что связано с ИТ, учебный план условно разделим на две большие час-
ти: базовую (или «безопасную») и оперативную («продвинутую»). Базовая часть включает такие дисциплины, как «Архитектура вычислительных систем», «Программирование на языке О», « Объектно-ориентированное программирование» и т. п. Это «безопасные» дисциплины, потому что из года в год и из десятилетия в десятилетие их состав не меняется, а наполнение может изменяться, но нефундаментально, незначительно. Оперативная часть учебного плана собирается из дисциплин-фрагментов на основании того, что актуально «сегодня» (в этом году, десятилетии, в этой части света), и данные дисциплины могут полностью заменяться или обновляться, хоть каждый год. Проблема в том, кто и как определяет актуальность той или иной технологии или тематики и на основании каких данных. Источники информации здесь могут варьироваться от результатов реальных исследований и опыта работы в отрасли ответственного за план сотрудника (или сотрудников: декана, его заместителей, заведующих профильными кафедрами и их преподавателей) до заметок в интернет-изданиях и программных заявлений политических деятелей («Нанотехнологии!», «Суперкомпьютеры!» и т. д.). Есть и другая проблема: составители учебных планов — деканы, заведующие кафедрами и преподаватели — часто забывают о том, что компьютерные науки во многом вышли именно из университетской, научной среды. И по сей день на этих людях
№ 1 (37) 2012
лежит ответственность не только за следование в построении учебного процесса мейнст-риму, но и в значительной степени за определение мейнстрима — перспективных направлений развития ИТ [1]. Ведь реальный сектор, отраслевые компании интересуются тем, что им известно, что является их специализацией, и лишь немногие из них, а именно крупные и богатые, могут позволить себе проведение собственных исследований и открыть что-то по-настоящему новое. Вообще, как правило, по-настоящему новое — это идея или видение одного человека, которое уже потом может стать или не стать специализацией ИТ-компании [2].
Подход на основе стандартов совмещает некоторые элементы первых двух описанных подходов, имеет вытекающие из этого достоинства и недостатки. В качестве источника информации для определения состава дисциплин учебного плана и их наполнения берется некий отраслевой или образовательный (в дополнение к ГОС, которому нужно следовать обязательно) стандарт, и этот стандарт или стандарты важно правильно выбрать — стандарт может быть российским (например «Профессиональные стандарты ¡5 в области ИТ» разработки АП КИТ [3]) или | международным («Учебный план по компью-| терным наукам 2008» — англ. Computer Sci-| ence Curriculum 2008 [4], «Руководство к своз ду знаний по программной инженерии» — <s англ. Guide to Software Engineering Body of Ц Knowledge, SWEBOK производства ACM | и IEEE CS и т. д. [5]). Стандарт бывает так-§ же декларативным (описывающим, что дол-§ жен знать специалист) или императивным
5 (описывающим, чему нужно учить студента), Ц слишком общим или чрезмерно конкретным, g он может быть ориентирован на применение «¡5 в учебном процессе или отражать исключи-g тельно текущие, даже сиюминутные потреб-Л ности ИТ-компаний, а люди, которые его со-
6 ставляли, могли разбираться в специфике & образования в разной степени.
| Ориентирование на клиентов. Конечно, сначала нужно определить, кого учебное ¡§ заведение считает своим клиентом и, если
таковых несколько (а так оно на самом деле и есть), упорядочить их по степени важности. Клиентами вуза являются и студенты, и отраслевые компании, и государство, и человечество в целом. При этом у клиентов разная мотивация и критерии оценки работы вуза:
• Студенты хотят, чтобы учиться было интересно, чтобы можно было научиться такому, чего в книгах не прочитаешь, а по окончании вуза (или уже на старших курсах) к ним выстраивалась очередь из работодателей.
• Отраслевые компании хотят, чтобы на рынке труда присутствовали специалисты, чьи компетенции подходят под текущие проекты, при этом желательно в достаточном количестве, чтобы было из кого выбирать.
• Государство, при наличии внятной политики в области ИТ, обязано прогнозировать, какие специалисты понадобятся через год, два, пять, десять лет и далее.
• Человечество должно развиваться, и кто-то должен определять направления развития, в том числе в области ИТ.
При использовании последнего подхода разработчикам учебных планов необходимо учитывать, что прогнозный горизонт у клиентов разных групп отличается, а потому, выстраивая образовательную траекторию, нужно действовать на различных уровнях, предусматривая возможность оперативной замены или обновления тех или иных ее отдельных элементов или целых «веток».
Все упомянутые подходы имеют свои достоинства и недостатки, не исключают друг друга и чаще всего применяются в определенных комбинациях, а не эксклюзивно (в любом случае от ГОС полностью уйти невозможно).
Однако когда говорим о специалистах вообще и специалистах в области ИТ в частности, мы склонны характеризовать их с точки зрения либо компетенций (или знаний, умений, навыков, что то же самое), либо конкретных технологий (C++, ASP.NET, Oracle, 1С, OpenGL, Unix и т. д.), которыми они вла-
№ 1 (37) 2012
деют. Это немаловажные характеристики, но их недостаточно — когда речь идет о специалисте в той или иной области, существует еще один уровень, уровень выше конкретных компетенций или технологий, и только на нем можно ответить на вопросы: как будет развиваться специалист, работу какого характера он будет выполнять и насколько универсальным он будет? Речь идет о парадигме специалиста.
Слово «парадигма», пришедшее из греческого языка, в разных областях имеет следующие определения:
• в грамматике — таблица форм склонения и спряжения слов [6];
• в риторике — пример, взятый из истории и приведенный с целью сравнения [7];
• в науке — совокупность фундаментальных установок, представлений и терминов, принимаемая и разделяемая научным сообществом и объединяющая большинство его членов, обеспечивает преемственность развития науки и научного творчества [8];
• в философии науки — совокупность явных и неявных (и часто не осознаваемых) предпосылок, определяющих научные исследования и признанных на данном этапе развития науки, а также универсальный метод принятия эволюционных решений, гносеологическая модель эволюционной деятельности [9];
• в программировании — совокупность идей и понятий, определяющих стиль написания программ [10].
В этом случае парадигму специалиста определим как совокупность собственных представлений специалиста, а также работодателей о профессии программиста и разновидностях выполняемой им деятельности, о методах получения новых компетенций, о степени глубины и широты познаний в той или иной области (технологии или группе технологий, методах решения определенных типов задач) и о степени универсальности специалиста.
Приведенное определение значительно шире и глубже, чем список компетенций, чем то, которое обычно включают в профес-
сиональные стандарты и описания вакансий, хотя у представителей работодателей, § в особенности компаний, непосредственно ^ занимающихся разработкой программного га обеспечения (ПО), представление о пара- | дигме нужного специалиста часто имеется. § Конкретная парадигма может быть описана ^ разными формулировками, вплоть до емко- ^ го: «умен и доводит дело до конца» [11].
Следует отметить, что парадигма специалиста не имеет ничего общего с парадигмой обучения: последняя часто используется в научных трудах, но представляет собой не гипотетический портрет будущего специалиста, а абстрактный пейзаж учебного процесса (методы, технологии обучения, компетенции преподавателя). Образовательная парадигма (или парадигма обучения) касается того, как сформировать специалиста с определенным известным набором характеристик, но не того, как составить этот набор.
Два примера парадигм программиста
Рассмотрим для примера две парадигмы программиста. Назовем их условно «шахтер» и «коммивояжер». Каждая из них определяет круг людей, занятых в сфере разработки ПО. Однако они по-разному воспринимают свою профессию и прогресс в ней, неодинаково решают задачи, оценивают свою пригодность или непригодность в отношении вакансий, изучая их описания и т. д. За предлагаемыми примерами стоят реальные люди — авторы этой статьи.
В шахте добывают один либо несколько видов полезных ископаемых, которые соседствуют в силу схожести условий образования и могут находиться на разной глубине. Программист-«шахтер» в процессе обучения или на начальном этапе своей карьеры выбирает некоторое интересное для него направление работы, в которую и углубляется. Таким направлением, определяющим значимый для него круг задач, может быть компьютерная графика, разработка нетривиальных алгоритмов, высоконагрузочных приложений для серверов, разработка веб-сайтов
№ 1 (37) 2012
того или иного типа (на базе какой-то одной или нескольких близких по возможностям технологий) и т. д. Другим вариантом является углубление в конкретный язык программирования или технологию (например со всеми их нюансами и эволюционными изменениями. Специализация в части технологии часто сопровождается и специализацией в части решаемых задач.
Описанный подход к пониманию себя в профессии имеет следующий ряд преимуществ:
• программист-«шахтер» действительно глубоко знает свой предмет, часто является звездой компании-работодателя и имеет достаточно высокую заработную плату;
• если задача хоть как-то может быть решена с помощью известной ему технологии, он ее обязательно решит, а если она решается множеством способов, то он способен выбрать наиболее эффективный из них;
• он всегда знает, в каком направлении развиваться: если он занят непосредственно в разработке, то изучает (в том числе по книгам и другим материалам) возможности своих инструментов, а если получает повышение и становится управленцем — повы-
¡5 шает свою квалификацию в области управ-| ления проектами, оценке затрат и т. д.; Ц • у такого специалиста меньше проблем | с поиском работы, а точнее — с оценкой со-з ответствия своих компетенций конкретной <£ вакансии, чем у людей, соответствующих 1| иным парадигмам.
| Разумеется, имеется и ряд недостатков: § • ограниченность профессионального § кругозора при решении даже тривиальной задачи, выходящей за рамки известной про-Ц граммисту-«шахтеру» области, может при-§ водить к ее неразрешимости собственными Ц силами;
У • может проявляться тенденция к исполь-Ц зованию для решения задачи неподходяще-& го инструмента, т. е. технологии или языка & программирования (точнее, подходящих | меньше, чем другие, о которых он не знает ^ или знает, но недостаточно, или не считает сэ для себя подходящими);
• если специалист все же добавляет в свой арсенал некий новый для него язык программирования, существует опасность, что он будет проектировать и разрабатывать код так, как он делал это в старом привычном языке, следуя «букве», но не «духу» нового [12];
• иногда «шахтеры» склоняются к мнению, что быстрые и масштабные изменения в области ИТ в будущем могут оставить их «на обочине» («C++ через 20 лет будет таким, что я не смогу в нем разбираться» и т. д.).
По мнению Бьярне Страуструпа (создателя языка программирования C++), которое он высказал в интервью авторам данной работы на конференции CEE SECR 2010 в Москве [13], специализация является в настоящее время одним из важнейших аспектов обучения программированию. «Шахтеры» как раз и появляются в результате такого специализированного обучения и представляют собой спецназ в области разработки ПО.
Коммивояжер (от фр. commis voyageur) — это разъездной торговый агент какой-либо фирмы, предлагающий покупателям товары по образцам и каталогам. По аналогии про-граммист-«коммивояжер» имеет в своем арсенале множество инструментов разработки, которые осваивает в разной степени. Его отличает широта кругозора, постоянное отслеживание новых программных платформ и технологий, интерес к совершенно различным или сильно различающимся задачам.
Как и в случае «шахтера», парадигме «коммивояжера» присущи специфические достоинства и недостатки. Выделим следующие достоинства:
• широкий спектр известных инструментов позволяет программисту-«коммивояже-ру» быстро сообразить, какой из них или какое их сочетание можно использовать, чтобы быстро получить желаемый результат;
• «коммивояжеры» читают много материалов по ИТ (не только в части разработки ПО);
• новые задачи, с которыми подобный специалист не сталкивался ранее, его ни-
60 у
№ 1 (37) 2012
сколько не пугают (по крайней мере, до детального их разбора);
• профессиональный кругозор во многих случаях позволяет им по-новому взглянуть на старые задачи и найти более эффективное, неочевидное решение;
• способность работать не программистом (менеджером, научным сотрудником, бухгалтером), при этом применяя навыки программиста;
• «коммивояжер» вполне может быть звездой компании-работодателя, но только в том случае, если основная деятельность компании — не разработка ПО.
Обозначим недостатки парадигмы «коммивояжера»:
• несмотря на то что специалисту известны многие технологии и языки программирования, его квалификация в отношении каждого конкретного инструмента может быть совершенно различной: от достаточно глубокого до поверхностного знания (на уровне написания программ типа Hello, world!), поэтому действительно сложная задача, требующая применения конкретного инструмента и знания его нюансов, окажется для программиста-«коммивояжера» неразрешимой;
• по каждой отдельно взятой технологии или языку программирования «коммивояжеры» редко достигают той глубины знания, которой обладают специализированные «шахтеры»;
• у подобных специалистов часто возникают проблемы с поиском работы, поскольку: а) им интересно многое, но не что-то одно конкретное и б) могут присутствовать внутренние сомнения относительно профессиональной пригодности для конкретной вакансии;
• они могут испытывать трудности с профессиональным ростом, потому что зачастую непонятно, «куда стоит расти».
Приведенные парадигмы называют также «глубиной» и «широтой», соответственно. Разумеется, можно выделить значительно больше парадигм, чем две, распространены и смешанные варианты.
В качестве еще одного примера приве- ;| дем парадигму «Рантье». Слово «рантье» § (от фр. rentier от rente — рента) обозначает ^ человека, живущего на проценты с отдавае- ss мого в ссуду капитала или на доходы от цен- | ных бумаг. В случае программиста-«рантье» g речь идет о человеке, создавшем некоторый ^ продукт и впоследствии получающем от не- ^ го доход. Способы извлечения дохода могут быть разными: обучение работе с этим продуктом, создание компании, продающей и развивающей продукт, выполнение коммерческих заказов, т. е. разработки нового ПО на базе данного продукта и т. д.
Имеет смысл говорить даже не об однозначном соответствии специалиста той или иной парадигме, а о размере той и иной доли «шахтера», «коммивояжера» и т. д. (в частности, каждый программист в определенной мере мечтает стать «рантье»). На то, каким специалистом в области разработки ПО может стать человек, оказывают влияние многие факторы: его темперамент, как именно и когда он начал программировать, какой инструмент разработки был у него первым и т. д. К этому не имеют никакого отношения уровень интеллекта, наличие способностей и предрасположенности к занятиям программированием — можно быть как плохим «шахтером», так и плохим «коммивояжером». В данном случае важен ответ на вопрос: что именно введение понятия «парадигма специалиста» дает для организации учебного процесса?
Подход на основе парадигмы специалиста
Предлагаемый подход не имеет ничего общего с преподаванием «для одаренных» или «в расчете на средний уровень». Дело в том, что работающие «шахтеры» и «коммивояжеры», уже получившие некий опыт практической деятельности, ретроспективно неодинаково оценивают смысл и пользу от различных дисциплин и видов занятий, имевших место при обучении по специальности в вузе. По-разному отвечают они и на вопросы о своей работе (табл. 1).
№ 1 (37) 2012
Таблица 1
Примеры ответов программистов, преимущественно подпадающих под разные парадигмы специалиста
Примеры ответов
«Коммивояжер»
Как вы можете охарактеризовать свой рабочий профиль, т . е . описать, чем занимаетесь на сегодняшний день? Какое ПО вы используете и разрабатываете, каковы ваши функции?
Я — системный программист, специализируюсь на С++, но знаю и применяю несколько других языков .
Работаю в двух основных областях деятельности: мобильная разработка (телефоны, смартфоны, коммуникаторы и пр .) и серверная разработка для высоконагружен-ных решений . В ходе работы чередовал эти области, на последнем месте я их фактически сочетаю . В настоящее время основную часть рабочего времени я уже не пишу код, а ставлю задачи другим программистам, даю оценку и веду планирование работы, а также разработку архитектуры
В настоящее время я — ведущий научный сотрудник Центра анализа и управления рисками ВНИИ ГОЧС МЧС России1, занят разработкой прикладных научных методик, моделей и т .д . , а также автоматизацией, т .е . разработкой ПО для расчетов и анализа согласно этим методикам и другим научным результатам . Задачи возникают различные: от разработки простых вычислительных программ до программ составления отчетов на базе анализа больших объемов данных и имитационных моделей, поэтому применяются разные инструменты: от C++ и программ, написанных с нуля или на базе библиотек (например, Pilgrim 5), до Microsoft Access с Visual Basic for Applications и геоинформационных систем (например, esri ArcGIS в прошлом ArcView) . Я долгое время работал в сфере ИТ-образования, успел получить также опыт работы системным аналитиком (разработка систем дистанционного обучения), техническим писателем, специалистом технической поддержки
Какими технологиями, языками, методиками и т . д. вы владеете, в какой степени?
Языки:
• С++ — владею достаточно хорошо, основной рабочий инструмент;
• Python — знаком в общих чертах, на уровне написания несложных скриптов для обработки текстовой информации;
• Perl, PHP — когда-то был знаком, имею остаточные знания;
• C#, Java — знаком в самых общих чертах .
Технологии:
• мобильная разработка — Windows CE / Smartphone / Mobile, PalmOS, Symbian, Brew;
• серверная разработка — Unix/Linux: pre-fork, threading, sockets, разработка приложений для работы под высокой нагрузкой;
• SQL — в общих чертах, на уровне стандарта SQL'92 .
Методики:
• Предпочитаю итерационную модель, TDD2, раннюю интеграцию
Языки:
• C++, C# — на сегодняшний день это два моих основных инструмента, владею уверенно;
• VB, VBA — раньше приходилось работать довольно часто, так что знание уверенное, сейчас применяю эпизодически при необходимости;
• Java, JavaScript, Perl — раньше приходилось применять несколько раз;
• Python, PHP, Ruby, COBOL и еще с десяток языков — базовые теоретические знания или навыки на уровне написания программ «Hello world!»
Технологии:
• компьютерная графика и интерактивные приложения — OpenGL, DirectX (достаточно давно не приходилось этим заниматься), но знания и навыки практической разработки обширные;
• имитационное моделирование — Pilgrim 5;
• разработка на платформе Microsoft Office (в том числе сложных больших приложений, таких как графические конструкторы) — Access, Visio, Excel, Word .
I
5
0
6
1
1 Федеральное государственное бюджетное учреждение «Всероссийский научно-исследовательский институт по проблемам гражданской обороны и чрезвычайных ситуаций МЧС России» (Федеральный центр науки и высоких технологий).
2 Test Driven Development — разработка, управляемая тестами. Процесс разработки ПО, базирующийся на многократном повторении очень коротких циклов разработки (создание провального теста, определяющего нужный функционал, написание кода, позволяющего программе пройти этот тест, рефакторинг кода).
62
№ 1 (37) 2012
Продолжение табл. 1
Вопрос Примеры ответов
«Шахтер» «Коммивояжер»
Методики: Проектирование взаимодействия «по Куперу» [14], водопадная или итерационная модель разработки в зависимости от размера проекта . Поскольку зачастую разрабатывается ПО для использования конкретными людьми и с конкретными целями, а не коробочный продукт для массового рынка, сложные методики и модели разработки не оправдывают себя с точки зрения финансовых и временных затрат
Какие дополнительные знания и навыки (не касающиеся непосредственно кодирования) у вас имеются? Знаком с теориями проектирования ПО, управления жизненным циклом программных продуктов . Немного знаком с теориями управления качеством, а также с управлением рисками Аналогично, плюс SW-CMM3, COCOMO4, ITIL5 (хотя в противоположность стандартам на интерфейсы считаю стандарты на процессы сомнительными с точки зрения полезности), метрики ИТ-услуг
Как эти компетенции приобретались в процессе учебы и работы,начиная с вуза? До вуза я знал Паскаль и немного C, в самых общих чертах представлял, что такое Ассемблер . В институте изучил C++ — это основное, что пригодилось в дальнейшем . Помогли также общие знания по теории баз данных (БД) и SQL . Первая серьезная работа познакомила меня с Perl, PHP и веб-технологиями в целом (в вузе тогда этого почти не преподавали, а то, что давали, было в минимальном, не годном к употреблению объеме) . Затем следующая работа была уже после окончания института — там я начал применять познания в C++ и познакомился с разработкой ПО под мобильные платформы . Потом новая работа — снова C++ и новые мобильные платформы Далее смена отрасли — разработка под Unix/Linux, институтские знания к этому моменту были практически утрачены, восстанавливал заново Ну и на нынешней работе объединились мобильные платформы и серверная разработка . Руководить учился самостоятельно До вуза я знал восемь диалектов Бейсика (Spectrum, Yamaha, G-BASIC, QuickBASIC и несколько других) . В институте изучил Паскаль, C, затем C++, Ассемблер, общие вопросы, связанные с разработкой БД, минимум по метрикам ПО, зачатки Perl . Во время обучения самостоятельно освоил Java, JavaScript, разработку приложений под Windows (WinAPI, MFC — это в 1996 г . , так что была необходимость осваивать самостоятельно, многие тогда еще ограничивались программами под DOS), Delphi, позднее Visual Basic . Волей случая я столкнулся с геоинформационными системами, было интересно изучить DirectX, а работа над диссертацией через несколько лет привела к изучению имитационного моделирования (Pilgrim 5), OpenGL и всего, что связано с графикой в общем и с визуализацией в частности. Работа в ИТ-образовании требовала широкого круга знаний — декан отвечает за специальность, значит в той или иной мере должен разбираться или хотя бы иметь представление по всем вопросам, которые затрагиваются учебным планом . Знания в области управления проектами, разработки документации, технической поддержки потребовались уже на следующей работе
Что, на ваш взгляд, было неправильным в учебном процессе вуза? В нашем обучении было много лишнего и многого явно не хватало . Самое неприятное, что не хватало многих вещей, которые могли бы быть наиболее качественно освоены именно в институте — т . е . в коллективе и в искусственных условиях . Сейчас, ретроспективно, кажется, что наибольшая проблема — отсутствие реальных задач . И дело не только в постановке: реальная задача всегда комплексная — нужно не только разработать алгоритм, но организовать взаимодействие с БД, создать интерфейс пользователя, вписать разработанное
3 Capability Maturity Model for Software — модель зрелости процессов разработки программного обеспечения.
4 Constructive COst MOdel — алгоритмическая модель оценки стоимости разработки программного обеспечения.
5 IT Infrastructure Library — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.
Продолжение табл. 1
I
S=
I
i §
£ о
8
I
I
0 &
1
It
Вопрос Примеры ответов
«Шахтер» «Коммивояжер»
И были явно лишние предметы, которые далеко не всем пригодятся или которые достаточно легко изучить самостоятельно . Примеры: основы документирования ПО (далеко не всем нужен этот формализм, легко изучить самому, без практики моментально забывается), экспертные системы (слишком узкая специализация, мало кому нужно), метрология и качество программного обеспечения (практической пользы мало, без практики моментально забывается) и т д С другой стороны, не хватало технологии разработки ПО, разработки через тестирование (TDD), освоения средств для работы в команде, принципов рефакторинга и т .д . То есть нас очень мало готовили к реальной программистской работе в команде Почти не объясняли, что такое качественный код и как его писать в какую-то уже имеющуюся систему, обеспечить вывод в файл определенного формата, приложить к программе ту или иную документацию и т . д .В реальных условиях существуют и ограничения на условия, в которых решается задача: жесткое ограничение по срокам, когда приходится выбирать инструмент, исходя из того, как можно решить задачу более быстро, а не более эффективно; работа в команде — распределение функций; работа только с определенными инструментами или наоборот выбор инструмента, технологии по определенным критериям и т . д. Не могу сказать, что я получил в вузе хоть какое-то представление обо всем этом
Что в вузе было действительно конструктивно? Хорошо дали базовые знания, основы программирования, аппаратную часть, C++, компьютерную графику и т д Вуз дает систему знаний Например, есть кодирование — скажем, это основной рабочий отрезок . А есть какие-то виды работы, аспекты слева, справа, до и после этого отрезка Вуз позволяет получить системное представление о работе программиста При этом конкретная система знаний, выстроенная вузом, может быть удачной или неудачной с точки зрения характера и конкретного места работы будущего специалиста, но, по крайней мере, система есть, а значит, проще добавлять в нее новые знания, сохраняя интегрированное представление об области деятельности в целом
Как вы выбираете стратегию обучения, т е язык, технологию, источник, которые следует изучить? Как правило, выбор обусловлен насущной необходимостью, т е появляется конкретная задача — я ищу в Интернете рекомендации по литературе, достаю, читаю, сразу же начинаю применять . После решения конкретной задачи, если интересно, продолжаю углубленное изучение Возможно два варианта: либо анализируется текущая предметная область и те задачи, которые приходилось и приходится решать, — происходит изучение подходящих для этого инструментов либо просто выбираются новые интересные технологии в расчете на то, что и они могут пригодиться (в научной деятельности часто приходится применять что-то новое или даже старое для решения новых задач)
Как вы относитесь к таким предметам, как философия, культурология, политология, история религий, и прочим, изучаемым в рамках институтской программы подготовки программистов? В разумных количествах подобные дисциплины однозначно полезны — человек должен быть развит разносторонне Программисты иногда любят пофилософствовать, к тому же им не вредит и отдых от компьютеров и математики
64
№ 1 (37) 2012
Окончание табл. 1
Что вы думаете об очень узко специализированных курсах и дисциплинах, например «Компьютерная коммуникация рисков в области тепловых взрывов», и подобных?
Примеры ответов
«Коммивояжер»
По-моему, таких дисциплин должно быть как можно меньше, в виде коротких практикумов или в рамках специализации . Главное, чтобы они не мешали основным предметам
Понятно, что у каждого вуза своя специфика, своя область, характерная для него в целом, и это накладывает отпечаток на состав и наполнение дисциплин — с этим ничего не поделаешь . В определенной степени дисциплины и курсы, о которых говорится, полезны — в их рамках можно ставить реальные задачи и вводить ограничения на процессы их решения . Однако целенаправленное или просто излишнее ограничение предлагаемых студентам задач, практикумов и тому подобного спецификой вуза опасно, поскольку в нашем мире далеко не все работают в той отрасли или области, которую вуз считает «своей»
о
t <2
5S
!
Si ^
со со
Отметим, что, помимо прочего, «шахтер» четче формулирует свои ответы, ему требуется меньше слов, но, с другой стороны, его попытку быстро разработать простенькую базу данных на Access может ожидать фиаско (если разработка таких приложений не входит в число областей его специализации).
«Коммивояжер» в данном случае «растекается мыслью по древу», его профессионализм растянут на множество предметных областей. Многословное описание своих компетенций иногда создает проблемы при поиске работы, причем за счет как объема выдаваемой соискателем в резюме информации (которая может попросту не вместиться в стандартную форму на сайте HeadHunter или подобном), так и ее содержания.
Обратим внимание на то, что на вопрос о рабочем профиле «шахтер» отвечает: «Я — системный программист», в то время как «коммивояжер» указывает предметную область, в которой на сегодняшний день он занят разработками. Завтра эта область может быть другой: сотрудник редакции, автоматизирующий работу с банком материалов и авторов, сотрудник деканата, модифицирующий систему управления данными о студентах, сотрудник ЖЭКа, создающий расчетные модули для выставления счетов и т. д. В таких условиях трудно разместить резюме: непонятно, к какой отрасли себя отнести. «Шахтер» за свою карьеру, ско-
рее всего, наберет несколько направлений, в которых он специализировался, причем они будут формулироваться в терминологии ИТ. «Коммивояжер» может набрать множество отраслей, в которых он работал в качестве разработчика ПО (разумеется, речь идет об экстремальных случаях «шахтера» и «коммивояжера» — смеси в определенных долях встречаются куда чаще).
Проведенный анализ позволяет также заключить, что на предмет реформации учебного процесса по ИТ в вузе бесполезно опрашивать всех выпускников в общем пуле (они вполне могут относиться к различным парадигмам и заниматься разработкой ПО, но совершенно по-разному), причем это касается не только изменений наполнения учебного плана изучаемыми языками и технологиями, но и доли, и содержания более общих дисциплин, таких как документирование ПО, тестирование, технологии разработки т. д.
Заключение
Введение понятия парадигмы специалиста позволяет в дополнение к рассмотренным в начале работы подходам к построению учебного плана и учебного процесса предложить еще один. Выделив наиболее существенные характеристики и определив специфику различных парадигм, оценив полезность тех или иных дисциплин и курсов для различных типов будущих специалистов,
можно заранее определиться с тем, какого специалиста мы хотим получить на выходе, и соответствующим образом построить план. Заметим, что определение парадигмы специалиста и соответствующий подход не зависят ни от популярных на сегодняшний день технологий, ни от исторического периода, ни от конкретных работодателей — и «шахтеры», и «коммивояжеры», и «рантье» будут востребованы всегда. К тому же предлагаемый подход не конфликтует с остальными, т. е. они могут применяться и совместно.
Парадигма специалиста имеет непосредственное отношение к популярной нескончаемой полемике на тему различий между теорией и практикой, образованием и работой — прежде чем оценивать масштабы различий, необходимо определиться с тем, что есть практика и работа. Сделать это в терминах технологий при нынешнем распространении и темпах развития ИТ невозможно — требуется дополнительный уровень абстракции. Полезно введенное понятие и при выработке критериев качества обучения: как показано в табл. 1, такие критерии различны у специалистов, преимущественно относящихся к разным парадигмам. ¡5 Знаменитому скульптору и художнику Ми-| келанджело приписывают известную фразу: Ц «Быть скульптором просто — нужно лишь | увидеть в мраморе душу и отсечь все лиш-
3 нее». Подход на основе парадигмы как раз
<£ и позволяет увидеть «душу» будущего спе-
1| циалиста, точнее, определить ее разновид-
■= ность.
£
о
| Список литературы
§ 1. Артюхин В. В. Реальность 2.0Ь. Современная ис-
4
|| тория информационного общества / В. В. Артю-
§ хин [Электронный ресурс] Информация для всех.
Ц Электрон. дан. 2011. Режим доступа: http://ifap.ru/
§ НЬгагу/Ьоок501^^ свободный. Яз. рус.
Ц 2. Полунов Ю. Л. От абака до компьютера: судьей
& бы людей и машин. Книга для чтения по исто-о
^ рии вычислительной техники в двух томах. Том
| II. М.: Русская редакция, 2004.
3. Профессиональные стандарты в области ИТ
<§ [Электронный ресурс] АП КИТ. Электрон. дан.
2011. Режим доступа: http://apkit.ru/committees/ education/meetings/standarts.php, свободный. Яз. рус.
4. Computer Science Curriculum 2008: An Interim Revision of CS 2001 [Электронный ресурс] ACM. Электрон. дан. 2008. Режим доступа: http://www.acm.org/education/curricula/ ComputerScience2008.pdf, свободный. Яз. англ.
5. SWEBOK V3 Review [Электронный ресурс] IEEE CS. Электрон. дан. 2011. Режим доступа: http://computer.centraldesktop.com/ swebokv3review/, свободный. Яз. англ.
6. Ожегов С. И. Толковый словарь русского языка / под ред. проф. Л. И. Скворцова. 27-е изд. испр. М.: Оникс — Мир и образование, 2010.
7. Иллюстрированный энциклопедический словарь Ф. Брокгауза и И. Ефрона. М.: Эксмо; Форум, 2007.
8. Парадигма [Электронный ресурс] Википе-дия. Электрон. дан. 2011. Режим доступа: http://ru.wikipedia.org/wiki/Парадигма, свободный. Яз. рус.
9. Парадигма (философия) [Электронный ресурс] Википедия. Электрон. дан. 2011. Режим доступа: http://ru.wikipedia.org/wiki/Парадигма_ (философия), свободный. Яз. рус.
10. Парадигма программирования [Электронный ресурс] Википедия. Электрон. дан. 2011. Режим доступа: http://ru.wikipedia.org/wiki/ Парадигма_ программирования, свободный. Яз. рус.
11. Спольски Дж. Джоэл о программировании и разнообразных и иногда родственных вопросах, которые должны быть интересны разработчикам программного обеспечения, проектировщикам и менеджерам, а также тем, кому посчастливилось или не повезло в каком-то качестве работать с ними. СПб.: Символ-Плюс, 2008. С. 165.
12. Страуструп Б. Язык программирования C++. 3-е изд. СПб.: М.: Невский диалект — БИНОМ, 1999.
13. Мини-интервью Бьерна Страуструпа [Электронный ресурс] МОО «Информация для всех». Электрон. дан. 2010. Режим доступа: http://www.ifap.ru/pr/2010/101020a.htm, свободный. Яз. рус.
14. Купер А., Рейман Р., Кронин Д. Алан Купер об интерфейсе. Основы проектирования взаимодействия. СПб.: Символ-Плюс, 2009.
66 у
