БЕСЕДЫ О ПРОГРАММИРОВАНИИ    

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

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

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

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

Например, утечка памяти и других ресурсов типична для сред типа Windows. Такие инструменты, как новый CodeGuard for Borland C++ фирмы Borland, дают разработчикам отличную возможность находить эти дефекты до того, как они повлияют на работу. Теперь нет никакого оправдания тому, что приложение "рабочего дня" начинает давать сбои из-за того, что проработало слишком долго, и надо перезагружаться, чтобы опять набрать скорость.

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

ВЫГОДЫ МАСШТАБИРОВАНИЯ

Возможности масштабирования тоже заслуживают пристального внимания. Я видел разные конкурирующие продукты типа электронных таблиц и инструментария статистического анализа, для которых коэффициент время выполнения/объем задачи выражался функциями от логарифмических (объем  -  10, время  -  2) до полиномиальных (объем  -  10, время  -  100).

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

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

Microsoft, например, учла это замечание, объявляя, что основной целью при создании библиотеки Foundation Classes было желание стимулировать разработчиков использовать новые интерфейсы API. Независимый анализ нескольких версий MFC показал такое быстрое развитие основного кода прежде всего из-за создания новых API, которое вряд ли можно ожидать от того, что называют "базовым кодом".

Я все еще не готов строить мощные здания программ будущего на песке C++, однако всем нам следует быть осторожными при покупке инструментов более высокого уровня.    

Питер Кофи

К Питеру Кофи можно обратиться через MCI Mail: 357-1756 или через  CompuServe: 72631,113 или Internet: 357-1756@MCIMAIL.COM.