Привет. Небольшой дисклаймер: Пост выкладываю больше на поговорить, чем чем-то поделиться. Я был удивлен, какая это неоднозначная тема в руби комьюнити. Вот интересно узнать мнение русского среза.
Ruby давно славится своей гибкостью и удобным синтаксисом, позволяющим быстро создавать прототипы да и не только их. Однако эта свобода имеет свою цену: по мере роста проектов поддержка и отладка становятся всё более затратными.
Многие разработчики считают статическую типизацию ненужным препятствием, замедляющим работу. Но, как и автоматические тесты, статическая типизация (с помощью RBS или Sorbet) — это инвестиция, которая окупается с лихвой. Она не только ускоряет разработку после первоначального освоения, но и служит бесплатной документацией, облегчая поддержку кода и снижая общие издержки.
Баланс: первоначальные усилия против долгосрочной эффективности
Внедрение статической типизации в Ruby действительно требует начальных усилий. Нужно изучить RBS или Sorbet, а также аннотировать существующий код. Однако эта инвестиция поможет уже в скором времени:
уменьшить количество ошибок во время выполнения, что означает меньше времени на отладку.
приведет к понятному, самодокументируемому коду, облегчающему адаптацию новых разработчиков.
позволит проводить более безопасный рефакторинг.
Если ваша команда тратит часы на поиск ошибок, вызванных неожиданными аргументами методов или значениями nil, статическая типизация значительно сократит это время.
Сигнатуры типов как бесплатная документация
Как часто вы открывали код на Ruby и не могли понять, какие параметры ожидает метод и что он возвращает? В динамически типизированных языках приходится догадываться, читать тесты или искать документацию (если она есть), ну или курить код.
Со статической типизацией код сам предоставляет эти ответы. Вместо расплывчатых комментариев вроде:
# Обрабатывает заказ и возвращает подтверждение
# @param order [Order] - заказ для обработки
# @return [String] - сообщение подтверждения
def process_order(order)
# логика метода
end
можно определить это с помощью RBS или Sorbet, обеспечивая актуальность и точность информации:
sig { params(order: Order).returns(String) } # Пример для Sorbet, но можно использовать и rbs-inline
def process_order(order)
# логика метода
end
Теперь каждый разработчик, читающий этот метод, сразу понимает, чего ожидать, без необходимости полагаться на устаревшие комментарии.
Предотвращение ошибок до их возникновения
Гибкость Ruby позволяет быстро вносить изменения, но также упрощает внесение различных ошибок. Простые ошибки, такие как передача аргумента неправильного типа, могут остаться незамеченными до тех пор, пока не вызовут проблемы в продакшене.
Рассмотрим распространённую ошибку:
def add_numbers(a, b)
a + b
end
add_numbers("10", 5) # Ошибка во время выполнения!
Да, пример тупой, но, проявив воображение, можно придумать 100500 реальных сложных примеров, когда вот так легко ошибиться можно на раз-два.
С помощью проверки типов эта проблема была бы обнаружена сразу:
# @rbs (Integer, Integer) -> Integer
def add_numbers(a, b)
a + b
end
Статическая типизация предотвращает такие неожиданные ошибки во время выполнения, экономя время на отладку и снижая уровень разочарования.
Безопасный и предсказуемый рефакторинг
Если вы работали над крупным проектом на Rails, вы знаете, насколько пугающим может быть рефакторинг. Изменение сигнатуры метода может незаметно сломать множество частей приложения.
Со статической типизацией ваш редактор и проверяльщик типов сразу укажут на все места, где требуется изменение. Больше не нужно надеяться, что тесты поймают всё — статическая типизация делает рефакторинг предсказуемым и спокойным процессом.
Если вы всерьёз настроены создавать поддерживаемые приложения на Rails, которые масштабируются без головной боли, статическая типизация — мощный инструмент, который не стоит игнорировать.
ЗЫ: Статическая типизация, как и тесты, да как и стиль кода - это выбор каждого. Можно взять и использовать от и до, можно лишь взять то, что нужно для конкретного проекта. Статическая типизация отлично работает как с новыми так и уже со старыми проектами. Необязательно покрывать весь код типами данных. Вы сами решаете что да как.
Буду рад любому обсуждению в комментариях. За / Против / А поговорить - любоей подойдет.
Если просто хочется быть в теме, то я веду ежемесячную рассылку по статической типизации в Ruby: link.
Мой личный опыт показывает, что в больших проектах, когда надо общаться с большим количеством апей и разными протоколами, статическая типизация вредит намного больше, чем решает чего-то.
Зачастую проблема возникает в том, что другое АПИ ответило "10" вместо 10. Тогда вообще чистый Яваскрипт всем в помощь, потому что в нём всем этим каком управлять намного проще.
А типопроверки и дебаг можно оставить на ЛЛМках. Они это просечь могут задолго до того, что надо будет вводить типизацию.
ПЫСЫ.
Странно, пост со скидкой для вастрикан, но при этом - публичный. А если прочитать статью, то она сама по себе состоит из 13 абзацев и просто пиарит твои курсы. Самого по себе содержания в этой статье - кот наплакал. "Берите статическую типизацию, она вам нужна, спасибо".
Как-то не по правилам контента, и ничего полезного в клуб не вносит. @moderator
Все разы когда я пытался сделать заход в типизацию руби — оно всегда было как–то через жопу. Я до сих пор не понимаю как:
1 аннотировать гемы (не самому же)
2 метапрограммирование
Кроме этого, я так понимаю вывода типов у нас все еще нет. Кажется что за типизацией проще пойти в другое место 🙂
Какой оверхед даёт использования Сорбета или аналогов с точки зрения перфоманса?
Страйп заявляет, что никакой потери от использования сорбета нет (я не проверял). Но могу точно сказать что у RBS нет никакой потери как минимум из-за того, как все устроено - у RBS типы это либо обычные комментарии, либо .rbs файлы: которые никак и никем на продакшене не грузятся.