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

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

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

Model — клас Python, який визначає форму таблиці бази даних, включаючи її поля і відносини, що служить єдиним джерелом правди, яке використовує Django для створення фактичної схеми.

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

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

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

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

** Проміжне програмне забезпечення ** — компонент, який обробляє запити і відповіді глобально перед тим, як вони досягнуть перегляду або після повернення перегляду, використовується для вирішення таких загальних завдань, як автентифікація, ведення журналу або заголовки CORS. “Повідомлення 403 надходить не з самого перегляду — в стеку є посереднє програмне забезпечення, яке відкидає запит до того, як він досягне вашої перевірки дозволів.”

** Signal ** — механізм, за допомогою якого одна частина програми може сповіщати інші частини про те, що відбулася певна подія, наприклад, збереження моделі, без безпосереднього зв’ язку цих частин одна з одною. “Цей побічний ефект відбувається через сигнал post_ save на моделі, а не через щось у цьому перегляді — перевірте signals.py перед тим, як припустити, що вада є тут.”

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

• Чи це міграція на рівні схеми, чи вона також потребує міграції даних?»
• Чи цей набір запитів дійсно оцінюється один раз, чи він перезапитує кожен раз, коли його використовують?»
• «Яке середнє програмне забезпечення перехоплює цей запит перед тим, як він потрапляє в перегляд?»
• Чи це поведінка, що походить від сигналу десь, або це відбувається безпосередньо в перегляді?»
• Чи міграція застосовується в кожному середовищі, чи тільки локально?»

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

Перегляд перенесення у запиті на звантаження:

• “Ця міграція додає стовпчик NOT NULL без типового значення, що призведе до невдачі у порівнянні з існуючими рядками у виробничій версії — або додайте типове значення, або розділіть цю міграцію на дві: додайте стовпчик з нульовими значеннями, заповніть його, а потім зробіть його обов’ язковим.” *

Зневадження проблеми з швидкодією набору запитів: “Проблема з N+1 запитом тут виникає з доступу до .author.name всередині петлі — використання select_related('author') на оригінальному наборі запитів витягне ці дані в одному з’єднанні замість одного запиту на рядок.”

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

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

• Розрізняйте ** міграцію схеми ** від ** міграції даних ** явно у переглядах — перша змінює структуру, друга змінює дані, і об’ єднання їх є поширеним джерелом виробничих інцидентів у великих таблицях.
• Використовуйте queryset, а не просто «запит», коли обговорюєте продуктивність ORM — це означає, що ви розумієте модель лінивого оцінювання Django, яка зазвичай є справжньою причиною проблем N+1.
• Назвіть конкретне ** середнє програмне забезпечення **, відповідальне за несподівану поведінку запиту, замість того, щоб описувати його нечітко як « щось у конвеєрі запиту » — це буде вказувати членам команди безпосередньо на потрібний файл.
• Флаг ** сигнал **-засновані побічні ефекти явно в перегляді коду - їх легко пропустити, тому що вони не видимі на сайті виклику, і незадокументовані сигнали є повторюваним джерелом заплутаних помилок.

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

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

Національна мова: мова, що використовується для спілкування ненаціональними групами

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

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

Крім того, важливо освоїти словниковий запас, що оточує взаємодії з базами даних. Такі терміни, як «міграція схеми», «модель даних» і «оптимізація запиту ORM» є не просто технічним жаргоном; вони мають певні наслідки при обговоренні продуктивності або потенційних проблем з цілісністю даних. Не вагайтеся попросити про пояснення - це нескінченно краще визнати, що ви не розумієте термін, ніж ризикувати неправильно інтерпретувати його значення і запропонувати неправильне рішення. Пам’ятайте, ваша команда там, щоб підтримувати вас, і чітке спілкування сприяє співпраці. Нарешті, розуміння загальних ідіом, що використовуються в технічних дискусіях, таких як «розрив змін», «залежна ін’єкція» або «DRY (не повторюйте себе)» значно поліпшить вашу здатність повністю брати участь у цих розмовах.

Ось приклад, який показує, яким чином цей словник можна використовувати у практичному випадку:

# Example: Running Django migrations after updating a model definition
python manage.py makemigrations myapp
python manage.py migrate

Ця проста команда підкреслює необхідність чіткого повідомлення про те, * чому * виконується міграція (« Оновлення схеми MyModel ») і потенційний вплив змін на існуючі дані або програми. Спрямування уваги на точність мови не лише покращить ваш технічний внесок, але також створить довіру і зміцнить ваші стосунки з колегами.