Главная страница Visual 2000 · Общий список статей

Поговорим о программировании.
Размышления бывшего программиста
Часть 1.2

Андрей Колесов

© 2000, Андрей Колесов
Авторский вариант. Статья была опубликована c незначительной литературной правкой в "КомпьютерПресс" N 9/2000, с. 90-95.

Весь сериал

Какой инструмент лучше

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

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

К вопросу о спорах. Давно давно, "когда мы были молодые" мы тоже любили потрепаться о том, как система лучше. В нашей лаборатории тогда были два лагеря: один программировал для больших ЕС ЭВМ, а другой — для малых СМ ЭВМ. Когда время, отведенное на перекур, иссякало, я порой применял последний убийственный аргумент в свою пользу: бросал через весь зал в своего оппонента катушку с перфолентой, на которой было записан программа. Лента разматывалась метров на десять, потом я, не вставая из-за стола, спокойно сматывал ее и предлагал спорящей стороне: "Я теперь брось в меня свою колоду с сотней перфокарт. И давай посмотрим, сколько времени у тебя уйдет, чтобы собрать ее в нужном порядке". Победа была за нами!

Разумеется, вопрос выбора инструмента (лучшего) может серьезно обсуждаться только в контексте выполнения вполне конкретного проекта. И при этом можно выделить два ключевых критерия: класс решаемой задачи и подготовка разработчиков. Например, выглядело бы довольно странным, если для создания серьезных численных моделей, был выбран ассемблер или Visual Basic (я бы в первую очередь посоветовал Fortran). Очевидно, что VB никак не подходит для решения тонких задач на уровне операционной системы, но имеет явные преимущества перед Fortran и C при создании пользовательского интерфейса.

В то же время, конечно, имеет смыл тема сравнительного изучения инструментов, как раз для предварительного выявления их плюсов и минусов. Но, к сожалению, как раз таких исследований и публикаций в настоящее время практически нет.

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

Однако сегодня существует достаточно большой круг задач (например, создание локальных учетных систем или разработка клиентской части прикладных комплексов), для решения которых имеется несколько альтернативных инструментов (Delphi, VB, "1C:Предприятие" и многие другие). Лично я убежден: даже при достаточно большом диапазоне колебаний технических требований существенным критерием является то, какой инструмент знаете лучше вы или ваша группа разработчиков. Слабое знание инструмента сводит на нет все его возможности.

Мой опыт однозначно говорит о том, что в зависимости от квалификации программиста эффективность программы, например ее быстродействие, и срок ее реализации могут отличаться в несколько раз (я постараюсь показать это позднее). В этой ситуации довод о том, что "тесты показали преимущества инструмента А перед Б на 50%" выглядят весьма условным. Хотя бы потому, что тесты, возможно, писались одним человеком, который проработал с А более десяти лет и только за месяц до этого начал осваивать Б.

В начало статьи

Бывают ли "неструктурные" языки

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

Отвечая на первое возражение, Эдвард Йодан показал, что главное в структурном проектировании программ — это умение составление правильной логической схемы, исполнение которой языковыми средствами — дело вторичное. Доказательством этому были примеры программной реализации разнообразных логических конструкций на пяти ведущих тогда языках программирования: Assembler IBM 360, Fortran, Cobol, Algol и PL-1.

Замечание. Как известно, ассемблер — это категория языков низкого уровня, в которых каждому оператору соответствует ровно одна машинная команда. (Но многие такие языки широко используют также макрокоманды, которые преобразуются в последовательность операторов.) Так что язык ассемблера является специфическим для каждого процессора или архитектурного семейства процессоров (например, Intel x86 и Pentium). Таким образом, нужно различать понятие категории языков (в этом случае слово пишется с прописной буквы) и конкретной реализации языка для конкретной машины (начинается со строчной буквы и фактически является обозначением программы-транслятора, преобразующего мнемоническую запись программы в машинные коды).

Что касается, влияния "структурированности" программы на ее эффективность, то этот вопрос непосредственно связан с глобальной темой нахождения оптимального соотношения между эффективности кода и его стоимости с учетом всего жизненного цикла программы. Эти вопросы мы будем еще более подробно обсуждать, причем именно потому, что они очень актуальны и сегодня, во времена, когда, казалось бы, рост мегагерцев и мегабайтов может решить все алгоритмические промахи программиста.

Сегодня проблема пригодности языков для структурного программирования является не столь актуальной (например, Basic и Fortran давно вышли на уровень классического Algol/Pascal). Сейчас дискуссии идут по поводу других вопросов, но если приглядеться внимательнее, то окажется, что чаще всего их решение выглядит столь же простым.

В начало статьи

Что наша жизнь? Постоянная учеба!

Много лет назад, когда я был еще обладателем пышной шевелюры, в парикмахерской мастер сказала мне: "Эх, парень, у тебя уже лысина пробивается! Ты кем работаешь?" — "Программистом." — "Да, видать тяжелая жизнь у вас, у программистов!" (Любопытные рассуждения о радостях и печалях профессии программиста приведены в книге Ф.Брукса.)

То, что профессия программиста была и остается изначально ориентированной на постоянное изучение новых инструментов, не требует специальных доказательств. Тем не менее, за последние тридцать лет произошли серьезные изменения в этом процессе.

Раньше это было связано с достаточно частой (с цикличностью в 2-4 года) сменой, как языковой основы инструмента, так и архитектуры компьютера. Например, у меня было несколько периодов в работе (это характерно для многих программистов той поры), когда приходилось одновременно работать на машинах принципиальной разной архитектуры (EC ЭВМ, СМ-1 и "Электроника-60") и использовать несколько языков (Фортран, Бейсик, Алгол и Ассемблер).

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

Процедура же смены инструмента, безусловно, облегчалась тем, что сами инструменты были существенно проще современных. Но при этом хотелось бы отметить и другой момент: такая миграция выполнялась легко, только в случае приличного знания методики разработки, методов вычислительной математики и общих принципов организации языков программирования. И именно это определяло общий уровень специалиста. Короче говоря, если человек владел общеметодической и теоретической подготовкой, то он писал программы хорошо независимо от языка и архитектуры. В противном случае — это было слабое программирование, независимо от используемого инструмента.

Сейчас можно говорить о более высоком уровне специализации разработчиков в рамках отдельных инструментов, поэтому развитие специалиста чаще всего идет в виде постоянного освоения новых версий средства и появляющихся смежных технологий. Безусловно, современные инструменты на порядок сложнее существовавших еще всего десяток лет назад. Их доскональное освоение требует нескольких месяцев, а то и лет изучения и практической работы.

В этой связи можно сделать один промежуточный совет. Ранее я отмечал, что при выборе инструментария для реализации проекта, нужно обязательно учитывать квалификацию и специализацию (каким средствами владеют) потенциальных исполнителей работы. Если же выбор пал на инструмент новое для них средство, то нужно серьезно подумать — следует ли заставлять их осваивать его или лучше поменять программистов.

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

Отличительная черта современного программирования — заметное снижение среднего возраста разработчиков. Это, вполне естественно хотя бы потому, что четверть века назад будущие программисты в абсолютном большинстве впервые получали доступ к компьютеру только в 20-летнем возрасте. Но тут есть очевидные подводные камни — многие разработчики сегодня считают, что практический опыт может заменить систематическое изучение теоретических и методический основ.

Я долгое время сомневался, стоит ли вообще писать эти заметки, и решающим стимулом для меня явилось весьма любопытное обсуждение конкретной технической проблемы с программистом из Риги, который представился так: "Я опытный C/Pascal-программист (стаж — шесть лет), мне 19 лет и я учусь на третьем курсе университета. Но все что мне нужно для программирования, я знал до поступления в него". Разбор задачи, которую он пытался решить у нас будет впереди. Отмечу только, что я настоятельно рекомендовал ему не пропускать занятия, если он не хочет остаться таким же "опытным", как в данный момент.

В начало статьи

Инструмент и квалификация — не одно и то же

Еще одной иллюзией является широко распространенное сейчас представления о том, что квалификация программиста определяется тем, каким инструментом он владеет. Более конкретно, C- программист — это сильно, Basic — не очень... Такое мнение не просто неверное: оно формирует неправильное представление о действительности.

На самом деле, квалификация разработчика определяется его уровнем общеметодической подготовки (об этом пойдет речь ниже) и глубиной знания инструмента. Короче говоря, есть более и менее квалифицированные специалисты, соответственно, если слабые C-программисты и сильные VB- программисты, и наоборот. При смене инструмента, скорее всего, слабый разработчик останется слабым, а сильный — сильным.

Вообще говоря, неплохим интегрированным показателем квалификации специалиста является его заплата (но тут надо принимать во внимание колебание конъюнктуры рынка). Полезно вспомнить, что Билл Гейтс (не только отличный бизнесмен, но и весьма приличный программист) еще несколько лет назад рядом с титулом "Президент Microsoft" часто указывал "Basic-программист".

Да, наверное, можно констатировать, что в среднем квалификация у C-программиста выше, чем у VB-программиста. Но, скорее всего, что в силу ряда обстоятельств "младшие" программисты (не будем говорить о слабых и сильных) скорее могут найти себе применение, работая с VB.

Другая опасность для разработчика — прикрывать слабость своей квалификации якобы имеющимися недостатками и ограничениями инструмента. Примеры этого были очень хорошо видны еще в начале 90-х годов, когда я активно работал с QuickBASIC. Кто-то хотел переходить с QB на Pascal, чтобы иметь возможность работать с портами компьютера (оказывается, они не знали о существовании операторов OUT и INP). Другие даже слышать не хотели о QB, изначально не веря, что у него есть настоящий компилятор и возможность создания EXE-модулей. При этом и те, и другие не могли поверить, что показываемые им серьезные прикладные пакеты действительно написаны в "Васике". А секрет был простой — их писали мастера...

Тут хотелось бы привести цитату исследователей процесса разработки времен начала 70-х: "Если программист хорош, то он очень и очень хорош. Но уж если он плох, то он просто ужасен".

В начало статьи

Знание одного инструмента — недостаточно

И все же, несмотря на более узкую и глубокую специализацию, "многоязычие" программиста и сегодня является, если не обязательным, то, по крайней мере, весьма желательным. Конечно, сейчас трудно одинаково хорошо знать два инструмента, поэтому, наверное, лучше взять за основу подход "основной и вспомогательный инструменты".

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

Например, во времена DOS для QB, безусловно, необходимым языком был Assembler. Даже простые подпрограммы в один-два десятка машинных команд, позволяли повысить быстродействие критически важных операций в десятки раз или обойти, казалось бы, непреодолимые преграды.

Для Fortran-пользователей (и, наверное, для С) является очень полезными умение создание пользовательского интерфейса с помощью одного из RAD-инструментов. Delphi является в значительной степени самодостаточным инструментом, но вряд ли его пользователь сможет обойтись без применения VB или Java. VB-разработчику знание основ Java также совсем не повредит. И всем им нужно представление о HTML и в ближайшее время — об XML.

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

В начало статьи

Хорошие программисты — кто они?

Прежде чем перейти к обсуждению более конкретных проблем разработки приложений (в будущем хотелось обсудить вопросы разработки и отладки программ) было бы полезно вспомнить о вопросе, с которого начинается книга Йодана — "Отличительные черты "хорошей" программы для ЭВМ".

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

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

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

В начало статьи

О хорошей программе — в следующий раз

На этом я прерываю "Размышления", что продолжить их потом с обсуждения "что такое хорошая программа". В заключении хочу упомянуть, что во все главы книга Э.Йодана сопровождались весьма остроумными и уместными эпиграфами, а также вопросами и заданиями для оценки "Усвоения материала". Вот один из 42 вопросов в конце первой главы:

"3. В чем состоят выдающиеся способности самого лучшего из известных вам программистов? Можно ли на ваш взгляд, эти способности развить обучением или научиться передавать их другим? Считаете ли вы, что некоторые из этих способностей основаны на опыте? Или они являются врожденными?"

В начало статьи