IRB vs Pry: кто твой интерактивный друг

Каждый Ruby-разработчик знает: когда код ведёт себя как капризный подросток, интерактивная консоль — последний оплот здравомыслия. Но какой инструмент выбрать: старый добрый IRB или харизматичный Pry? Разберёмся на примерах, боли и даже немного философии.

🧠 Теория: зачем вообще нужны REPL?

REPL (Read-Eval-Print Loop) — это интерактивная среда, где можно:

Быстро проверить идею без создания файлов
Отлаживать код как хирург с лупой
Исследовать объекты на лету

В Ruby есть два главных игрока:

	IRB	Pry
Стандарт	Встроен в Ruby	Требует установки
Философия	“Минимализм”	“Дайте мне всё!”
Суперсила	Надёжность	Интроспекция

🔧 Практика: базовое использование

IRB: как старый друг

# Запуск
$ irb

# Простейший пример
irb(main):001> 2 + 2
=> 4

# Работа с классами
irb(main):002> class Foo; def bar; "baz"; end; end
=> :bar

Pry: как швейцарский нож

# Установка
$ gem install pry

# Запуск с подсветкой
$ pry

# То же сложение, но с цветами
[1] pry(main)> 2 + 2
=> 4

# Плюс магия интроспекции
[2] pry(main)> ls Hash

💡 Ключевые отличия

1. Интроспекция объектов

Pry побеждает с разгромным счётом:

# Просмотр методов объекта
pry(main)> cd ActiveRecord::Base
pry(ActiveRecord::Base):1> ls -M

# Просмотр исходного кода
pry(main)> show-method User#save

В IRB для этого придётся писать User.instance_methods.sort и рыться в документации.

2. Навигация по стеку вызовов

Когда всё падает, Pry становится детективом:

def problematic_method
  binding.pry # Остановка здесь
  some_buggy_code
end

# В консоли Pry:
pry(main)> whereami  # Покажет текущий контекст
pry(main)> up        # Подняться по стеку
pry(main)> down      # Опуститься обратно

IRB предлагает лишь caller, что похоже на чтение телефонной книги без очков.

� Боль и антипаттерны

Когда Pry может навредить

В production
Оставить binding.pry на продакшене — как забыть включить сигнализацию в ювелирном. Используйте pry-remote осознанно.
При работе с потоками
Pry иногда ведёт себя как кот в комнате с шарами — непредсказуемо.
Когда нужна скорость
Запуск Pry с кучей плагинов (pry-rails, pry-doc, pry-byebug) может быть медленнее IRB.

Когда IRB недостаточно

# Попытка исследовать объект в IRB
irb(main)> user = User.first
irb(main)> user.methods.grep(/name/) # Ох...

# То же в Pry
pry(main)> user = User.first
pry(main)> cd user
pry(#<User>):1> ls -M | grep name

🛠 Интеграция с Rails

Pry + Rails = ❤️

Добавьте в Gemfile:

group :development do
  gem 'pry-rails'
  gem 'pry-byebug'
end

Теперь:

rails console запускает Pry вместо IRB
Отладка с пошаговым выполнением (next, step)
Автодополнение работает из коробки

IRB: минималистичный подход

Хотите “ванильный” опыт? В .irbrc можно добавить:

# Автозагрузка Rails-окружения
if defined?(Rails)
  require 'rails/console/app'
  require 'rails/console/helpers'
end

Но готовьтесь к ручному труду.

🎤 Что сказать на собеседовании

— Почему вы используете Pry вместо стандартного IRB?

— Для сложной отладки Pry предлагает инструменты уровня “нейрохирургия”: навигацию по стеку, интроспекцию объектов и плагины. Хотя для простых задач иногда достаточно IRB — как швейцарский нож против скальпеля.

� Реальная история из практики

Сценарий: В production падает фоновый джоб, но лог говорит лишь “undefined method for nil:NilClass”.

IRB-подход:

Добавить логи в 10 мест
Задеплоить
Ждать следующего падения
Повторять 5 раз

Pry-решение:

def perform
  # ...
  binding.remote_pry if Rails.env.production? # Подключаемся через pry-remote
  problematic_code
end

И сразу видим состояние объекта в момент падения. Время на решение: 15 минут против 2 часов.

🧾 Вывод

Выбирайте инструмент под задачу:

IRB — для быстрых проверок и “чистого” Ruby
Pry — для сложной отладки и исследования кода