Pull to refresh

Чему мы должны учить разработчиков нового программного обеспечения? Почему?

Reading time 11 min
Views 3.2K
Original author: Страуструп
Требуются существенные изменения в обучении компьютерной науке, для лучшего соответствия потребностям индустрии.

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

Проблема

Во многих местах существует разрыв между обучением компьютерной науке и потребностями индустрии. Взгляните на следующую ситуацию:
Знаменитый профессор компьютерной науки (с гордостью): «Мы не учим программированию; мы обучаем компьютерной науке.»
Производственный менеджер: «Они не способны программировать.»

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

Другой профессор компьютерной науки: «Я не написал ни одной строчки кода.»
Другой какой-нибудь производственный менеджер: «Мы не принимаем выпускников факультетов Компьютерной Науки; легче обучить программированию физика, чем выпускника КН физике.»

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

Профессор КН (о студенте): «Он принял приглашение работать в индустрии».
Другой профессор КН: «Жаль; он был таким перспективным».

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

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

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

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

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

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

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

Несоответствие научных сообществ/индустрии

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

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

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

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

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

Мечты о профессионализме

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

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

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

Опытные педагоги заметят: «Но это невозможно! Вряд ли кто-то из студентов сможет овладеть всем этим за четыре года». Эти педагоги правы: что-то придётся изменить. Я предлагаю, чтобы первой степенью специалистов в области компьютерной науки была степень магистра – степень магистра как завершённая научная степень – не как степень бакалавра с дополнительными одним или двумя годами обучения. Люди, которые планируют проводить исследовательскую работу, будут как обычно стремиться к степени доктора философских наук.

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

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

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

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

Заключение

Мы должны стараться. Пока мы не начнём, наша инфраструктура будет продолжать скрипеть, разбухать и впитывать ресурсы. Постепенно, какая-нибудь часть сломается каким-нибудь непредвиденным и разрушительным способом (подумайте о Интернет рутинге, онлайновой банковской системе, электронном голосовании и управлении электросетью). В частности, мы должны сузить разрыв между образовательными учреждениями и индустрией путём перемен в обеих сторонах. Я предлагаю определить структуру обучения КН, основанную на ядре и специализациях и прикладных сферах, постепенно нацеливаясь на лицензирование некоторого программного обеспечения, по крайней мере некоторых профессионалов КН, которые его производят. Это может идти в совокупности с уклоном на повышение производственной/образовательной квалификации для технических экспертов.
Tags:
Hubs:
+27
Comments 47
Comments Comments 47

Articles