Крок 5: Вирішення проблем

5.2 version
Maintained

Вирішення проблем

Налаштування проекту також полягає у наявності правильних інструментів для відлагоджування проблем.

Встановлення додаткових залежностей

Пам’ятайте, що проект було створено з дуже малою кількістю залежностей. Без шаблонізатора. Без інструментів для відлагоджування. Без системи логування. Ідея полягає в тому, що ви можете додавати більше залежностей як тільки вони вам знадобляться. Навіщо вам така залежність як шаблонізатор, якщо ви розробляєте HTTP API або CLI інструмент?

Як ми можемо додати більше залежностей? За допомогою Composer. Окрім «звичайних» пакетів Composer, ми будемо працювати з двома «особливими» видами пакетів:

  • Компоненти Symfony: Пакети, які реалізують основний функціонал та абстракції низького рівня, які потрібні для роботи більшості застосунків (маршрутизація, консоль, HTTP-клієнт, поштовий клієнт, кеш, …);
  • Бандли Symfony: Пакети, які надають функціонал високого рівня або забезпечують інтеграцію зі сторонніми бібліотеками (бандли розробляються, в основному, спільнотою).

Для початку додаймо Symfony Profiler — заощаджувач часу, коли вам потрібно знайти першопричину проблеми:

1
$ symfony composer req profiler --dev

profiler — це псевдонім для пакету symfony/profiler-pack.

Псевдоніми — це не особливість Composer, а концепція надана Symfony, щоб полегшити ваше життя. Псевдоніми — це ярлики для популярних пакетів Composer. Хочете ORM для вашого застосунку? Встановіть orm. Хочете розробити API? Встановіть api. Ці псевдоніми автоматично задаються для одного або декількох звичайних пакетів Composer. Псевдоніми призначаються основною командою Symfony.

Ще одна приємна особливість — ви можете не вказувати постачальника symfony. Використовуйте cache замість symfony/cache.

Порада

Пам’ятаєте, ми згадували про плагін Composer із назвою symfony/flex? Псевдоніми — одна з його особливостей.

Розуміння середовищ Symfony

Ви помітили прапорець --dev у команді composer req? Оскільки Symfony Profiler корисний лише під час розробки, ми хочемо уникнути його встановлення у продакшн.

Symfony підтримує поняття середовища. За замовчуванням, є вбудована підтримка трьох: dev, prod та test, але ви можете додати скільки завгодно. Усі середовища використовують той самий код, але представляють різні конфігурації.

Наприклад, усі інструменти налагодження включені в середовищі dev. У prod застосунок оптимізований для максимальної продуктивності.

Перехід від одного середовища до іншого можна здійснити, змінивши змінну середовища APP_ENV.

Під час розгортання в SymfonyCloud, середовище (зберігається в APP_ENV) автоматично перемикається на prod.

Управління конфігураціями середовища

APP_ENV можна встановити, використовуючи «реальні» змінні середовища у вашому терміналі:

1
$ export APP_ENV=dev

Використання реальних змінних середовища є кращим способом для встановлення таких значень, як APP_ENV на продакшн-серверах. Але у середовищі для розробки, необхідність встановлення великої кількості змінних середовища може бути занадто громіздким рішенням. Замість цього їх можна визначити у файлі .env

Актуальний файл .env було згенеровано автоматично, під час створення проекту:

.env
1
2
3
4
5
6
###> symfony/framework-bundle ###
APP_ENV=dev
APP_SECRET=c2927f273163f7225a358e3a1bbbed8a
#TRUSTED_PROXIES=127.0.0.1,127.0.0.2
#TRUSTED_HOSTS='^localhost|example\.com$'
###< symfony/framework-bundle ###

Порада

Будь-який пакет може додати до цього файлу більше змінних середовища завдяки рецепту, який використовує Symfony Flex.

Файл .env зафіксований у репозиторії та описує значення за замовчуванням з продакшн. Ви можете змінити ці значення, створивши файл .env.local. Цей файл не повинен відстежуватися, тому він ігнорується, що зазначено у файлі .gitignore.

Ніколи не зберігайте в цих файлах таємні чи чутливі значення. Ми побачимо, як керувати конфіденційними даними на іншому кроці.

Ведення журналу всіх дій

З коробки, у нових проектах, можливості ведення журналу і налагодження досить обмежені. Додаймо більше інструментів, які допоможуть нам досліджувати проблеми в розробці, а також у продакшн:

1
$ symfony composer req logger

Що стосується інструментів налагодження, встановімо їх виключно у середовищі для розробки:

1
$ symfony composer req debug --dev

Дослідження інструментів налагодження Symfony

Якщо ви оновите головну сторінку, то побачите панель інструментів, у нижній частині екрана:

Перше, що ви можете помітити, це 404 червоного кольору. Пам’ятайте, що ця сторінка є «заглушкою», оскільки ми ще не визначили головну сторінку. Навіть якщо сторінка за замовчуванням, яка вітає вас, прекрасна, це все-таки сторінка помилки. Отже, правильний код статусу HTTP — 404, а не 200. Завдяки панелі інструментів веб-налагодження ви одразу отримуєте цю інформацію.

Якщо ви натиснете на маленький знак оклику, то побачите «справжнє» повідомлення про виняток, як частину запису у журналі профілювальника Symfony. Якщо ви хочете побачити трасування стеку, натисніть на посилання «Exception» у меню зліва.

Щоразу, коли виникає проблема з вашим кодом, ви побачите сторінку винятку, як показано нижче, яка дає вам все необхідне, щоб зрозуміти проблему і те, звідки вона походить:

Знайдіть трохи часу, щоб ознайомитися з інформацією, що надає профайлер Symfony, натискаючи по різних посиланнях.

Журнали також дуже корисні в сеансах налагодження. Symfony має зручну команду для відстеження останніх записів всіх журналів (з веб-сервера, PHP і вашого застосунку):

1
$ symfony server:log

Проведімо маленький експеримент. Відкрийте public/index.php і зламайте там PHP-код (додайте foobar в середину коду, наприклад). Оновіть сторінку в браузері та спостерігайте за потоком журналу:

1
2
Dec 21 10:04:59 |DEBUG| PHP    PHP Parse error:  syntax error, unexpected 'use' (T_USE) in public/index.php on line 5 path="/usr/bin/php7.42" php="7.42.0"
Dec 21 10:04:59 |ERROR| SERVER GET  (500) / ip="127.0.0.1"

Вихідні дані мають яскраве забарвлення, щоб привернути вашу увагу до помилок.

Ще один чудовий помічник у налагодженні — функція Symfony dump(). Вона завжди доступна і дозволяє виводити складні змінні у зручному й інтерактивному форматі.

Тимчасово змініть public/index.php, щоб вивести об’єкт Request:

patch_file
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
--- a/public/index.php
+++ b/public/index.php
@@ -18,5 +18,8 @@ if ($_SERVER['APP_DEBUG']) {
 $kernel = new Kernel($_SERVER['APP_ENV'], (bool) $_SERVER['APP_DEBUG']);
 $request = Request::createFromGlobals();
 $response = $kernel->handle($request);
+
+dump($request);
+
 $response->send();
 $kernel->terminate($request, $response);

При оновленні сторінки зверніть увагу на новий значок «ціль» на панелі інструментів; він дозволяє переглядати виведення. Натисніть на нього, щоб перейти до повної сторінки, де навігація спрощується:

Скасуйте все, що змінили на цьому кроці, перед фіксацією решти змін:

1
$ git checkout public/index.php

Налаштування IDE

У середовищі розробки, при виникненні винятку, Symfony відображає сторінку з повідомленням про виняток та трасування його стеку. При відображенні шляху до файлу, він додає посилання, яке відкриває файл на потрібному рядку у вашому улюбленому IDE. Щоб скористатися цією функцією, необхідно налаштувати IDE. Symfony підтримує безліч IDE з коробки; я використовую Visual Studio Code для цього проекту:

patch_file
1
2
3
4
5
6
7
--- a/php.ini
+++ b/php.ini
@@ -6,3 +6,4 @@ max_execution_time=30
 session.use_strict_mode=On
 realpath_cache_ttl=3600
 zend.detect_unicode=Off
+xdebug.file_link_format=vscode://file/%f:%l

Зв’язування файлів не обмежуються лише винятками. Наприклад, контролер на панелі інструментів веб-налагодження, також, стає доступним для натискання після налаштування IDE.

Налагодження у продакшн

Налагодження продакшн-серверів завжди складніше. Наприклад, у вас немає доступу до профілювальника Symfony. Журнали менш детальні. Але перегляд останніх записів, все ж, можливий:

1
$ symfony logs

Ви навіть можете підключитися до веб-контейнеру через SSH:

1
$ symfony ssh

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


  • « Previous Крок 4: Вибір методології
  • Next » Крок 6: Створення контролера

This work, including the code samples, is licensed under a Creative Commons BY-NC-SA 4.0 license.