НовостиОбзорыСобытияIT@WorkРеклама
Идеи и практики автоматизации:

Блог

Вспоминая о Эдварде Йодане – о человеке, который превратил программирование из искусства в технологию

Только на днях узнал, что 20 января этого года скончался Edward Yourdon, как характеризует его английская Википедия – американский софтверный инженер, компьютерный консультант, автор и лектор, а также – пионер в области методологии проектирования ПО. В последние годы его фамилию переводили в российской печати, как Йордан, но я будут использовать написание, которое использовалось в первом переводе его классической работы "Структурное проектирование и конструирование программ", выпущенной издательством "Мир" в 1979 году ("Techniques of Program Structure and Design", 1975).


Эдвард Йодан в 1970-х. Когда он писал свою знаменитую книгу, ему было всего тридцать лет
[spoiler]
Написать же этот текст меня заставило то, что именно этого человека я всю жизнь считал и считаю сейчас своим главным учителем в области создания ПО. И даже не только учителем, но и соратником, хотя я нисколько не хочу приравнять результаты своей работы к его вкладу в развитие методологии программирования. Но я бы обрисовал ситуацию конца 70-х годов так: вы идете дорогой первопроходцев по неизвестным местам, методом проб и ошибок, не будучи до конца уверенными, что движетесь в нужном направлении. И вдруг вы находите книгу, которую написал человек, намного более опытный, уже прошедший этот путь. Вы получаете подтверждение того, что вы шли правильно и делали при этом правильные вещи, и там же подсказывает, как нужно двигаться вперед в дальнейшем. И возможно, что даже это было не самым главным. Наверное, самое важное было то, что вы понимаете, что вы – не один такой, что таких людей, которых волнует, как повысить эффективность и качество разработки ПО – много, и главное – это нужное дело…

"Мы все учились понемногу…"

Признаться, что когда я слышу разговоры о высоком качестве высшего образования советского времени, это вызывает определенное недоумение – на основе чего делаются такие выводы? Я поступил в 1970 году на факультет "Кибернетики" МИФИ и закончил его ва марте 1976 года, получив специальность "инженер-системотехник". Образование МИФИ в те времена считалось одним из лучших в СССР, этот касалось и "вычислительных" профессий. Как его можно было соотнести в зарубежными аналогами сказать невозможно из-за отсутствия возможно провести такое сравнение. Но то, что это образование было довольно странным – это совершенно точно. По большому счету о своей будущей специальности мы ничего не знали! Это стало понятно сразу же после окончания вуза. Разумеется, это мое субъективное мнение, но все же – мнение совсем не студента-троечника (и даже не "хорошиста"), основанное на анализе ситуации.

Такое впечатление, что вуз сам не очень представлял специалистов какого профиля (я, разумеется, имею в виду направление ИТ) готовит и чему именно их нужно учить, поэтому в условиях такой неопределенности применял классический подход: делать акцент на фундаментальные предметы и взыскательный спрос на экзаменах. Такой же метод применялся в классическом образовании России до самого начала 20-го века: латынь и греческий язык в реальной жизни никому тогда уже не был нужен, но такая "яыковая подготовка" была отличным тестом, чтобы отсеят "непригодных", и создавала для тех, кто ее выдерживал, мощный фундамент для будущего развития. У нас в МИФИ эту роль выполняли высшая математика, физика и целый ряд других дисциплин, сформировавшиеся в "старые времена" – начертательная геометрия, термех, сопромат, электротехника и пр. Специальные предметы начались у нас только на последних двух курсах, но после прохождения испытанием ТФКП (теория функции комплексной переменной), урматами (уравнения математической физики) и ФЭП (физика электронных приборов) это выглядело почти как каникулы...

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

Кажется, единственная попытка дать нам представление о современной ИТ-архитектуре было предпринята в последнем учебном семестре на пятом курсе (на примере архитектуры и системы ПО IBM 360), именно там мы впервые услышали термины "операционная система" и "супервизор", но, кажется, этот курс ни у кого не оставил особых следов, поскольку уже царило настроение "Ура! Скоро этому аду в виде экзаменационных сессий наступит конце!".

1970-е – радикальная трансформацация советской ИТ-отрасли

Впрочем, тут нужно сказать, что такая система обучения имела смысл и объективное обоснование, особенно тогда. Ведь именно на рубеже 1960-70-х советская ИТ-отрасль (слова "ИТ" и "компьютерная", тогда не было, это называлось "вычислительная техника") переживал этап радикального структурно-технологического преобразования ("трансформации" – современным языков), перехода от этапа "натурального хозяйства" (сделай все сам на одном предприятии, начиная от металлического крепежа до трансляторов) к промышленному производству ИТ, на базе системы разделения труда и интеграции в мировое ИТ-пространство (хотя интеграция было весьма условной, односторонней – использование западных идей и технологий). Кстати, тут нужно сказать, что об ИТ-ситуации в зарубежном мире, мы во время обучения в МИФИ вообще ничего не знали – эта тема отсутствовала в нашей программе обучение "как класс".

Так что, начало 70-х в советской ИТ-сфере можно сравнить с ситуацией в конце 1920-х в кинематографе (это хорошо описано в "Золотом теленке"), когда немое кино уже умерло, а звуковое еще не родилось... Вот и мы, студенты-кибернетики того времени, попали в период между уже умершими идеями и еще неродившимися, и потому лучшим вариантом было просто изучение классических дисциплин прошлого века (надо было бы еще и "латынь"). Кстати, отражением этой сиутации стало переименование в 1972 году нашего факультета с "Вычислительных устройств" на "Кибернетики", но в тот момент, это была, скорее, декларация о намерениях, но пока еще не реализация коррекции программы обучения на практике. Отражением этого сумбура в нашем специальном образовании стало то, что, хотя нас явно готовили с ориентацией на разработчика аппаратных средств, не менее 80-90% выпускников нашего потока в реальности потом занималось программированием.



"Забудьте, обо всем, чему вас учили в институте…"

То, что о собственно вычислительной специальности мы получили в вузе довольно слабое представление, стало понятно сразу после выхода из стен МИФИ. Уже после обучения (одного из лучших в СССР) мы узнали такие понятия, как "системное и прикладное ПО", "драйверы", "система операций ввода-вывода", "классы ЭВМ", "системы реального времени", "модемы и каналы ввода-вывода", "библиотеки подпрограмм", "управление процессом разработки" и многое другое, включая названия выпускавшихся тогда ЭВМ. Кстати, если говорить о программе обучения в вузе, то очень полезным был бы (и тогда и сейчас) предмет "основы делопроизводства, учета материальных ценностей и подготовки научно-технических документов") – уже через три года мне пришлось глубоко освоить эти дела, параллельно с программированием и исследовательской работой. Кстати, до начала перестройки в конце 80х, такого понятия как "цена ЭВМ" вообще практически не существовала, стоимость техники (даже приблизительно) не знали даже профессионалы. ЭВМ была "фондируемой" продукцией, ее не покупали, а получали.

На мой взгляд, ситуацию в вычислительных отделах времен середины 70-х, хорошо иллюстрирует анекдот (вполне реальная ситуация) той поры. Руководитель группы программистов приходит к начальнику вычислительно центра и говорит: "Нам нужен новый транслятор". Начальник достает план ВЦ и отвечает: "Я понимаю, что нужен. У нас и фонды есть. Но нет места! Посмотри сам (показывает схему размещения оборудования) – куда я его поставлю?"

После вуза я попал в вычислительный отдел крупного научно-исследовательского закрытого предприятия, радиоэлектронного профиля с полным производственным циклом с выпуском законченных для использования изделий. ЭВМ использовались, в основном, для сугубо расчетных задач (машинное проектирование и что-то по бухгалтерским делам), но как раз в этом вычислительное направление переживало и тут "трансформацию". Началась смена поколения техники ("Минск-22/32" и "М-220") на M-6000/7000, EC, СМ, и главное – расширился круг ИТ-задач, он вышел на качественно новый уровень. Речь шла, в частности, о реализации комплексных АСУ (прообраз будущих ERP) и о создании программно-аппаратных систем реального времени, когда ЭВМ централизованно управляет периферийной специальной аппаратурой, поддерживая при том многотерминальный доступ с разных рабочих мест с разграничением по ролям и правам доступа.

И тут пришла помощь, откуда не ждали!

Сейчас эти задачи выглядят обыденными, но тогда это было что-то вроде начала производства автомобилей на предприятии, ранее делавшем только конные дилижансы. Старые кадры к таким задачам были не очень готовы (да и кадров-то почти не было), массово приходивших выпускников вузов этому не учили. Но именно "зеленым" инженерам пришлось осваивать "инновации" и браться за решение качественно новых задач, уже через 2-3 года некоторые из них оказались руководителями новых направлений и проектов. Это был сложный и очень интересный процесс изучения отраслевого опыта (в том числе, хотя и немного – зарубежного), самостоятельного освоения средств и даже "придумывания" собственных. Начав после вуза с индивидуального написания относительно небольших вычислительных программ, мы довольно быстро вышли на задачи создания больших и сложных (неоднородных) программных систем, управления жизненным циклом программных решений и управления коллективной разработкой. Ничему этому нас в МИФИ не учили, все это проходилось осваивать во многом, придумывая сами, методом проб и ошибок. Но как раз тут мы получили мощную теоретическую, методическую и моральную поддержку со стороны зарубежных ИТ-авторов! Я бы особенно хотел выделить слово "моральную", поскольку там мы нашли подтверждение своим собственным, зачастую интуитивным, "находкам" и важные аргументы на наших спорах с начальством о реализации новых идей (в том числе организационных).




Здесь стоит напомнить, что с конца 1960-х, в стране в области ИТ началась реализация курса на "движение в фарватере передовых западных ИТ" (это реально позволило несколько сократить нараставшее отставание страны в этой сфере), а в начале 1970-х наступил период "разрядки" (потепление отношений с Западом, переход к сотрудничеству). Следствием этого стало появление в СССР переводных изданий (в издательстве "Мир") ведущих зарубежных ИТ-авторов. Роберт Кнут ("Искусство программирования"), Джеймс Мартин ("Системный анализ передачи данных"), Эдсгер Дейкстра ("Структурное программирование"), Фредерик Брукс ("Как создаются программные комплексы или мифический человека месяц"), Эдвард Йодан ("Структурное проектирование и конструирование программ"). Это были наши реальные "университеты"!

Среди этих автором хотелось бы особенно отметить Брукса и Йодана, которые в своих работах (у первого основной темой была организация процесса разработки, у второго – методика программирования) связали опыт и теорию с реальной практикой, дав при этом вполне конкретные рекомендации и руководства к действию. При этом обе книги были написаны прекрасным, легким и понятным языком (спасибо, специалистам-переводчикам, в частности, Леониду Абрамовичу Теплицкому!), не сухим научным стилем, а в виде увлекательной беллетристики, когда новые и непростые вещи объясняются с использованием простых, образных аналогий. Чего стоит один только рассказ Йодана о приключениях суперпрограммиста (в первой главе, где обсуждает, что такое "плохая" и "хорошая" программа и "плохой" и "хороший" программист, серьезные вопросы весьма актуальные и сегодня), которой мог бы занять достойное место в произведениях Марка Твена или Джером Джерома. Тогда (да и потом) я порой перечитывал книгу Йодана просто потому, что это было увлекательное чтение.

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

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

Тема структурного программирования сопровождалась тогда дискуссиями по дискуссиями по языкам программирования, в том числе на предмет "хороших" и "плохих" языков, в том числе с точки зрения создания больших и сложных программных систем, и возможности использования структурных методов. Самым "плохим", разумеется, был ассемблер и его неограниченными возможностями по запутыванию программного кода, позицию перед ним занимал Фортнан. А примером хорошего был Алгол, изначально созданный на базе идей структурированного код, именно его использовали чаще всего в публикациях по этой теме, в том числе и Э. Дейкстра. А Э. Йодан в своей книге показаывал все структурные методы на примере четырех языков – ассемблера, Фортрана, Алгола и PL, наглядно демонстрируя при этом, что нет плохих языков программирования, а есть плохие методы и программисты.

Это особенно было важно для нашей команды, поскольку мы программировали на мини-ЭВМ с очень ограниченными аппаратными ресурсами (объем оперативной памяти – 64 Кб), и потому все писалось на ассемблере. К моменту выхода книги (1979 год) мы уже выработали собственную методику программирования (в том числе целый набор внутренних требований – как писать и оформлять код), но работа Йодана подвигла нас на дальнейшее развитие в этом направлении.

В общем: спасибо Эдварду Йодану! Он помог нам тогда в освоении современных методов программирования и наглядно показал, что о самых сложных вещах можно рассказывать интересно и увлекательно!
Виктор Воронков
Вы может за деньги сообщаете имена программистов?
Или Вам не хочется, что бы у них была слава деньги и женщины?

Колесов Андрей
И за деньги не могу :-)
Я на этом заканчиваю разговор в этой ветке.
Виктор Воронков
Это же надо так Вам ненавидеть знакомых программистов, что бы препятствовать их известности.
На это я заканчиваю о чем-то спрашивать Вас.