В январском номере Communications of the ACM опубликована небольшая статья дяденьки Страуструпа о проблемах в преподавании информатики. Статья далеко небесспорная и конечно же сильно ориентированная на американское общество, но интересная и вполне актуальная и для нас. Перевод (несколько художественный, но близкий к оригиналу) предлагаю вашему вниманию и обсуждению, желающие его улучшить — welcome сюда

Чему нужно учить молодых программистов и зачем.

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

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

В чём проблема.

Во многих местах существует разрыв между тем, что нужно промышленности и тем, чему учат программистов в университетах. Вот например:

Знаменитый профессор информатики, гордо: «Мы не учим программированию, мы учим информатике.»

Менеджер из промышленности: «Они же не могут запрограммировать самую элементарную вещь!»

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

Другой профессор информатики: «Я никогда не программирую.»

Другой менеджер: «Мы не нанимаем выпускников кафедры информатики. Легче научить физика программировать, чем научить физике выпускников этой кафедры.»

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

Профессор информатики (о студенте): «Он получил работу в промышленности.»

Другой профессор информатики: «Жаль, ведь он подавал большие надежды.»

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

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

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

Но в последнее время мой компьютер что-то не зависал

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

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

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

Мои образы «промышленности» и «научного сообщества» близки к карикатурным, но я уверен, что все, у кого есть хоть капелька опыта, увидят в них отражение кусочка реальности. Моё восприятие — это восприятие промышленного исследователя и менеджера (24 года в лабораториях AT&T Bell, 7 из них как глава отдела), который провёл последние 6 лет в университете (на кафедре информатики инженерного факультета). Я много путешествую и каждый год веду серьёзные дискуссии с техническими и управляющими людьми из нескольких десятков компаний, преимущественно из США. Я считаю несоответствие между тем, что производят университеты и тем, что нужно производству, угрозой как для жизнеспособности информатики так и для вычислительной отрасли.

Разрыв между теорией и практикой

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

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

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

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

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

Грёзы о профессионализме.

«Компьютерная наука» (Computer Science, до сих пор в этом тексте переводимая как «информатика» — моё примечание) — это ужасный и вводящий в заблуждение термин. В основном она не о компьютерах и в основном это не наука. Скорее речь идёт об использовании компьютеров и о способах работы и мышления, подразумевающих вычисления («алгоритмический и вычислительный склад ума»). Она совмещает некоторые стороны науки, математики, и инженерии, часто с использованием компьютеров. Почти для всех занимающихся ею людей информатика является прикладной областью. «Чистая информатика», в отрыве от прикладного использования, обычно бесплодна.

В чём отличие между двумя людьми, конструирующими приложение, один из которых знает информатику, а второй является профессионалом в какой-нибудь другой области, например в медицине или в физике? Должно быть, первый в совершенстве владеет фундаментальными основами, «ядром» информатики. Что оно могло бы в себя включать? Большую часть устоявшегося курса информатики — алгоритмы, структуры данных, машинные архитектуры, принципы программирования, немного математики (в основном для логического и численного мышления) и компьютерные системы (операционные системы, например, или СУБД). Чтобы собрать все эти знания воедино и получить представление о том, как работать с большими задачами, каждый студент должен поучаствовать в нескольких групповых проектах (вы можете называть это элементарной программной инженерией). Существенно то, что между теорией и практикой должен быть баланс. Информатика это не только принципы и теоремы и не только тупое кодерство.

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

Опытные преподаватели могут воскликнуть: «Но ведь это невозможно! Какой студент сможет выучить всё это за четыре года?». Они правы: чем-то надо пожертвовать. Я предлагаю сделать магистерскую степень первой, дающей право практиковать в роли учёного-компьютерщика, причём настоящую магистерскую степень, а не бакалаврскую с прицепленным заключительным годом или двумя. Те, кто планирует в дальнейшем заниматься исследованиями будут, как всегда, стремиться получить степень кандидата.

Многие профессора возразят: «У меня нет времени программировать!» Я, однако, полагаю, что профессорам, обучающим студентов, желающих стать профессиональными разработчиками, следует найти время на программирование, а институтам найти средства на то чтоб таких профессоров вознаградить. Первичной задачей информатики должна стать помощь в производстве лучших систем. Вот вы бы доверили преподавание хирургии тому, кто много лет не видел ни одного пациента? А что бы вы подумали о преподавателе класса фортепиано, который никогда не трогал клавиатуру? Изучение студентом информатики должно выйти за пределы чтения необходимых книг, по направлению к совершенствованию своего приложения в целой системе и к ощущению эстетичности кода.

Я использую слово «профессионал». У него много значений и смыслов. В таких отраслях, как медицина и инженерия, оно подразумевает лицензирование. Лицензирование — тема очень тонкая и эмоциональная. Но ведь наша цивилизация зависит от программного обеспечения. Разумно ли, что кто угодно может поменять критическую часть кода, основываясь только лишь на собственном вкусе и корпоративной политике? Даже если и да, то будет ли это по прежнему разумно через 50 лет? Разумно ли, что программное обеспечение, от которого зависят миллионы людей, не имеет никакой гарантии? На самом деле проблема в том, что профессионализм, подтверждаемый лицензией, зависит от наличия большой массы общедоступного знания, инструментов и технологий. Лицензированный инженер может подтвердить, что здание было построено с использованием общепринятых материалов и технологий. Я не знаю как сделать то же самое для программного обеспечения при отсутствии общепринятой схемы компетентности в информатике. На сегодняшний день, я не знаю даже как выбрать группу людей для разработки лицензионного экзамена (или, более реалистично, набора экзаменов для разных специализаций, по подобию медицинской комиссии).

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

Промышленный менеджер: «хочешь выжить — никому не показывай свои технические способности»

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

Заключение.

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