Синтаксис и применение комментариев
Комментарии в Ruby начинаются с символа # и продолжаются до конца строки:
Чтобы улучшить читаемость комментария, рекомендуется поместить пробел после символа # (хотя это не обязательно).
При запуске программы комментарии не обрабатываются – интерпретатор Ruby полностью игнорирует их. Комментарии находятся в исходном коде и предназначены для людей, а не для компьютеров.
В простой программе Ruby комментарии могут предоставить дополнительную информацию о том, что происходит в каждой части кода:
Эти комментарии дают общее представление о том, что делает каждый раздел программы и как она работает.
В программе, которая выполняет итерацию по массиву и отображает его содержимое в виде списка HTML, вы можете увидеть более подробные комментарии:
Даже если вы пока не знакомы с map и join, комментарии дают вам представление о том, как должна работать эта программа и как может выглядеть результат. Чтобы узнать, как работает эта программа, поместите этот код в файл sharks.rb и запустите его.
Вы увидите вывод:
Комментарии в выводе не отображаются, так как интерпретатор их игнорирует.
Комментарии – отличный инструмент, особенно для новичков в программировании.
Комментарии пишутся с теми же отступами, что и код, который они объясняют. То есть, для определения класса без отступов комментарий пишется тоже без отступов. Каждый последующий уровень кода имеет отступы. Отступы комментариев должны совпадать с отступами кода, для которого они предназначены.
Для примера рассмотрим Ruby-реализацию игры Magic 8-Ball, в которой компьютер выдает случайный ответ на заданный вами вопрос
Обратите внимание, что комментарии имеют такие же отступы, что и код, с которым они связаны
Комментарии должны помогать программистам, которые так или иначе связаны с этим проектом. Это означает, что комментарии должны поддерживаться так же, как и код. Помните: программа с неправильными и устаревшими комментариями хуже, чем программа без комментариев.
К примеру, если человек знает Ruby, такой комментарий ему не нужен:
Этот комментарий очевиден, он просто повторяет то, что делает код. Хотя он и не влияет на вывод программы, это лишний шум при чтении кода.
Иногда комментарии должны предоставлять более подробную информацию. Вот для чего нужны многострочные комментарии.
Кеширование
Кеширование проектов — один из важнейших этапов разработки крупного интернет–проекта. В PHP имеются различные варианты кеширования данных. Эти варианты и инструменты прикручиваются, пристраиваются, приделываются, прикрепляются сбоку. До сих пор в сообществе PHP нет единого мнения: что лучше использовать, как лучше кешировать данные, какими инструментами пользоваться.
Ruby on Rails в его базовой комплектации имеет штатные средства кеширования данных. На старте предоставляются инструменты, позволяющие реализовать кеширование данных на проекте. Вы можете кешировать целые страницы или же блоки кода. Можете кешировать результаты запросов и ActiveRecord–модели. Кешировать можно как при помощи memcached или redis, так и другими средствами. Для реализации кеширования на Ruby on Rails проекте вам в 95 процентах случаев не потребуется ничего кроме уже готовых и штатных решений.
Системы контроля версий
При разработке любого Ruby on Rails проекта подразумевается использование известных систем контроля версий. Использование git, как говорится, «добровольно–принудительно», так как многие системы автоматического развертывания проекта на «боевых» серверах не работают без них. Программисты на RoR изначально, при изучении платформы, вынуждены осваивать git, так как многочисленные примеры кода в документации подразумевают использования данных систем контроля версий. Во многом из за этого неопытным новичкам проще начать изучать PHP и не трогать Rails до достижения определенного уровня понимания веб–разработки как таковой и ее принципов.
Скорость разработки
Основным преимуществом языка программирования Ruby и фреймворка Ruby on Rails считается скорость разработки. Практика показывает, что скорость разработки проектов на RoR увеличивается на 30–40 процентов по отношению к любому другому языку программирования или фреймворку. В первую очередь прирост скорости разработки определяется обширным набором готовых к работе штатных инструментов RoR, колоссальным набором готовых решений в сообществе, языку Ruby и простоте программирования на нем.
Одной из важнейших частей культуры RoR является социальность. Решил проблему, — помоги решить другим. Реализовал свой модуль, — поделись с сообществом. Таким образом, на данный момент в открытом доступе хранятся тысячи готовых решений тех или иных задач. Системы аутентификации, авторизации, комментирования, системы платежей, почтовые рассылки и многое другое (все то, что обычно разрабатывается «с нуля») внедряются реализованные кем–то другим, протестированные и рекомендованные многочисленным сообществом.
Миграции и работа с базой данных
Обыденная проблема многих проектов на PHP — невозможность понятными средствами и инструментами контроллировать структуру базы данных. Изменения в структуру зачастую вносятся вручную и прямо в базу. Из–за этого в проекте появляются многочисленные непонятные поля и таблицы, про которые уже никто ничего не помнит. В Ruby on Rails существуют штатные инструменты работы с базами данных — «миграции». Структура базы данных хранится в коде приложения и конфигурируется из проекта. Ваша структура будет всегда в репозитории, любое изменение структуры будет задокументировано и привязано к определенному коммиту в репозиторий.
Культура и стандарты
Ruby on Rails — это фреймворк. Зачастую фреймворк не позволяет вам самодеятельность. Конечно же, в Ruby on Rails можно «изобрести свой велосипед» и программировать в любых направлениях, не опираясь на стандарты; но зачастую этого не требуется. Стандарты размещения файлов в проекте, стандарты написания кода в проекте, общие правила программирования в Ruby on Rails сильно структурируют любой проект. За счет этого проект становится читаемым. Вхождение в проект новичков происходит очень быстро. Опыт показывает, что любой новичок в проекте в первый же день работы делает свои первые полезные правки. За счет этого не считается большой проблемой, если разработку проекта изначально вела одна команда программистов, а поддержку проекта или доработку — совершенно другая. Проект на RoR априори понятен любому разработчику.
