Англійська для розробників Ruby on Rails

Rails сильно опирається на спільні конвенції, і словник, який з ним приходить — «жирна модель, худий контролер», «N+1 запит», «конвенція над конфігурацією» — має певне значення, яке легко зловживати, якщо ви нові в екосистемі. Цей підручник стосується англійської мови, яку використовують під час обговорення коду Rails з командою.

Ключовий словник

** Конвенція над конфігурацією ** — керівна філософія Rails, що розумні типові (назва, структура файлів, маршрутизація) у більшості випадків виключають необхідність явного налаштування. “Вам не потрібно вказувати назву таблиці в моделі — конвенція про конфігурацію означає, що Rails автоматично виводить її з назви класу.”

ActiveRecord callback — гачок ( before_save, after_commit ), який запускає код у певній точці життєвого циклу моделі, часто є джерелом прихованих, важко відстежуваних побічних ефектів. “Це after_save зворотне викликання тихо надсилає електронну пошту на кожне оновлення — це саме той вид прихованого побічних ефектів, який робить зневадження цієї моделі болючим.”

** N+1 запит ** — вада швидкодії, коли програма видає один запит для отримання списку, а потім один додатковий запит на елемент для отримання пов’ язаних даних, замість того, щоб завантажувати все заздалегідь. “Це перегляд запускає N+1 — додайте includes(:author) до запиту, щоб автори охоче завантажували один додатковий запит замість одного за пост.”

** Fat model, skinny controller ** — конвенція проектування, яка впроваджує бізнес- логіку у моделі (або об’ єкти сервісу) і зберігає контролери зосередженими на оркеструванні циклу запит/ відповідь. “Ця дія контролера має довжину сорок рядків — давайте слідувати fat-model-skinny-controller і пересунути цю логіку перевірки вниз до моделі.”

** Migration ** — файл Ruby з версіями, який описує поступову зміну схеми бази даних, виконання якої має на меті перевести схему у відомий стан. “Не редагуйте вже запущену міграцію безпосередньо — напишіть нову міграцію, щоб внести зміни, інакше ви розсинхронізуєте всіх, хто вже запустив стару міграцію.”

** Concern ** — модуль ( ActiveSupport::Concern ), який використовується для спільного використання поведінки між моделями або контролерами, шаблон Rails для змішування у логіці перетинів. “Замість дублювання цієї логіки м’якого вилучення по трьох моделях, перетягніть її в проблему і включіть її там, де це потрібно.”

Звичайні фрази

• «Чи буде цей зворотній виклик використовуватися в ситуаціях, яких ми не очікуємо, таких як масовий імпорт або скрипти-сімена?»
• «Чи ми охоче завантажуємо тут, або це збирається викликати N + 1 у виробництві?»
• Чи повинна ця перевірка жити в моделі, або вона належить до об’єкта сервісу, враховуючи, скільки логіки є?»
• «Чи ми написали нову міграцію для цього, чи ми редагували одну, яка вже працює?»
• «Чи це дійсно спільна поведінка, чи ми змушуємо дві неспоріднені моделі виглядати подібно?»

Приклади висловлювань

Перегляд запиту на звантаження: “Це зворотне викликання викликає зовнішній API- виклик під час збереження — це ризиковано всередині транзакції бази даних; чи можемо ми пересунути його до after_commit або до фонового завдання замість цього?”

Пояснення рішення про проектування:

• “Ми витягнули логіку ціноутворення в об’ єкт сервісу замість методу товстої моделі, оскільки три різні контролери мають викликати його незалежно від будь- якого конкретного екземпляра моделі.” *

Опис події: “Уповільнення почалося з N+1 на панелі управління — завантаження сотні замовлень тихо видає сто один запит.”

Професійні поради

• Скажіть “eager load”, а не “get it all at once” — це точний термін, якого очікують рецензенти Rails, коли обговорюють N+1 виправлень.
• Позначте побічні ефекти зворотного виклику явно з **“цей зворотний виклик має побічний ефект на…” ** — це звичайний шаблон перегляду коду Rails для виявлення прихованої поведінки.
• Використовуйте “convention over configuration”, коли пояснюєте, чому ви не додали явного config — це сигналізує, що ви навмисно, а не через пропуск, покладаєтеся на Rails-ідіоми.
• Розрізняйте **« міграція » ** від **« зміна схеми » ** у розмові — міграція — це файл з версіями; зміна схеми — це фактичний ефект бази даних, який вона створює.

Практичні вправи

1. Поясніть у двох реченнях, чому відбувається запит N+1 і як його виправляє завантаження з ентузіазмом.
2. Написати коментар перегляду коду у одному реченні, у якому буде позначено ризикований зворотній виклик ActiveRecord.
3. Опишете вашими словами різницю між вставленням логіки у товсту модель і вставленням її у об’ єкт служби.

Науковий ступінь: доктор технічних наук

Ядро ефективного спілкування в команді розробників Rails обертається навколо набагато більше, ніж просто синтаксис. Вона в основному зосереджена на * конвенції над конфігурацією *, об’єднуючи філософію, яка диктувала, як речі повинні бути структуровані для сприяння підтримці і співпраці. Багато не рідних англомовних людей вважають конкретну термінологію викликом, не через основні поняття - які часто досить логічні - але через нюанси у фразуваннях і очікуваннях навколо професійного спілкування. Це про те, щоб вийти за рамки простого зауваження того, що ви зробили («Я створив модель») і передати * чому * ви це зробили, і як ваша робота збігається з більш широкими цілями команди. Наприклад, розуміння різниці між «виправленням помилки» і «розв’язанням проблеми» драматично змінює сприйняту невідкладність і очікуваний підхід. Аналогічно, фрази на кшталт «Це технічно коректно, але не відповідає нашим конвенціям» потребують ретельної артикуляції — це про те, щоб запропонувати поліпшення, а не просто вказувати на помилки. Ключовим елементом є демонстрація того, що ви розумієте * чому * існує конвенція - що вона не довільна, а розроблена для ефективності і послідовності.

Іншою областю, де часто виникають нерозуміння, є опис життєвого циклу запиту, особливо при обговоренні відносин ActiveRecord. Просто сказати « Я з’ єднав моделі » недостатньо; вам слід описати, яким чином було оброблено запит — « Запитом було розпочато запит GET для отримання даних користувача з бази даних, які потім було відтворено у пов’ язаній моделі Post на основі зв’ язку зовнішнього ключа. » Такий рівень деталізації є ключовим під час обговорення питань швидкодії або зневадження. Також важливо активно повідомляти про потенційні проблеми * до того, як * вони стануть критичним. Наприклад, якщо ви очікуєте, що майбутня міграція може вплинути на існуючі запити, заява «Я додав індекс до цієї таблиці, щоб зменшити потенційне погіршення продуктивності під час наступних міграцій» демонструє передбачення і проактивне вирішення проблем - щось високо цінується в спільному середовищі розробки.

Нарешті, пам’ятайте, що коротке, чітке письмо є найважливішим. Розробники надзвичайно зайняті; їм потрібно швидко зрозуміти суть ваших коментарів, повідомлень про верифікацію або описів витягнутих запитів. Уникайте надто складних речень і жаргону, якщо це абсолютно не потрібно. Стремись к ясности превыше всего. Навчання, як конструктивно формувати зворотній зв’ язок - зосереджуючись на * впливі * зміни, а не просто критикуючи сам код - це критична вміння, яка значно покращить ваше спілкування та інтеграцію в команді.

# Example: Optimizing database queries using ActiveRecord's eager loading.
# This demonstrates efficient data retrieval in a Rails application.
# We are loading all related posts for each user to reduce the number of database round trips.
User.includes(:posts) # Eager loading relationships