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

Розмови про AdonisJS часто потребують обґрунтування вибору фреймворку з включеними батареями, а не збирання менших бібліотек, тому словник охоплює його конвенції, модель введення залежностей і компроміси, які виникають при структурі проти гнучкості.

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

** Батареї-включений фреймворк ** - філософія дизайну AdonisJS доставки маршрутизації, ORM, перевірки, автентифікації і тестування інструментів разом з коробки, а не вимагати команди зібрати їх з окремих пакунків. “Бути фреймворком, що включає батареї, саме тому ми обрали AdonisJS — ми не хотіли оцінювати і з’єднувати п’ять окремих бібліотек, тільки щоб отримати роботу з аутентифікації і перевірки.”

IoC контейнер — AdonisJS контейнер інверсії управління, який управляє як класи і їх залежності інстанційовані і пов’язані, дозволяючи обмінюватися або обманювати послуги без зміни коду споживання. “Оскільки ця служба розв’ язується за допомогою контейнера IoC, ми можемо обмінюватися в імітації реалізації для тестів без торкання контролера, який її використовує.”

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

Lucid ORM — вбудований ORM AdonisJS для взаємодії з реляційними базами даних, включаючи визначення моделей, міграції і створення запитів, за правилами Active Record-style. “Ми не мали потреби додавати Prisma або інший ORM — Lucid ORM обробляв міграції і моделі відносин, які нам були потрібні, як тільки вийшли з коробки.”

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

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

• «Чи є це батери-включений фреймворк насправді варте цього тут, або ж цей проект потребує більшої гнучкості, ніж стандартні параметри AdonisJS?»
• Чи ця залежність вирішується через контейнер IoC, або вона інстанційована безпосередньо, що зробить її насміхатися важче? ”
• Чи потрібний нам для цього спеціалізований постачальник послуг, чи може він просто жити всередині існуючого?»
• Чи варто нам використовувати вбудовані відносини Lucid ORM тут, або ж цей запит потребує чогось більш нетипового?»
• «Це пошкодження, тому що ми не дотримуємося конвенції над конфігурацією, або є реальна помилка в маршрутизації?»

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

Обґрунтування вибору системи для команди: “Ми вибрали AdonisJS, тому що це фреймворк, що включає в себе батареї — аутентификация, перевірка і ORM вже інтегровані, тому ми не підтримуємо клей код між окремими бібліотеками.”

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

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

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

• Обґрунтуйте вибір ** батарей-включаючи рамки ** з конкретним списком того, що ви не підтримуєте окремо — це сильніший аргумент, ніж загальна перевага за «менше налаштування»
• Пояснити контейнер IoC з точки зору можливості перевірки — це причина, чому залежність може бути чисто вимальована, що є конкретною перевагою, про яку турбуються рецензенти.
• Використовуйте provider, коли описуєте, де буде зареєстровано нові функціональні можливості — це допоможе новим співробітникам знайти правильний пункт для додавання прив’ язок.
• Попереджайте нових членів команди про конвенцію над конфігурацією на ранньому етапі — код, який «просто працює», доки не буде порушена конвенція іменування, є поширеним джерелом заплутаних ранніх вад.

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

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

На практиці: Навігація та співпраця

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

Одним з поширених сценаріїв є отримання коментаря перегляду коду. Уявімо, що колега вказав, що прив’ язка залежності втручання у вашому контейнері IoC виглядає занадто специфічно. Вони можуть написати: « Ця прив’ язка здається досить жорсткою; чи не могли б ми дослідити більш гнучкі альтернативи, щоб врахувати потенційні майбутні зміни? » Просто відповісти « Гаразд » недостатньо. Краще було б визнати свою занепокоєність, попросити про пояснення і пояснити свої аргументи. Ви можете сказати щось на зразок: «Це хороша думка — я хотів отримати чітке керування, щоб забезпечити [спеціальну вимогу], але я ціную те, що ви підкреслили потенціал майбутньої гнучкості. Чи можемо ми обговорити, яким чином можуть виглядати ці потенційні зміни?» Зауважте використання таких фраз, як «це хороша точка зору», «дякую за підкреслення», і «чи можемо ми обговорити». Це демонструє активне слухання і готовність розглядати альтернативні перспективи, ключові елементи професійного спілкування.

Аналогічно, при написанні описів запитів на завантаження, чіткість є найважливішою. Уникайте нечітких вказівок на зразок « Виправлено ваду » або « Оновлено код ». Замість цього надайте контекст: « Впроваджено новий механізм повторних спроб для з’ єднань з базою даних, щоб поліпшити стійкість до перехідних помилок. Цей спосіб вирішує проблему з перервними збоями з’ єднання, які спостерігалися під час пікових навантажень (див. # 42 у системі стеження за проблемами). » Використання точних слів — « стійкість », « перервне збої », « пікове навантаження » — демонструє ваше розуміння проблеми і надає цінну інформацію для переглядачів. Також важливо пояснити * чому * ви прийняли певне рішення, навіть якщо це здається вам очевидним. Не припускайте, що всі поділять вашу негайну інтуїцію; сформулюйте свій процес мислення.

Нарешті, пам’ятайте, що англійська в цьому контексті не тільки про технічну точність; це про будівництво довіри і взаєморозуміння в команді. Бути активним, ввічливим і готовим пояснити себе йде довгий шлях до створення позитивного і продуктивного середовища для розробки. Часто важливіше як ви спілкуєтеся, ніж що ви кажете.

Ось приклад використання adonis-lucid для демонстрації зміни у налаштуваннях бази даних:

# Example command to update the database connection string in a PR description
adonis migrate:refresh --database=development