Цените интегрированные системы

Ruby on Rails можно использовать для разных целей, но его конек — это монолитные интегрированные системы. Такие системы нацелены на решение всей задачи совокупно. Через Rails проходит все, начиная от генерации JavaScript для мгновенного обновления страниц, и заканчивая миграцией базы данных от одной версии к другой, когда проект уже в эксплуатации.

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

Именно упор на расширение возможностей отдельного разработчика подталкивает нас к интегрированным системам. Интегрированная система позволяет убрать ненужные абстракции, уменьшить дублирование между слоями (например, использовать одни и те же шаблоны на сервере и на клиенте), а самое главное — до последнего не допустить перехода к распределенной архитектуре.

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

Увы, иногда без распределенной архитектуры не обойтись. Если вашему веб-приложению нужен API-интерфейс, к которому пользователи будут обращаться по HTTP, то ничего не поделаешь — придется решать почти все упомянутые проблемы. Остается порадоваться, что работа со входящими запросами куда проще, чем с исходящими, ведь если ваш интерфейс какое-то время не будет работать, то проблемы будут не у вас, а у потребителя этого интерфейса. По крайней мере в таком случае неудобства, которые вам как разработчику придется претерпеть, не столь велики.

Плохо, когда система преждевременно дробится на сервисы или, что еще хуже, на микросервисы. Бытует мнение, что при разработке «Современного Интернет-Приложения» неизбежно придется строить одну и ту же систему много раз: один раз на стороне сервера, один раз на стороне клиента в виде JavaScript MVC, по одному разу для каждой мобильной платформы, и так далее. Но это требование ничем не обусловлено, так делать совершенно необязательно!

Можно запросто использовать одни и те же элементы системы для разных задач и способов доступа. Завести единый набор контроллеров и представлений и для десктопных браузеров, и для нативных мобильных приложений. Сосредоточить как можно больше функций в монолитной интегрированной системе.

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

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

Прогресс превыше стабильности

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

Но, если мы будем слишком внимательно прислушиваться к голосам консерватизма, мы никогда не увидим другой стороны медали. Мы должны иногда брать на себя смелость и изменять условия, по каким все должно развиваться и расти. Именно это развитие сохранит Rails: и его выживание, и процветание в течение десятилетия (десятилетий?) в будущем.

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

Это не некая вседозволенность причинять кому-то ненужную или чрезмерную боль. Большой Переход от Rails с версии 2.x до версии 3 все еще будоражит раны тех, кто был причастен к этому переходу. Это было тяжело. Серьезный переполох, который многих оставил на версии 2.x на долгое время, причем некоторых из них уже было оттуда не вернуть. Но, по великой схеме вещей, это все равно стоило того.

Это тяжелые решения, которые мы должны продолжать делать. Сделают ли Rails лучше в течении будущих пяти лет изменения, которые мы делаем сегодня? Станет ли Rails лучше для адаптации стека новых задач, например очередей сообщений или WebSockets, в ближайшие годы? Если да, то давайте закатаем рукава и займемся работой.

Эта работа — не просто то, что должно произойти исключительно в Rails, но и в более крупном сообществе самого языка Ruby. Rails должен находиться на переднем крае разработки, помогая продвижению Ruby, заставляя его составляющие быстрее использовать более поздние версии.

До сих пор мы очень хорошо справлялись с этим. С того момента, как я начал, мы прошли через Ruby версий 1.6, 1.8, 1.9, 2.0, 2.1, 2.2 и теперь на 2.3. Множество серьезных изменений произошло на этом пути, но Rails непосредственно присутствовал и участвовал в них, чтобы иметь под капотом Ruby, и помочь каждому быстрее осуществлять процесс разработки. Эта отчасти привилегия, а отчасти и обязательство Rails, является основой популяризации Ruby.

Это также верно для вспомогательных инструментов рабочего процесса. Bundler когда-то был спорной идеей, но по настоянию Rails о том, что это будет краеугольным камнем совместного будущего, сегодня это само собой разумеющийся инструмент де-факто. Это так же касается таких инструментов и технологий как asset pipeline (файлопровод) и Spring, предварительный загрузчик приложений Rails. Все три инструмента прошли стадию укоренения, или же продолжали переживать боль роста, но очевидность их ценности в долгосрочной перспективе помогла нам преодалеть это.

Прогресс, в конечном счете, в основном связан с людьми и их готовностью продвигать изменения. Вот почему в таких группах, как Rails Core или Rails Committers, не сидят без дела. Обе группы предназначены для тех, кто активно работает над достижением прогресса для фреймворка. Для некоторых, их вклад в такой прогресс может измеряться всего несколькими годами, и мы будем навсегда благодарны за их труд, а для других это может продолжаться десятилетиями.

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

Возведите большую палатку

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

Именно по этому мы так не делаем!

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

Итак, хотя этот документ многое описывает в идеалистическом ключе, повседневная реальность гораздо тоньше (и интереснее). Rails способен поддерживать такое большое сообщество в одной палатке именно потому, что в его культуре очень мало неких «тестов на единственно верный подход», если они вообще есть.

По мере непрекращающегося развития RSpec, DSL для тестирования, я часто выражал серьезное недовольство, и это отлично иллюстрирует сказанное выше. Я могу разглагольствовать до посинения, так как не считаю Rspec серьезной затеей, а он несмотря на это и процветал, и процветает как технология. И это гораздо важнее, нежели выбор какой-то одной, «единственно верной» технологии!

То же самое можно сказать о режиме Rails в качестве HTTP API. В то время, как я лично предан и сосредотачиваюсь на интегрированной системе, включающей в себя виды (представления), несомненно Rails может многое предложить и разработчикам, желающим разделить свое приложение на клиентскую и серверную часть (бекенд и фронтенд). Мы должны принять это, поскольку такие решения могут развиваться в Rails как второстепенные, и я уверен, что это возможно.

Однако «иметь большую палатку» — не значит пытаться угодить всем и каждому. Это просто означает, что вы приветствуете всех людей на вечеринке и позволяете им «приносить свои напитки». Мы не должны терять ни одного из наших приверженцев или наших ценностей, предлагая другим присоединиться к нам, и мы вполне можем научиться смешивать новые вклады («напитки») пришедших с теми, что уже существуют.

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

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

Большое спасибо за перевод railsfun

Ruby on Rails соглашение. Часть 4