🐘 PHP: Подружись с Composer раз и навсегда

Привет! На связи Бурый.

Вижу часто в чатах и проектах: люди до сих пор таскают библиотеки руками, копируют файлы или пишут велосипеды там, где всё уже придумано до нас.

✋ Эту боль надо прекращать.

Если в вашем проекте нет файла composer.json - вы делаете что-то не так.

❓ Почему Composer - это мастхэв:

- Быстро: Одна команда composer require vendor/package — и библиотека у вас в проекте.
- Удобно: Обновление одной командой composer update. Автозагрузка классов работает из коробки.
- Контроль версий: Вы всегда знаете, какая версия библиотеки стоит, и можете откатиться при необходимости.

⚠️ Но есть нюанс (кровавый опыт):

Никогда не пускайте обновление пакетов на самотек. Видел проекты, где в composer.json написано "monolog/monolog": "^2.0", а через полгода ребята удивляются: "Почему всё сломалось?".

👍 Фиксируйте версии!

Вот как должен выглядеть адекватный composer.json:

{
    "require": {
        "monolog/monolog": "2.9.3",
        "guzzlehttp/guzzle": "7.8.2"
    }
}

+ Библиотеки обновляются, мажорные версии ломают обратную совместимость.
+ Вчера пакет работал, а после composer update — посыпались ошибки.
+ Проект должен собираться одинаково сегодня, через месяц и через год.

🎯 Мой подход:

+ Ставлю пакет с конкретной версией: composer require monolog/monolog:2.9.3
+ Обновляю осознанно: читаю changelog, смотрю на критические изменения.

Composer - это стандарт индустрии. Дружите с ним, контролируйте версии, и код станет чище, а жизнь проще.
—

👇 А вы фиксируете версии или доверяете "^"? Делитесь болью в комментариях!

👉 Подписывайтесь на Бурый.dev - дальше будет еще больше живых советов из практики!

Бурый.dev | TG
Бурый.dev | MAX

🐘 Логируй то, что надо!

Привет! На связи Бурый.

Заходил когда-нибудь в логи и тонул? Листаешь мегабайты текста, а в итоге — ничего не понял. Знакомо?

Логов много не бывает. Бывает много бесполезных логов.

Если ты логируешь всё подряд - ты не логируешь ничего. В критический момент ты просто утонешь в простыне текста, пока прод горит.

❓ Что реально нужно логировать?

Одна запись на один клиентский запрос. Одна запись на выполнение cli скрипта. Которая отвечает на главный вопрос:
Как прошел процесс? Успех или ошибка?

🎯 Мой подход:

+ На каждый запрос/скрипт - одна итоговая запись.
+ Если ошибка - пишу reason так, чтобы сразу было понятно, куда смотреть.
+ Для отладки включаю подробные логи локально, на проде - только суть.

👍 Вот мой идеальный лог:

{
  "datetime": "2025-03-19 10:23:15.123"
  "status": "error",
  "reason": "Database connection timeout",
  "script": "cron/parse-orders.php",
} 

 {
  "datetime": "2025-03-19 10:24:11.123"
  "status": "success",
  "reason": "",
  "script": "cron/parse-orders.php",
  "final_time": 0.123,
  "rows": 1002,
}  

Почему это работает:
✅ status - сразу видно, всё ок или нет. Можно мониторить только по “error”
✅ reason - ёмко объясняет, что пошло не так. Не нужно парсить stack trace, чтобы понять, что упала база.
✅ контекст - можно дополнить параметрами вызова, pid процесса и др, все то что поможет идентифицировать запрос или итерацию вызова скрипта.

Что не надо логировать:
❌ Каждую итерацию цикла
❌ "Начал делать то-то" - если без этого можно понять результат
❌ Дампы огромных массивов
❌ Стек-трейсы на каждое предупреждение

Помни: логи ты пишешь не для процесса, а для ответа на вопрос "Что случилось?" в 3 часа ночи, когда прод лёг.
—

👇 А у вас в проекте можно по логам быстро понять проблему?

👉 Подписывайтесь на Бурый.dev - дальше будет еще больше живых советов из практики!

Бурый.dev | TG | MAX | VK

⬆️ Бурый.dev - новый адрес канала

Привет! На связи Бурый.

Канал сменил название. Теперь: Бурый.dev

Почему .dev?

PHP остается моим главным инструментом, но бэкенд-разработка - это гораздо шире: базы данных, очереди, архитектура, Docker, интеграции.
Хочу делиться опытом по всем этим направлениям.

Спасибо, что остаетесь со мной!
Дальше - больше 🔥

Бурый.dev | TG | MAX | VK

🛠 Инструменты: Логируй так, чтобы не переписывать

Привет! На связи Бурый.

В одном из прошлых сообщений я рассказал, какого подхода придерживаюсь при логировании. А сегодня расскажу о том, как это лучше делать в коде.

📌 Начну сразу с анонса: в следующем посте покажу свою реализацию CombineLogger, которая упрощает мне жизнь. А сегодня - база, без которой эта реализация не имела бы смысла.

В проектах часто используют логи. Monolog, нативный логгер из фреймворка или свои велосипеды... вариантов много. Проблема возникает, когда нужно заменить одну библиотеку на другую. Если код завязан на конкретную реализацию - правки будут по всему проекту.

🔥 PSR-3 решает эту проблему раз и навсегда.

PSR-3 - это единый интерфейс для логирования. Любая библиотека, которая его реализует, становится взаимозаменяемой.

Вот как он выглядит:

interface LoggerInterface
{
    public function emergency(string $message, array $context = []);
    public function alert(string $message, array $context = []);
    public function critical(string $message, array $context = []);
    public function error(string $message, array $context = []);
    public function warning(string $message, array $context = []);
    public function notice(string $message, array $context = []);
    public function info(string $message, array $context = []);
    public function debug(string $message, array $context = []);
    public function log($level, string $message, array $context = []);
}

👍 Что даёт PSR-3:

➕Гибкость: сменил библиотеку - не меняешь код
➕Единый подход: любой разработчик понимает, как логировать
➕Структурированные логи: передавай контекст, а не склеивай строки

🎯 Мой подход:

✅ Всегда принимаю в конструктор Psr\Log\LoggerInterface.
✅ Никакой привязки к Monolog или другой библиотеке - только интерфейс!
✅ Контекст - это сила: передаю структурированные данные, а не склеиваю строки.

Пример, как не надо:

$this->logger->error('Ошибка оплаты для заказа 12345, пользователь 678, сумма 100.5');

Пример, как надо:

$this->logger->error('Ошибка оплаты', [
    'order_id' => 12345,
    'user_id' => 678,
    'amount' => 100.50
]);

Второй вариант позволяет фильтровать логи по полям в Elasticsearch, не требует парсинга строк и легко читается и расширяется.

Стандарты - это не про бюрократию. Это про то, чтобы код не приходилось переписывать.

PSR-3 занимает 5 минут на внедрение, но экономит часы при смене инструментов и дебаггинге.

👇А вы используете PSR-3 в проектах? Или пишете свои врапперы? Делитесь в комментариях!

🔥Подписывайтесь на Бурый.dev - дальше будет еще больше живых советов из практики!

Бурый.dev | TG | MAX | VK

🐘 Архитектура: Как не утонуть в легаси

Привет! На связи Бурый.

В работе часто сталкиваюсь с разным кодом. В основном - с легаси. Проектам по 5 - 10 лет, код живёт своей жизнью, структура разная, договорённости терялись вместе с уволившимися разработчиками.

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

Нельзя просто взять и переписать всё. У нас есть задачи, дедлайны, работающий прод. Рефакторинг ради рефакторинга - недопустимо, бизнес не поймёт.

🎯 Мой подход: делаем только базу.

Создаю минимальный каркас, который не ломает существующую логику, но задаёт направление.

Базовые папки:

src/
├── Application/
├── Domain/
└── Infrastructure/

- Application: Сценарии, которые связывают домен и инфраструктуру.
- Domain: Сущности, которые отражают реальный бизнес.
- Infrastructure: БД, HTTP-клиенты, кэш, логи - всё, что можно заменить, не трогая бизнес-логику.

⚡️ Мои рекомендации:

📌 Выделяй сущности постепенно. Не пытайся охватить всё сразу. Начни с одной - той, которая чаще всего меняется и конечно, с той, которая затрагивается в решаемой задаче.

📌 Создай базовые папки. Даже если они пустые - это сигнал. Новый код будет ложиться туда, а не в легаси.

📌 Соблюдай баланс. Если задача на три дня, а рефакторинг займёт неделю - сделай минимум. Но этот минимум должен быть шагом в правильную сторону.

Чистый код - это не цель. Это инструмент, чтобы жить было легче.

Не надо идеально. Надо - лучше, чем было. Задать направление, чтобы каждая следующая бизнес задача встраивалась в новую структуру.

—

❓ А у вас в проектах есть единая структура? Или каждый пишет как хочет? Делитесь в комментариях!

🔥 Подписывайтесь! Дальше будет еще больше живых советов из практики!

dev161.ru

Привет! На связи Бурый.

В прошлом посте о логах я рассказывал про PSR-3 и обещал показать свою реализацию CombineLogger. Выполняю обещание 🔥

Откуда взялся CombineLogger?

В проектах, над которыми я работаю, везде используется Psr\Log\LoggerInterface. Это стандарт, который позволяет не привязываться к конкретной библиотеке.

Но возникла проблема: интерфейс один, а логгеров нужно несколько.

Хочется писать в файл и отправлять в output или в GrayLog. А код везде принимает только один LoggerInterface.

Решение с кодом и примерами:

➡️ https://dev161.ru/php-multi-logger-6

—

❓ А как ты логируешь в своих проектах? Используешь несколько каналов или всё в одну кучу?

🔥 И не забудь подписаться :)

Привет! На связи Бурый.

Теперь все полноценные статьи я публикую на своём сайте
➡️ https://dev161.ru

Мессенджеры и соцсети стали нестабильными - блокировки, ограничения, доступ затруднён

Сайт - это моя территория, где контент всегда доступен и ничего не пропадёт.

🤝 Что остаётся прежним:

- Анонсы и ссылки - всегда здесь
- Обсуждение по-прежнему в комментариях
- Обратная связь и вопросы приветствуются

—

🔥 И подписывайся, чтобы ничего не пропустить

Всё, побежал кодить :)

Привет! На связи Бурый.

Коллекции - это круто. Но у коллекций по умолчанию есть один минус - их нельзя перебирать в цикле. Почему я всё равно выбираю коллекции?

Сейчас расскажу:

➡️ https://dev161.ru/php-iterator-aggregate-7

❓ А ты используешь коллекции в проектах?

🔥 И подписывайся, чтобы ничего не пропустить
~

Привет! На связи Бурый.

Сегодня предлагаю поразмышлять: код должен становиться лучше? И если да - то когда?

➡ https://dev161.ru/nice-refactoring-8

❓ А ты как решаешь? Рефакторить код или оставить простым?

🔥 И подписывайся, чтобы ничего не пропустить
~

🔥Друзья, Telegram стал нестабильным.

Все новые статьи, советы по разработке и анонсы дублирую в Max. Там информация всегда доступна.

Подписывайся → https://max.ru/id616507661604_biz

Привет! На связи Бурый.

⚡Cитуация: клиент отправил запрос к вашему api, ждёт ответ, а тебе нужно сделать что-то тяжёлое. Отправить письмо, обработать видео, записать логи в базу.

Клиент не должен ждать!

➡ https://dev161.ru/php-finish-request-9

❓ А ты используешь эту функцию? Или предпочитаешь очереди?

🔥 И подписывайся, чтобы ничего не пропустить.
~

Привет! На связи Бурый.

Сегодня рассказываю, как можно обойтись без очередей для долгих задач - обработка видео, сложный парсинг и фоновые процессы.

Сканирование + атомарный захват: альтернатива очередям.

➡ Читать статью: https://dev161.ru/scan-and-atomic-without-queue-11

❓ Сталкивался с задачами, где очереди избыточны? Как решал?

🔥 И подписывайся, чтобы ничего не пропустить.

Бурый.dev

Привет, на связи Бурый!

Коллеги из @avitotech делились плейлистом с небольшими роликами про паттерны и практики написания кода.

Формат удобный: коротко, наглядно.

Кому проще смотреть, чем читать - рекомендую.

Плейлист существует уже год, но он всё ещё актуален.

🎬 Ссылка на плейлист:
https://vkvideo.ru/video/playlist/-152990965_33

—

❓ Смотрите такие видео или по старинке читаете статьи?

🔥 И подписывайся, чтобы ничего не пропустить.

Привет, на связи Бурый!

Давно не писал - так вышло. Работа, задачи. Но я вернулся :)

За это время накопилось мыслей, и первая статья готова.

Репозитории - ещё один шаг к чистому коду.

↖️ https://dev161.ru/repository-pattern-clean-code-12

—

🔥 Подписывайся, чтобы ничего не пропустить.

Привет, на связи Бурый!

Фоновые процессы под контролем - Supervisor в Docker.

Как использую я, пишу тут 👇

↖ https://dev161.ru/process-orchestration-supervisor-13
—

🔥 Подписывайся, чтобы ничего не пропустить.