Каким должен быть язык программирования?	Анализ и критика	Описание языка	Компилятор
Отечественные разработки	Cтатьи на компьютерные темы	Компьютерный юмор	Новости и прочее

Программисты-профессионалы и программирующие инженеры

Ностальгическое, «Воспоминания советского программиста», автор — Самуил Любицкий. Киевлянин, всю жизнь проработавший в ИТ, начавший работать на ЭВМ ещё школьником в 1966 году. По его же словам, «инвалид пятой графы» (советские люди знают, что это такое), написал серию своих воспоминаний в 2009 г. На тот момент он работал программистом в Торонто. У него даже антисоветизм мягкий и советский. Ниже предлагается Вашему вниманию одна из его глав.

                                    * * *

            Машины МИР были хоть и довольно миниатюрными, но детищами своего времени: занимали, обычно, отдельную комнату и время работы на них распределялось между пользователями. Но вот что впрямь замечательно: пользователи эти не были программистами. Я, к примеру, за многие годы ни одной программы для этих машин не написал. И вообще, не знал ни одного программера, кто б на них работал; с другой стороны, все, кто писал программы для «миров», программистами не были. Тут читатель наверняка спросит: «как же так, программы писали, а программистами не были?» Поверьте, и тени профессионального снобизма у меня нет — это, действительно, разные виды деятельности. Ну, вот пример: простейшая программа прочностного анализа, скажем, расчет балки по формулам сопромата. Что напишет умеющий программировать инженер-расчетчик: две-три строчки — ввод исходных данных, две-три строчки — собственно вычисления и четыре-пять строчек — печать результатов расчета. Всей программы — десяток строк кода. И написание её займет от силы полчаса. Ну хорошо, если человек только осваивает компьютер, — два часа. А дальше инженер будет этой программой пользоваться всякий раз, когда ему надо посчитать балку.

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

            Обычно, к этому моменту «подследственный» начинает звереть и ерзать на стуле, а ведь мы, по-хорошему, ещё даже не начинали. Проверка на допустимые значения параметров по отдельности, это так… даже не разминка. Переходим к проверке соотношений параметров. Формулы сопромата для расчета изгиба балки базируются на допущениях теории Эйлера-Бернулли, коими не буду морить читателя, но скажу лишь, что результаты расчета хорошо согласуются с экспериментом, когда балка — действительно балка, т.е. нечто такое удлиненное по сравнению с сечением (но не слишком). Скажем, книжная полка: пролет метровый, а доска дюймовая. В самый раз. Или брус перекрытия пролетом шесть метров, с высотой сечения 20 см. Тоже нормально. А если мы восьмидюймовым брусом перекроем пролет в один фут, то это как? А это, извиняюсь, уже не балка будет и считать такую конструкцию (скорей похожую на стеновую панель) надо совсем по другим формулам. И если двухметровый пролет перекроем, к примеру, миллиметровым металлическим листом или затянем пленкой, как в теплицах, то это тоже не будет балкой и считать придется по формулам теории все того же вездесущего Леонарда Эйлера, только совсем другой теории — статики гибкой нити. Инженер все эти вещи «печенкой чует», он интуитивно классифицирует и выбирает метод расчета (а хороший инженер и считает-то «для очистки совести»; он заранее знает результат, моделируя работу конструкции — сопротивление материала — каким-то необъяснимым, помимо сознания, способом, но при этом — безошибочно и весьма точно; если он настоящий инженер, конечно).

            Увы, компьютер начисто лишен интуиции и все «входные» ограничения требует формулировать явно и однозначно. Даже для нашего примитивнейшего случая это далеко не просто… А кстати, мы тут оперируем метрами, сантиметрами, дюймами. А ведь для расчета все размеры надо привести в одну единицу измерения. В какую? В сантиметры? OK. И для входных данные считать, что все задано в сантиметрах? Ах, пусть пролет в метрах, а сечение в сантиметрах? А дюймы-футы? Ага, значит прежде задания размеров из меню выбирается система измерений: метрическая или имперская. А если пользователь ввел в метрах-сантиметрах, а потом решил пересчитать в дюймы-футы? Ага, вводим специальный пункт меню «пересчет». А может пусть указывает единицу измерения при каждом числе? Неудобно? Тогда, значит, пусть будут «правила по умолчанию», возможность выбора системы измерений из меню, режим пересчета, а дополнительно ещё чтоб можно было указать единицу измерения при любом индивидуальном размере. Уф! Теперь это все запрограммировать и будет… всего навсего будет ввод геометрических размеров. А ещё у нас есть ввод физико-механических свойств материала. Для простейшего изотропного линейно-упругого материала это два числа — модуль Юнга и коэффициент Пуассона. Наше счастье, что второй — безразмерный. Зато первый… та же головная боль с единицами измерений: континентальные килограммы на квадратный сантиметр или может имперские килофунты на квадратный дюйм, а то и вовсе новомодные мегапаскали. И всякие пересчеты между ними. Плюс, конечно, проверки на допустимые диапазоны значений (для обоих параметров) и диагностические сообщения в случае нарушений… А ещё у нас ввод нагрузки: проверки, игры с единицами измерений и пересчетами, диагностические сообщения… И это мы топчемся пока всего лишь на вводе данных. А потом ещё будет сам расчет, где программист, помимо двух строчек расчетных формул, будет долго и нудно специфицировать все мыслимые и немыслимые ошибки вычислений, реакции на них и опять же диагностические сообщения. Посчитав, наконец, приступаем к печати результатов. Так, во-первых короткая распечатка для рабочих нужд: вывод на экран или консольную пишущую машинку только чисел и минимальных обозначений при них. Теперь дальше: печать в табличной форме для многократных прогонов — чтоб сравнивать варианты. Эх, ещё бы графики-эпюры построить. Не беда, что не производятся пока графические принтеры и дисплеи — примитивные графики можно «рисовать» звездочками на текстовых принтерах. И ещё не все. Нужна «официальная», полная распечатка, которая будет подшиваться в проект со всеми, кстати, реквизитами проекта (которые тоже надо вводить, как и параметры, задающие форматирование и управляющие процессом печати)…

            Ну вот, вроде бы все. На собеседования с будущим пользователем программы ушел хорошо если один рабочий день, а то и два (это называется на нашем жаргоне «обследованием» или «постановкой задачи»). Думаете, теперь-то программист пошел программировать? Ха, как бы не так! Он пошел писать документ под названием «техническое задание» и хорошо, если сам наберет его на компьютере и там же отпечатает. Тогда за пару-тройку дней справится. А вот если он пишет от руки на бумаге, а потом печатают девицы из машбюро, тогда, считай, уйдет неделя. Затем документ читается и согласовывается пользователем (почти всегда при этом — уточняется, правится и переписывается). Наконец утверждается начальством и… всего лишь две-три недели спустя программист приступает собственно к программированию. Помните, что инженер уложился в десять строчек кода? Так вот, программисту со всеми этими проверками, диагностиками и пересчетами придется написать эдак строк двести-триста…

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

            Этого программиста-профессионала уподоблю шоферу-дальнобойщику, везущему многотонный груз за сотни километров. Можно, конечно, нанять его громоздкий трак для доставки пиццы на дом — почему бы нет, платите только денежки. Но даже в идиотских советских условиях такого идиотизма на наблюдалось… Ну вот, вроде ясно, осталось только понять, почему это у непрограммиста программа в десять строчек, а у профессионала — раз в двадцать-тридцать больше. Если бы нам за число строк платили, тогда конечно, никаких вопросов… Так ведь не было у нас выгоды накручивать строки в программе, как советскому водиле — километраж на тахометре его грузовика. Никто за размер программы, как таковой, не платил. И какая там выгода, одна головная боль — чем программа больше, тем она сложнее. Почему же так получалось? А все просто: инженер составляет себе машинную программу как подсобное средство, облегчающее расчеты. Ну вот, на логарифмической линейке считать ведь удобнее, чем «в столбик» на бумажке. А на калькуляторе — удобнее, чем на линейке. А на программируемом калькуляторе «с памятью» — ещё удобнее. А на компьютере — ещё… Соль в том, что считает по-прежнему сам инженер, используя программу (линейку, калькулятор) просто как инструмент. А ежели так, то нужен ли ему в программе миллион проверок? Нет, он сам все проверяет и контролирует. Интуитивно. Ему нет нужды вникать в детали расчета, достаточно взглянуть на результат и… все сразу ясно: правильный он или лажовый. Так что, нужна ему только голая «считалка» для трудоемкого расчета, которую он и запрограммирует за полчаса… А вот наш брат программист делает программу для расчета автоматического (это когда вообще без участия человека) или же автоматизированного (при участии «безответственном», например, клерка, который проверить результаты не в состоянии, ибо не знает сопромата; его самого контролировать надо, правильно ли исходные цифры ввел). У компьютера же, как известно, с интуицией напряг, он — очень быстрый и старательный идиот, тупо исполняющий команды. А мы — программисты — представляем интересы этого бедолаги в мире людей. Зная, что сам он не в состоянии предусмотреть аж ничего, решить «интуитивно» («по аналогии», «исходя из здравого смысла») аж никакой, самый крохотный вопросик, вынуждены мы с раздражающим педантизмом, со скурпулезностью нечеловеческой предусматривать самые нелепые, невозможные ситуации, искать ответы на самые дикие, кретинские вопросы. И все эти «а что если?» закладывать в программы, отчего те разбухают неимоверно — в десятки, в сотни раз…

            Коль уж зашла речь о ремесле программистском, затрону ещё одну его сторону. Внимательный читатель обратил внимание, что, учиняя допрос инженеру-расчетчику, я знал заранее какие ему вопросы задавать. Я знал про допущения теории Эйлера-Бернулли, про то, что расчет балки корректен при определенных соотношениях пролета и сечения. Предположим, что не знал, при каких именно (и спросил у об этом специалиста расчетчика), но знал, что надо спросить. Знал что надо спросить. Откуда знал — понятно: сам по образованию прочнист. Но ведь это — случайное совпадение. Вот приходилось мне потом работать в энергетике и полиграфии, на химических и металлургический заводах, в авиакосмической индустрии и торговле, здравоохранении и грузоперевозках. Но ведь невозможно перед каждым новым проектом проходить соответствующий университетский курс. Так как же знать что надо спрашивать? И встречный вопрос: а зачем знать что надо спрашивать? Не проще ли попросить специалистов, пусть они сами все расскажут, а ты старательно законспектируешь да и пойдешь себе программу писать… Не тут-то было…

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

            Что же делать? Не дергаться. Работать. Общаться с клиентами, стараться вникнуть в их проблемы, вжиться в их рабочую среду. Очень важен психологический настрой — ты служишь своим клиентам, стараешься сделать их труд продуктивнее и комфортнее. В начале проекта ты ничего не знаешь и смиренно учишься. Надутый высокомерный индюк, кичащийся своими учеными званиями (видывали и таких) не сделает ничего… Кто лучше знает работу стропальщика на складе, как ни стропальщик? Поэтому забудь (до поры) про свои два университетских диплома, надевай рукавицы и вперед… на склад на пару деньков, младшим помощником. Как обдерешь руки в кровь, как спину натрудишь, так сразу дотумкаешь, что такие красивые (в математической теории) схемы оптимальной нарезки кабеля упираются в ма-а-ахонькую проблемку — надобность ворочать с места на место тяжеленные барабаны, что без нужды никто делать не станет… и всей тут твоей оптимизации — карачун. Или садишься в отдел сбыта выписывать вместе с тамошними девчатами счет-фактуры и накладные. Как облает тебя покупатель разок-другой за нерасторопность, так поймешь, что нужно сделать для повышения расторопности бедняжек, которых ежедневно облаивают эти жлобы (а кто, ты думал, снабженцами работает — учтивые благородные джентльмены?)…

            Бесконечные командировки, дни и недели в цеху, заводоуправлении, на складе, в офисе бок о бок с инженерами, бухгалтерами, работягами, клерками — все это нужно не для составления программ (они и дома неплохо пишутся — знать бы, что писать) но для вживания. Понемногу, день за днем вникаешь в дотоле неизвестную жизнь и потихоньку её вербализируешь. Вот в этом (а отнюдь не в знании ФОРТРАНа) и заключается твоя профессия — укладывать живую жизнь в строгие параграфы бизнес-правил и спецификаций. И быть готовым терпеливо делать и переделывать, делать и переделывать, делать и переделывать… Никогда, ни разу за сорок лет моей карьеры не удавалось сделать проект с первой попытки. Делаешь и переделываешь. Не потому, что такой уж ты дурак. Отнюдь, и сам не дурак и коллеги твои — инженеры отменные. Просто, существует всегда эта пропасть непонимания — misunderstanding gap. Пока не покажешь клиенту работающий прототип, он и не знает, чего он не хочет. Показал — недолет! Прототип — в корзину, а ты работаешь дальше. Другой вариант — перелет! С третьего раза — в цель. Да только, пока ты идеально подгонял компьютерную систему под бизнес-процесс, сам бизнес-процесс и окружающий его мир изменились. Мочи мочало — начинаем все сначала. Зато не соскучишься…

            Мой опыт ограничивается маленькими группами разработчиков — артелями в три-четыре, максимум — семь человек. В больших коллективах, конечно, все не так. Там правит бал специализация. Программисты клепают программы, а описанной выше деятельностью занимаются особые люди — постановщики задач. Откуда же они берутся? Порой это специалисты в своем деле, которые участвовали, например, в разработке проекта в качестве «подследственных» специалистов, увлеклись делами компьютерными, хорошо вникли (вжились) в нашу проблематику. Работа постановщика — интереснейшая, да и по части оплаты… такие специалисты не бедствуют. Однако, чаще в постановщики приходят все-таки из программистов. Занимается, к примеру, человек лет двадцать разработкой бухгалтерских программ и потихоньку становится классным бухгалтером, оставаясь при этом классным программером. Вот он — мостик через пропасть взаимонепонимания, драгоценный «междисциплинарный» опыт. В начале 90-х, когда в Украине софтверные проекты сошли на нет, а в услугах бухгалтеров, напротив, нуждались вновь создающиеся фирмы, многие мои коллеги были вынуждены сменить род занятий и оказались очень востребованы в «бухгалтерском» качестве. Ну, а в стабильной стране программист, доработав до благородных седин (сиятельной лысины), уходит в постановщики — оно и спокойней и денежней. Программер в пятьдесят, тем паче — в шестьдесят, это, как правило, недавний эмигрант… Так что, не случись известная заварушка, гужевался бы я сейчас все в той же своей конторе постановщиком задач, расписывал бы спецификации. А если б удалось мне свалить из Совка в семидесятые, был бы сейчас… постановщиком задач, специфицировал бы бизнес-объекты да процессы. Впрочем, если бы да кабы… спасибо на том, что есть.

            Вернусь к «мирам». На моей первой работе в проектном институте машина МИР-2 появилась в самом начале семидесятых и я с ней лет семь сталкивался. Нет, не программировал (выше я объяснил, почему), но именно сталкивался. Всякий инженер, составлявший на «мире» свои программы, если дело не ладилось, не стеснялся «дергать» программиста, сиречь меня. Я конечно исправлять неполадки в железе не мог (тут приходилось звать электронщика), но диагностировать оные и уж конечно — выявлять всякие «кости» в программах… этим приходилось заниматься регулярно. Так что машину, её язык и нехитрую операционную систему поневоле освоил досконально.