Программирование на языке Ruby

16.4. Использование irb в качестве отладчика

Библиотеку

написал Флориан Гросс (Florian Gross). Этот великолепный, несмотря на малый объем, инструмент позволяет расставлять в программе точки прерывания методом . Когда в процессе исполнения встречается точка прерывания, запускается сеанс (программа интерактивной работы с Ruby подробно рассматривается в главе 21).

Эта библиотека не входит в стандартный дистрибутив. Установить ее можно, например, выполнив команду

.

Внесем несколько изменений в программу из листинга 16.4. Поместим в начало директиву

и добавим вызов метода после обоих обращений к :

Теперь запустим ее. В следующем протоколе сеанса показано, как мы входим в

, после чего можем делать все что угодно — в частности, вызывать ранее определенные методы и изменять значения переменных.

Особенно подкупает, что отлаживаемая программа может быть не только командной или текстовой. Существует клиент drb (распределенный Ruby), который позволяет удаленно отлаживать программу Ruby, работающую в другом процессе.

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

):

Запустите клиент командой

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

После установления соединения вы можете и не получить приглашение

. Программа будет выполняться до точки прерывания — вот тогда-то вы и увидите приглашение.

Дополнительную информацию об этой библиотеке поищите в документации, которая входит в комплект поставки.

16.5. Измерение покрытия кода

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

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

Командную утилиту

(и соответствующую библиотеку) написал Маурисио Фернандес (Mauricio Fernandez). Устанавливается она в виде gem-пакета.

В простейшем случае для ее запуска достаточно указать имя вашей программы в качестве параметра:

Одновременно с исполнением вашей программы

будет собирать статистику. По умолчанию она создает каталог , в котором вы найдете HTML-файлы. В файле представлены сводные результаты и ссылки на исходные тексты, где строки, которые хотя бы раз исполнялись, подсвечены.

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

Хотя программа

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

Можно использовать

и в качестве библиотеки для написания аналогичных инструментов анализа. Ее API состоит из трех основных классов:

• 

позволяет отличить исполняемые предложения от комментариев (и тем самым уточнить статистику покрытия);

• 

применяется для трассировки выполнения, возвращает информацию о покрытии и счетчики выполненных предложений;

• 

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

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

16.6. Измерение производительности

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

Конечно, быстродействие имеет значение. Иногда даже очень большое. Однако начинать думать об этом на раннем этапе цикла разработки — ошибка. Как говорится, «преждевременная оптимизация — источник всех зол»; эту мысль впервые высказал Хоар (Hoare), а потом подтвердил Кнут (Knuth). Или, перефразируя, сначала пусть работает правильно, а уж потом быстро». На уровне отдельного приложения эта рекомендация обычно оказывается хорошим эвристическим правилом, хотя для больших систем она, быть может, и не так актуальна.