6.9. Заключение

Чем лучше вы пишете код изначально, тем меньше ошибок он будет содержать. Тестирование граничных условий непосредственно при на­писании кода — эффективный способ удалить множество мелких глу­пых ошибок. Систематическое тестирование проверяет потенциально уязвимые места в строгом порядке; опять же, сбои чаще всего происхо­дят на каких-то границах, которые можно проверить вручную или про­граммно. Как можно шире используйте автоматизированное тестирова­ние, поскольку машины не делают ошибок, не устают и не занимаются самообманом. Возвратные тесты проверяют, что результаты работы

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

Дополнительная литература

Один из способов узнать побольше о тестировании — изучить примеры на основе лучших образцов доступных программ. В статье Дона Кнута "Ошибки в ТЕХ", опубликованной в Software — Practice and Experience (Don Knuth. The Errors of TEX. Software — Practice and Experience, 19, 7, p. 607-685, 1989), описываются все ошибки, найденные к тому времени в системе ТЕХ, и обсуждаются использованные Кнутом методы тестирования. Тест TRIP для ТЕХ представляет собой отличный пример основательного комплекса тестирования. Perl также предлагает расширенный набор тестирования, предназначенный для проверки его правильности после компиляции и установки на новой системе и включающий такие модули, как MakeMaker и TestHarness, которые помогают в создании тестов для расширений Perl.

Ион Бентли (Jon Bentley) написал серию статей в Communications of the ACM, которые были собраны в сборниках "Programming Pearls" I (1986) и "More Programming Pearls" (1988), изданных Addison-Wesley. В этих статьях затрагиваются вопросы тестирования, главным образом структуры для организации и автоматизации расширенных тестов.

7.Производительность

Он был силен и много обещал, —

Свершений нет, а силы растерял.

Шекспир. Король Генрих VIII

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

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

Таким образом, первым принципом оптимизации можно считать принцип не делать лишнего. Достаточно ли хороша программа в своем теперешнем состоянии? Мы знаем, как и где она будет использоваться; будут ли заметны выгоды от ее ускорения? Программы, которые пи­шутся в качестве заданий в колледже, никогда больше не используются, их скорость редко имеет значение. Скорость также редко имеет значение для программ, написанных для собственного использования, временных утилит, испытательных стендов, экспериментов и про- грамм-прототипов. Однако же скорость исполнения коммерческого продукта или центрального компонента системы, например графической библиотеки, может иметь первостепенную важность, так что нам надо знать, как подходить к вопросам производительности. Когда надо пытаться ускорить программу? Как это можно сделать? На какие результаты мы можем рассчитывать? В этой главе мы обсудим, как добиться того, чтобы программа выполнялась быстрее или использо-вала меньше памяти. Как правило, больше всего пас интересует скоростьпрограммы, так что в основном речь пойдет о ней. Проблемы с памятью, оперативной или внешней, возникают реже, но иногда они могут быть критичными, так что мы затронем и этот аспект.

Как мы уже выяснили в главе 2, для выполнения задания сначала луч­ше выбрать самые простые и понятные алгоритмы и структуры данных. После этого надо измерить производительность и решить, нужны ли из­менения. Далее следует настроить опции компилятора на создание наибо­лее быстрого кода; потом оценить, какие изменения в самой программе могут дать наибольший эффект; потом начинать вносить изменения — по одному за раз! — и после каждого повторять предыдущие шаги. При этом всегда надо сохранять простые версии, чтобы продолжать сравнения.

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

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