Поговорим о программировании. Размышления бывшего программиста
Часть 2
Изменений за 20 лет не так уж много
Выдержки из писем — откликов на публикацию первой части «Размышлений»
Письменные и устные отзывы, полученные мною после публикации статьи «О программировании», заставили оставить сомнения в актуальности темы. Однако, прежде чем продолжить наши «размышления», хотелось бы сделать два замечания.
- В опубликованном варианте первой части статьи из заголовка пропало слово «поговорим», что не совсем точно отражает замысел публикации. Ведь желательно, чтобы это был не монолог автора, а именно разговор всех заинтересованных людей. Желательно не только «бывших» программистов.
- Совсем не хотелось бы, чтобы обсуждение сводилось к ностальгическим воспоминаниям. Цель обсуждения — оказать практическую помощь тем, кто разрабатывает программы сегодня и собирается это делать в будущем. В связи с этим очень приятно, что пожелание продолжить серию наших статей высказали не только «ветераны движения», но и действующие программисты разного возраста и c разным опытом работы.
В любом случае, я буду благодарен за какие бы то ни было отзывы и пожелания, касающиеся данной темы. Пишите: akolesov@online.ru.
Изменений за 20 лет не так уж много
Затронутые в полученных письмах вопросы заставляют перед обсуждением практических проблем разработки программ обсудить некоторые философские вопросы. Итак, что же поменялось в стиле программирования и может ли помочь нынешним разработчикам опыт бывших?
На самом деле за последние двадцать лет произошли весьма радикальные изменения. Я бы сравнил это с переходом от опытного (может быть, даже лабораторных испытаний) к серийному производству программ. От мастеров, создающих штучные изделия (где красуется личное клеймо автора) — к безвестным работникам конвейера. Разумеется, это очень утрированная метафора, но в целом она верна.
На вопрос о том, какая технология программирования более эффективна — современная или та, что применялась некоторое время (десять, двадцать... лет) назад, нужно четко ответить — сегодняшняя. Иначе она бы просто не существовала — в этом заключается основной принцип прогресса.
Мне кажется, что противопоставление тогдашних и сегодняшних программистов неверно по очень простой причине. На самом деле проблема стиля и качества разработки существовала и тогда и сейчас. Это отражает довольно значительный разброс (который был всегда) в квалификации специалистов. Ворчание «стариков» по поводу нынешнего племени объясняется хотя бы тем, что дожившие на компьютерном поприще до нынешних времен ветераны принадлежат как раз к наиболее сильным профессионалам. В результате получается, что мы сравниваем «средний» современный уровень с самым высоким уровнем тех времен. Если же сравнивать «средний» современный и «средний» тогдашний уровни, то картина будет иной.
При анализе изменения стиля программирования за последние двадцать лет складывается довольно противоречивая картина. С одной стороны (здесь я во многом согласен с позицией Дмитрия Шарадкина, письмо которого процитировано ниже), теоретические и технологические принципы программирования в целом остались теми же самыми. OCX, ADO, ActiveX, DNA и пр. — на 90% просто маркетинг, который позволяет каждый год заявлять о появлении новой революционной технологии, рассказывая старые истории с использованием новой терминологии1.
С другой стороны, за эти двадцать лет произошли революционные изменения в характере работы отечественного программиста: один час в день доступа к ЭВМ тогда и сколько угодно часов — сегодня. Но как раз в данном случае мне представляется, что эти новшества не очень сказываются на стиле разработки.
Начнем с того, что подход «сначала думай, а потом делай» всегда актуален при решении сколь-нибудь серьезных задач. Возможность работать на компьютере круглосуточно не отменяет главную задачу человека. Парадокс заключается в том, что, несмотря на возможность интерактивного программирования, производительность труда за последние двадцать лет не так уж возросла, во всяком случае, не на порядки. Точнее, высокие темпы обеспечиваются в основном за счет использования готовых компонентов, образно говоря, перехода от кирпичной кладки к панельному строительству (хотя кирпичная кладка широко применяется и сегодня). Снижение расходов достигается за счет исключения вспомогательных операций (например, многочисленных операторов ЭВМ и перфораторов) и разделения труда (раньше программист занимался еще и тестированием, и разработкой документации).
Объем создаваемого отдельным программистом результирующего кода также возрос не так сильно, поскольку определяется способностью специалиста управлять логической конструкцией проекта.
Понятно, что подходы к разработке крупных и небольших проектов различаются по степени проработки проекта на бумаге. Но в данном случае я бы не хотел затрагивать вопросы реализации крупных проектов — это совершенно иная область. Обсудим только разработку локальных систем и приложений. Кроме того, что этим занимается абсолютное большинство программистов, мне кажется, что только правильные подходы в решении локальных задач позволят специалисту успешно перейти на уровень более сложных систем.
Как мне представляется, технология программирования, сложившаяся в середине 70-х годов (кстати, в США в то время программисты уже имели 8-часовой доступ к компьютерам), как раз подразумевает эффективное совмещение стадий проектирования, кодирования и отладки программ. Лично я последние блок-схемы программ при проектировании рисовал, кажется, лет двадцать назад. Другое дело, что, когда я ввожу текст программы, у меня перед глазами постоянно стоят квадратики, ромбики и стрелочки, которыми нас два семестра мучили Л.И.Шустова и Л.И.Тышкевич, читавшие в нашем вузе курс вычислительной математики. И я хорошо помню, что обилие стрелочек, тем более пересекающихся, говорит о слабой проработке алгоритма.
Российское — значит отличное?
Если говорить об изменении в технологии программирования, то для начала нужно избавиться от иллюзии на предмет того, что российские программисты — самые лучшие в мире. По моим наблюдениям, число программистов из России в американских компаниях, по крайней мере, не превышает количество специалистов из европейских стран, не говоря уже об Индии. И это при том, что число выпускников вузов с такой квалификацией у нас гораздо больше.
Чтобы разобраться в этом вопросе, нужно понять, что же включает в себя понятие «программист». Лет пятнадцать назад большинство программистов были весьма универсальными специалистами, которые обеспечивали полный жизненный цикл разработок — постановку задачи, проектирование, кодирование, отладку, разработку документации, обучение пользователей (если они были), сопровождение и пр.
В связи с этим стоит отметить принципиальную разницу между отечественными и зарубежными разработчиками 70-х годов: в то время, как мы спорили о том, что такое «программирование — наука или искусство», американцы уже нашли правильный ответ: «программирование — это технология».
Технология же подразумевает создание четкой системы разделения труда и следование достаточно жестким стандартам и правилам. Не говоря уже о распределении обязанностей внутри групп программистов, сегодня в отдельные категории специалистов выделились тестеры, технические писатели (документация), сотрудники техподдержки.
В результате наши разработчики с университетским образованием, приезжая на работу в США, с удивлением обнаруживают, что рядом с ними зачастую сидит человек, познакомившийся с основами программирования лишь недавно, на двухмесячных курсах. И самое удивительное, что проекты с участием таких сотрудников успешно завершаются.
Конечно, специалисты с научным складом ума, умеющие генерировать идеи и находить оригинальные решения, нужны и будут всегда востребованы. Но проявлять эти выдающие качества нужно лишь в соответствующей обстановке и не в ущерб своим прямым обязанностям.
Многие российские кадровые агентства отмечают в качестве одной из проблем трудоустойства отечественных разработчиков за рубежом их слишком высокий научно-технический уровень подготовки. Точнее, не высокий, а «не соответствующий реальным требованиям». Они знают больше, чем нужно программисту, но при этом не в курсе многих необходимых для работы вещей. У нас, как и раньше, готовят ученых, способных решать уникальные задачи, а не технологов, обеспечивающих работу серийного производства.
По этому поводу мне вспоминается история, услышанная мною еще года три назад. Специалисты одного российского научного центра работали по контракту с американской компанией. Из-за рубежа поступило задание — провести тестовые испытания нового компилятора (были переданы программа и методика тестирования) и через неделю представить результаты. В назначенный срок американцы получают отчет о проделанной работе: «Мы проанализировали работу компилятора и методику тестирования и нашли их весьма далекими от совершенства. По нашим расчетам, производительность программы можно повысить на 20-30%. Специалисты уже начали модернизацию компилятора, которая будет завершена через месяц. Спустя еще две недели мы передадим вам отлаженную программу и отчет о ее тестировании».
О реакции заказчиков на такое предложение говорить, по-моему, излишне.
КомпьютерПресс 11'2000