Чему Мы Должны Учить Новых Разработчиков Программного Обеспечения? Почему?

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

Менеджер по производству: «Они не умеют программировать».

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

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

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

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

Обе точки зрения имеют смысл, но в идеале обе точки зрения были бы в корне неверными.

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

Разумеется, я не говорю о физиках, которые приложили значительные усилия к изучению информатики — такое сочетание навыков входит в число моих идеалов.

Профессор К.

Н.

(о студенте): «Он принял приглашение работать в отрасли».

Другой профессор КН: «Жаль, он был таким многообещающим».

Это несоответствие лежит в основе многих проблем и затрудняет попытки их решения.

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

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

Однако многие выпускники по сути не имеют образования или практики в области разработки программного обеспечения, кроме своих увлечений.

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

Кроме того, многие учащиеся не могут связать то, что они изучают на одном уроке, с тем, что они изучают на другом.

Таким образом, мы часто встречаем студентов с высокими оценками по алгоритмам, структурам данных и технологии программирования, которые, тем не менее, понимают все тонкости на уроках операционных систем, не принимая во внимание структуры данных, алгоритмы и структуру программного обеспечения.

В результате получается плохое представление не поддающегося расшифровке беспорядка.

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

Понятия «техническая поддержка» и «качество кодирования» обычно забываются или плохо понимаются.

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

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

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

Сама структура кода иногда менялась, но не всегда в лучшую сторону.

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

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

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

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

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

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

Точно так же есть преподаватели, которые выступают за разделение теории и практики.

Они также заслуживают похвалы и активной поддержки.

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

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

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

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

Моя точка зрения — это точка зрения промышленного исследователя и менеджера (24 года в AT&T Bell Labs, 7 из них в качестве руководителя отдела), который уже провел 6 лет в академических кругах (на кафедре SC инженерной школы).

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

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

Во многих организациях, которые полагаются исключительно на вычислительный процесс, уровень технических навыков стал опасно низким.

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

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

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

Позвольте мне отметить проблему масштабирования.

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

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

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

Это пустая трата человеческих способностей и усилий, поскольку она сводит всех к наименьшему общему знаменателю.

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

Они хотят иметь возможность работать с минимально квалифицированными и взаимозаменяемыми разработчиками во главе с несколькими «мечтателями», которые слишком высоки, чтобы заботиться о нюансах качества программного обеспечения.

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

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

Поставщикам нужно что-то от своих разработчиков, помимо общности основных методов.

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

Конечные затраты колеблются, как и процент неудач новых проектов.

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

Частные методы работы с огромными программными базами данных, написанные устаревшими способами, не соответствуют этой модели.

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

Все это идеально подходит для постоянного совершенствования учебных курсов по четко разделенным учебным предметам.

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

Кто-то всегда говорит: «Если бы индустрия просто платила разработчикам достойную зарплату, проблем не было бы».

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

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

Это вытесняет наиболее компетентных людей из этой области и не позволяет студентам войти в нее.

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

КН изначально не был посвящен компьютерам и изначально не был наукой.

Скорее, речь идет о пользователях компьютеров и о том, как работает мышление, включающее вычисления («алгоритмическое и количественное мышление»).

Он сочетает в себе черты естественных наук, математики и техники, часто с использованием компьютеров.

Практически для всех людей в КН это прикладная сфера - «чистая КН», отделенная от прикладных приложений, обычно неэффективна.

Что отличает специалиста по CS, разрабатывающего приложение, от профессионала в какой-либо другой области (например, медицины или физики), разрабатывающего то же самое? Ответ должен быть «прекрасно зная суть CN».

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

).

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

Баланс между теорией и практикой имеет основополагающее значение: КТ — это не только принципы и теоремы, и это не просто взлом программы.

Очевидно, что эта сущность гораздо более «компьютерно-ориентирована», чем компьютерная сфера в целом.

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

Однако этого все еще недостаточно.

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

.

Опытные преподаватели заметят: «Но это невозможно! Вряд ли какой-нибудь студент сможет освоить все это за четыре года».

.

Эти учителя правы: что-то придется изменить.

Я предлагаю, чтобы первой степенью для специалистов в области компьютерных наук была степень магистра - степень магистра как законченная степень магистра - а не степень бакалавра с дополнительными одним или двумя годами обучения.

Люди, планирующие заниматься исследовательской работой, как обычно, будут стремиться к получению степени доктора философии.

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

Конечная цель KN — помочь создавать более совершенные системы.

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

Я использую слово «профессионал».

Это слово со многими значениями и скрытыми значениями.

В таких областях, как медицина и технологии, это предполагает лицензирование.

Лицензирование – очень коварная и волнующая тема.

Однако наша цивилизация зависит от программного обеспечения.

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

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

Поскольку общепринятой концепции КТ-компетентности не существует (как я предлагал ранее), я не знаю, как применить ее к компьютерным программам.

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

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

Ведь образовательные учреждения имеют относительно стандартизированные структуры и относительно стандартизированные подходы к достижению целей.

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

Поэтому я даже не могу начать назначать лекарства.

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

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

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

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

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

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

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

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