Главная страница Visual 2000 · Общий список статей
Поговорим о программировании.Андрей Колесов
© Андрей Колесов, 2000"Мы изучаем историю, чтобы взять оттуда огонь, а не пепел"
Письменные и устные отзывы, полученные мною после публикации статьи "О программировании", заставили оставить сомнения в целесообразности темы. Однако прежде чем перейти к продолжению "размышлений", хотелось бы сделать два замечания.
В любом случае я буду благодарен за любые отзывы и пожелания в адрес данной темы. Пишите: akolesov@online.ru.
Изменений за 20 лет не так уж много
Затронутые в полученных письмах вопросы, заставляют перед обсуждением практических проблем разработки программ, обсудить некоторые философские вопросы. Итак, что же поменялось в стиле программирования и может ли помочь нынешним разработчикам опыт бывших?
На самом деле за последние двадцать лет произошли весьма радикальные изменения. Я бы сравнил это с переходом от опытного (может быть даже "лабораторных испытаний") к серийному производству программ. От мастеров, создающих штучные изделия (где красуется личное клеймо автора), к безвестным работникам на конвейере. Разумеется, это сильно утрированная метафора, но в целом она верна.
На вопрос о том, какая технология программирования более эффективна — современная или та, что была некоторая время (десять, двадцать, ... лет) назад нужно четко ответить — сегодняшняя. Иначе она бы просто не существовала, в этом принцип прогресса.
Мне кажется, что противопоставление тогдашних и сегодняшних программистов неверно по очень простой причине. На самом деле проблема стиля и качества разработки была и тогда и сейчас. Этот отражает довольно значительные разброс (который был всегда) в квалификации специалистов. Ворчание "стариков" по поводу нынешнего племени объясняется хотя бы тем, что дожившие на компьютерном поприще до нынешних времен ветераны принадлежат как раз к наиболее сильным профессионалам. В результате получается, что мы сравниваем "средний" современный уровень с самым высоким тех времен. Если же сравнивать "средний" и "средний", то картина будет иной.
Анализируя изменения стиля программирования за последние двадцать лет, можно наблюдать довольно противоречивую картину. С одной стороны, (я во многом согласен с позицией Дмитрия Шарадкина) в целом теоретические и технологические принципы программирования остались теми же самыми. OCX, ADO, ActiveX, DNA и пр. — на 90% просто маркетинг, который позволяет каждый год заявлять о появлении новой революционной технологии, рассказывая старые истории с использованием новой терминологии.
С другой, — налицо совершенно революционные изменения в характере работы программиста: 1 час в день доступа к ЭВМ тогда и сколько угодно часов сегодня. Но как раз в данном случае мне представляется, что эти новшества не очень сильно сказываются на стиле разработки.
Начнем с того, что подход "сначала думай, а потом делай" всегда нужен для решения сколь-нибудь серьезных задач. Возможность круглосуточной работы на компьютере никак не отменяет главную задачу человека. Парадокс заключается в том, что, несмотря на возможность интерактивного программирования, производительность труда за последние двадцать лет возросла не так уж сильно, не на порядки. Точнее высокие темпы обеспечиваются в основном за счет использования готовых компонентов, образно говоря, перехода от кирпичной кладки к панельному строительству (хотя кирпичная кладка широко применяется и сегодня). Снижение расходов достигается за счет исключения вспомогательных операций (например, многочисленных операторов ЭВМ и перфораторов) и разделения труда (раньше программист занимался и тестированием и разработкой документации).
В том же время объем создаваемого отдельным программистом результирующего кода возрос не так сильно, так как это определяется способностью специалиста управлять логической конструкцией проекта.
Понятно, что подход к разработке крупного и небольших проектов отличается по степени проработки проекта на бумаге. Но я бы хотел в данном случае не затрагивать вопросы реализации крупных проектов — это совершенно иная область — и обсуждать только разработку локальных систем и приложений. Кроме того, что этим занимается абсолютное большинство программистов, мне кажется, что только правильные подходы в решении локальных задач позволят специалисту успешно перейти на более высоких уровень систем.
Как мне представляется, технология программирования, сложившаяся в середине 70-х (кстати, в США в те времена программисты уже имели 8-часов доступ к компьютерам), как раз подразумевает эффективное совмещение стадий проектирования, кодирования и отладки программ. Лично я последние блок-схемы программ при проектировании рисовал кажется лет двадцать назад. Другое дело, что, когда я ввожу текст программы, у меня перед глазами постоянно стоят квадратики, ромбики и стрелочки, которыми нас два семестра мучили Л.И.Шустова и Л.И.Тышкевич по "Вычислительной математике". И я хорошо помню, что обилие стрелочек, тем более пересекающихся, говорит о слабой проработке алгоритма.
Если говорить об изменении в технологии программирования, то для начала нужно избавиться от иллюзии "советские программисты — самые лучшие программисты в мире". По моим наблюдениям, число русских программистов в американских компания, по крайней мере, не превышает количество специалистов из европейских стран, не говоря уже об Индии. И это притом, что число выпускников вузов с такой квалификацией у нас гораздо больше.
Чтобы разобраться в этом вопросе, нужно понять, что же такое "программист". Лет пятнадцать назад в большинстве своей программисты были весьма универсальные специалисты, которые обеспечивали полный жизненный цикл разработок — постановка задачи, проектирование, кодирование, отладка, разработка документации, обучение пользователей (если они были), сопровождение и пр.
В этой связи стоит отметить принципиальную разницу между отечественными и зарубежными разработчиками 70-х годов: в то время, как мы спорили, "Программирование — это наука или искусство?", американцы уже нашли правильный ответ "Программирование — это технология".
Технология же подразумевает создание четкой системы разделения труда и следование достаточно жестким стандартам и правилам. Не говоря уже о распределении обязанностей внутри групп программистов, сегодня в отдельные категории специалистов выделились тестеры, технические писатели (документация), сотрудники техподдержки.
В результате наши разработчики с университетским образованием, приезжая на работу в США, с удивлением обнаруживают, что рядом с ними зачастую сидит человек, познакомившийся с основами программирования лишь недавно на двухмесячных курсах. И самое удивительное, что проекты с участием таких сотрудников успешно завершаются.
Конечно, специалисты научного склада ума, умеющие генерировать идеи и находить оригинальные решения, нужны и они будут всегда востребованы. Но проявлять эти выдающие качества нужно лишь в соответствующей обстановке, не в ущерб своим прямым обязанностям.
Многие российские кадровые агентства отмечают в качестве одной из проблем трудоустойства отечественных разработчиков за рубежом их слишком высокий научно-технический уровень подготовки. Точнее не "высокий", а "не соответствующий реальным требованиям". Они знают больше, чем нужно программисту, но при этом не курсе многих необходимых для работы вещей. У нас, как и раньше, готовят ученых, способных решать уникальные задачи, а не технологов, обеспечивающих работу серийного производства.
По этому поводу, вот такая история, услышанная мною еще года три назад. Специалисты одного российского научного центра работали по контракту с американской компанией. Из-за рубежа поступила срочная задача — провести тестовые испытания нового компилятора (были переданы программа и методика тестирования) и вернуть результаты через неделю. В назначенный срок американцы получают отчет о проделанной работе: "Мы проанализировали работу компилятора и методику тестирования и нашли их весьма далекими от совершенства. По нашим расчетам производительность программы можно повысить на 20-30%. Специалисты уже начали модернизацию компилятора, которая будет завершена через месяц. Спустя еще две недели мы передадим вам отлаженную программу и отчет о ее тестировании".
Реакция заказчиков на такое предложение не требует особых пояснений.
Выдержки из писем — откликов на публикацию первой части "Размышлений"
Майерса я бы заставил изучать всех программистов в обязательном порядке даже сегодня. Что же касается Дейкстры (моего самого уважаемого патриарха), то эта маленькая книга — его непревзойденный шедевр. Она написана уже после того, как он изобрел параллельное программирование с семафорами, а затем структурное программирование. Это эссе представляет собой скорее поэтическое произведение, где Дейкстра свел программирование к трем командам и двум конструкциям, с помощью которых решаются исключительно сложные задачи. Кстати сказать, ни один современный язык программирования не дотягивает до "Дейкстровской" модели "того" еще времени.
Справедливости ради следует отметить еще одно достижение, которое в статье я не заметил. Это — объектно- ориентированное программирование, вторая революция после структурного программирования. Если научиться мыслить категориями ООП, то можно добиться больших успехов в программировании, пример тому - современные разработки Microsoft (в отличие от Netscape).
Виталий Сизов,
Эстония
Несколько последних лет в основном занимался коммерческими вопроса в компьютерной фирме. Но в последний год у меня появилась возможность вернуться к программированию, на сей раз в качестве руководителя ряда SW-проектов и соответствующего отдела. Благо Интернет дал возможность организовать работу в режиме удаленной работы с теми, кто готов платить — западными заказчиками.
Пришлось срочно наверстывать, смотреть, что же нового произошло и появилось за это время. Это конечно, тема отдельного разговора, но похоже принципиально нового - почти ничего. Как говорят "все новое - это хорошо забытое старое" или точнее, "развитие идет по спирали" — как нас с Вами учили классики. Очень много "крутых" разговоров, надувания щек, а новых идей-то почти нет. Все упирается в инструментарий.
Даже "навороченные" среды разработчика — это в общем-то "продвинутые" инструменты, с родословной, восходящей к Borland TurboPascal. Java c ее "переносимостью" корнями уходит в p-code Николаса Вирта, а ActiveX — красиво "запакованные" старые-добрые подпрограммы и т.д. В общем, в основном это скорее маркетинг. В итоге, посмотрите любое резюме: люди гордятся знанием конкретного инструмента, а не умением решать задачу с помощью инструмента.
Но главное, на что мне хотелось бы обратить Ваше внимание: действительно, появившаяся новая психология нового поколения программистов.
Вспомните, как работали мы . Час в день (в лучшем случае) доступа к ЭВМ и остальные семь — подготовка к этому "счастливому мгновению". И просчитывались все варианты, последствия, побочные эффекты и т.д. В итоге, у этого поколения сформировалась идеология "сначала думай, потом делай".
Для тех же, кто начал программировать в конце 80-х и сразу на PC, и постоянно имели "полный" доступ к компьютеру, гораздо проще было сначала попробовать, а затем посмотреть, что же получилось. Это сформировало их стиль работы. Так они (как правило) работают, и менять этот стиль им очень трудно.
Нельзя сказать, что второй вариант лучше или хуже первого: они разные. И в различных ситуациях каждый из них может оказаться лучшим. Например, в малых программистских группах (два-три человека), для малых программ, в случае, когда скорость выполнения работы превыше всего, второй стиль явно превосходит первый. Но попробуйте его применить при создании действительно сложных программных комплексов, при работе большой группы разработчиков и т.д.!
Как правило, в коллективе действительно нужны люди обоих "стилей". Одни — для того, что бы работать в роли "ледокола", быстро и "начерно" решать задачи. Другие — для скрупулезной "доводки" программного продукта. Более того, я заметил (не только "у нас", но и на примере нескольких "западных" софтверных компаний), что успех разработки, как правило, там, где руководитель проекта работает (либо изначально, либо сумев перестроиться) именно по принципу "сначала думай, потом делай". Почему так? Думаю, потому, что такой стиль переносит основной аспект на методологию, а не на технологию, учит программированию как творческой активности, а не как ремеслу.
К сожалению, внимательно присмотревшись к рынку литературы и к Интернет-источникам, я так и не смог найти практически ничего, что учило бы именно программированию, а не использованию конкретных средств. Я думаю что цикл статей, который Вы анонсировали, мог бы хоть как-то восполнить этот пробел. Поэтому удачи Вам в Вашем начинании.
С уважением, Дмитрий Шарадкин,
RQL-Украина, Коммерческий директор
Я начал работать программистом в 1987 году, трудился в НИЦЭВТ, позже в компании-разработчике систем автоматизации масштаба. Всегда старался соблюсти золотую середину между теоретической основой и практическими навыками. Языков старался не менять без надобности, и без необходимости не прыгать туда- сюда.
Сейчас наш коллектив заканчивает один из проектов B2C на базе ASP, что для меня как в прошлом Си- программиста было просто с точки зрения технической, но с психологической — совсем наоборот. Неожиданно для меня оказалось, что ребята, которые моложе меня лет на 10, абсолютно не знают теории, совсем как в Вашем примере о программисте из Риги, хотя есть ребята не только с высшим образованием, но и аспиранты.
Как раз за неделю до получения журнала с Вашей статьей у нас была дискуссия практически по всем пунктам статьи на вкладке. Я был как тот упомянутый Вами "суперпрограммист", который больше мешает, чем помогает своими знаниями, хотя, конечно, это все несколько утрировано.
С уважением, Вадим Уваров