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

Итак, почему я решил перейти с загрузки Spring на Ruby On Rails?
Прежде чем рассказать вам об этом, мне нужно рассказать короткую историю:

Жил-был бедный разработчик, его зовут «Джо», однажды Джо получил задание в своей работе, задание казалось простым:

"Джо, тебе нужно изменить наш код Java, чтобы обычные пользователи могли удалять элементы"

Джо был младшим разработчиком, и Джо подумал: «Хммм, хорошо, я сделаю это», поэтому коллеги Джо дали ему загрузочный проект Spring, ответственный за такие вещи. К сожалению, обычно каждая задача в области ИТ плохо документирована, поэтому Джо тратит много времени, пытаясь найти, где часть кода, отвечающая за работу с обычными пользователями и пользователями «Администратор», через некоторое время Джо наконец нашел функции, позволяющие удалять элементы с сайта. Но Джо замечает что-то неладное… Всего за это отвечают 4 функции, не одна, Джо пытается решить задачу и пока он пытается ему нужно протестировать свои решения, но когда он решил Тестировать, то находит новую проблема... IDE, стоящая за кодом, на компьютере Джо работала чертовски медленно! Мало того, каждый раз, когда Джо пытается изменить свою IDE, код просто не работает, Джо попадает в тюрьму из-за IDE… Так что, несмотря на медлительность, Джо решил продолжить свои тесты кода, но это не очень хорошо сработало. . На каждую попытку Джо тратил 10 минут только на ЗАПУСК простого теста, его компьютер очень медленно справлялся с этим, через две недели Джо наконец нашел решение этой проблемы, и когда он решил доставить свое решение клиенту, клиент сказал Джо:
«Джо, твое решение работает с учетными записями, которые мы тебе даем, но у нас есть другие учетные записи, которые не работают с твоим кодом, возможно, мы должны предоставить тебе другие учетные записи для тест перед тем, но ... Нам все равно. В любом случае, решайте проблему сами»

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

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

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

Соглашение о конфигурации — вы не снежинка

Это первый девиз, который вы должны усвоить при изучении Rails, соглашение ДОЛЖНО БЫТЬ выше любой конфигурации, если ваш код использует соглашение, никому не нужно будет ломать голову, пытаясь найти проблему, которую должна решить та или иная функция. Но что на самом деле означает «соглашение важнее конфигурации»?

Я приведу простой пример, чтобы понять, что, представьте, если вы когда-нибудь работаете в компании, стоящей за известным веб-сайтом, на этом сайте у вас есть такие вещи, как:

  • Страница, на которой вы найдете все содержимое сайта
  • Еще одна страница, на которой вы создаете новый контент
  • И еще одна страница, где вы редактируете контент

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

  • Страница, на которой вы найдете все содержимое сайта
  • Еще одна страница, на которой вы создаете новый контент
  • И еще одна страница, где вы редактируете контент

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

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

  • Индекс используется на главной странице вашего сайта, это главный контроллер
  • Показать используется для указанного содержания.
  • Редактировать, уничтожить…Я думаю, вы уже поняли

Если вы являетесь разработчиком загрузки Spring, вы можете подумать: «Но у нас также есть это в Spring, это причина использовать геттеры и сеттеры», нет, вы этого не сделаете, потому что идея Rails заключается в том, чтобы использовать максимально возможное соглашение, пока вы не Не нужно тратить свое время, пытаясь найти, где что-то.

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

Рельсы Драгоценные камни

Еще один хороший компонент Rails — возможность использовать Gems! Что такое драгоценные камни? По сути, гемы — это библиотеки, которые позволяют любому рубисту добавлять что-то в код, ничего не написав. Если вы работаете со Spring Boot, возможно, вы думаете: «Подождите, мы делаем это с помощью Maven!»

О, мой дорогой друг, это другое… Например, если я хочу добавить в свой код редактор форматированного текста, мне просто нужно сделать три вещи:

  • Сначала введите «Rails gem action_text:install».
  • Во-вторых, в модели напишите «has_rich_text :body».
  • В-третьих, в представлении укажите «‹%= form.rich_text_area :body %›».

И вы получаете свой текстовый редактор, вот и все.

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

"Хорошо, я понял, но все равно не думаю, что это лучшая причина для выбора Rails".

То, что я здесь написал, это лишь один из 9 аспектов философии Rails, остальные вы можете найти на этом сайте:
https://rubyonrails.org/doctrine

Я знаю, что Rails больше не является популярным фреймворком, славные дни популярности остались в прошлом, в 2000-х годах… Но причина, по которой так много людей до сих пор разрабатывает Rails, заключается в том, что Rails действительно заботится о своих разработчиках… Мне это не нужно. конкретную IDE для программирования, мне не нужно тратить недели на поиски одной функции для решения моей проблемы, и, самое главное, мне не нужно тратить время на что-то очень медленное и многословное.

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