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