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

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

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

** Eager loading ** — завантаження пов’ язаних моделей Eloquent перед батьківським запитом, за допомогою with(), щоб уникнути запуску окремого запиту для кожного пов’ язаного запису. “Це перегляд запускає запит N+1 — давайте завантажимо зв’язок comments з with('comments') замість того, щоб ліниво завантажувати його в петлі.”

Service container — контейнер Laravel для введення залежностей, відповідальний за автоматичне розв’ язання класів і їх залежностей, а також за реєстрацію прив’ язок. “Прив’ язати інтерфейс до конкретної реалізації у постачальнику послуг, щоб контейнер міг розв’ язати його автоматично, де б він не був підказкою типу.”

Facade — інтерфейс зі статичним виглядом (наприклад, Cache::get() ), який виконує роль проксі до базового класу, розв’ язаного з контейнера служби, надаючи простий синтаксис без втрати можливості тестування. “Навіть якщо Cache::get() виглядає статичним, це фасад — під капотом він розв’язує справжній кеш-приклад з контейнера, тому він все ще піддається насмішкам в тестах.”

** Migration ** — файл PHP з керуванням версіями, який описує зміну схеми, виконаний для підтримки синхронізації структури бази даних у різних середовищах.

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

** Job / queue ** — клас, що представляє одиниці відкладеної роботи, відправлені до черги і оброблені асинхронно працівником, використовується для повільних або некритичних завдань.

• “Пересунути створення PDF- файла рахунка до завдання у черзі — зараз його виконують синхронно у запиті і додають три секунди до завершення.” *

Middleware — клас, який перехоплює HTTP- запити перед тим, як вони досягнуть контролера маршруту, використовується для перетинаючих запитів, таких як автентифікація або обмеження швидкості. “Ми повинні додати цю перевірку як середнє програмне забезпечення, а не повторювати її на початку кожного методу контролера — це загальна проблема, а не логіка, специфічна для маршруту.”

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

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

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

Перегляд запиту на звантаження: “Цей контролер переслідує замовлення і викликає $order->customer всередині петлі — це запит N+1, давайте завантажимо customer в початковому запиті замість цього.”

Пояснення рішення про проектування: “Ми прив’язали інтерфейс платіжного шлюзу до конкретної реалізації Stripe в провайдері послуг, тому зміна провайдерів пізніше є зміною в одному рядку, а не рефактором кодової бази.”

Опис вади:

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

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

• Скажіть “N+1 запит” точно, коли описуєте проблему охочого завантаження — це стандартний термін, який шукають рецензенти, більш конкретний, ніж “надто багато запитів”
• Під час перегляду фасадного класу, запитайте “чи це все ще перевіряється?” — фасади можна насміхатися, але надмірне використання все ще може зробити намір неясним в перегляді.
• Розрізняти « у черзі » від « синхронного » під час опису місця виконання завдання — це впливає як на затримку, сприйнятий користувачем, так і на обробку помилок.
• Використовуйте “сервісний провайдер”, коли пояснюєте, де зареєстровано прив’ язку — сказати «десь у контейнері» занадто нечітко для перегляду коду.

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

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

Навигація по сторінках — це практичний підхід

Як розробник Laravel, ви витрачаєте значну кількість часу на спілкування про свій код - в основному через запити на витягування, перегляд коду, повідомлення Slack і документацію. Хоча технічна точність є найважливішою, чітка і точна англійська мова є ключовою для співпраці, забезпечуючи, щоб кожен розумів * чому * за кодом, а не тільки * що *. Легко застрягти в надто технічному жаргоні, але зосередження на фразування, що сприяє розумінню і конструктивному зворотньому зв’язку, значно покращить ефективність вашої команди. Поширеною проблемою є неоднозначність при описі складної зміни. Замість простого повідомлення «виправлена помилка», розгляньте можливість оформлення його як «Розв’ язано крайовий випадок, пов’ язаний з перевіркою даних під час реєстрації користувача», негайно надаючи контекст для обсягу і потенційних наслідків. Аналогічно, в перегляді коду, рухаючись від «Це потрібно виправити» до «Я помітив потенційну умову гонки тут - чи можемо ми дослідити використання мутекс або реалізацію системи черги, щоб зменшити цей ризик?», Демонструє глибше розуміння і запрошує обговорення оптимальних рішень.

Іншою часто зустрічається ситуацією є пояснення технічних рішень в Slack. Замість того, щоб сказати « Використання контейнера сервісу », що може збентежити розробників, які не є Laravel, поясніть « Використання контейнера сервісу дозволяє нам відокремити наші компоненти і поліпшити перевіряність — це ключовий аспект дизайну Laravel. » Навіть здавалося б невеликі фрази мають значення; використання « upstream » замість « з іншого джерела » підкреслює сприйняття відносин. Будьте особливо уважними під час документування змін у описах PR — важливо дати докладні пояснення, зосередившись на тому, що було змінено, чому це було змінено і як це впливає на решту програми.

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

Ось приклад використання команди enqueue з Laravel Queue для опису завдання:

# Enqueue a background job to process large CSV files
php queue-worker --timeout=60 --delay=30 myapp.csv

Ця проста команда, коли описана чітко – «Ми поставили в чергу нового працівника для обробки файлу myapp.csv у фоновому режимі, використовуючи 60-секундний тайм-аут і 30-секундну затримку для початкової обробки» – демонструє як технічну майстерність, так і ефективне спілкування.