В основу этого окружения легли мои любимые и часто используемые инструменты:

• Docker для контейнеризации
• Docker compose для управления контейнерами
• PHP последней версии
• Composer для управления зависимостями PHP
• xDebug для отладки приложения
• RoadRunner для запуска приложения в режиме Long-Running
• PHP-фреймворк Yii3
• БД PostgreSQL, т.к. она умеет в keep-alive коннекты, в отличие от некоторых.

К сожалению, я так и не оформил привычное мне окружение для разработки в шаблон, который можно было бы использовать в команде composer create project. Но это и не очень удобно, т.к. от проекта к проекту шаблон изменяется, эволюционирует. В каждый следующий проект я беру версию из предыдущего. Однако, основные принципы уже давно не меняются, и сегодня я покажу вам в первую очередь их.

Dockerfile и сохранение стейта

Во-первых, в корне каждого проекта у меня есть папка .docker, куда я скидываю все специфичные для него вещи:

• Dockerfile для образов контейнеров PHP и других
• Конфиги, которые зашиваются внутрь образов контейнеров или подключаются томами. Например, основной php.ini добавляется внутрь образа, а включение xDebug подключается томом только в среде локальной разработки
• Стейт контейнеров. Я всегда сохраняю на диск стейт БД (в проде иначе и не получится), а в dev-окружении - ещё и кеш композера, чтобы его команды выполнялись быстрее. Вот пример структуры из последнего моего проекта, которую я коммичу в репозиторий:

.docker
├──data
│  ├──composer
│     └──.gitignore
│  └──postgres
│     └──.gitignore
└──php
   ├──Dockerfile
   ├──php.ini
   └──xdebug.ini

• Папка data - для сохранения стейта из контейнеров между их перезапусками. Внутри каждой подпапки лежит файл .gitignore с двумя строками: * для игнора всего в этой папке и !.gitignore для того, чтобы сам этот файл закоммитить.

  *
  !.gitignore
• Папка php содержит Dockerfile и конфиги для контейнера с PHP
• Если мне понадобится билдить еще какие-то контейнеры - я создам еще одну папку рядом, и в нее тоже положу Dockerfile и все необходимые конфиги.

А вот - стартовый вариант моего Dockerfile:

FROM php:8.3-cli-bullseye

RUN apt update \
    && apt install -y  \
        libicu-dev \
        linux-headers-generic \
        zip \
        libpq-dev \
    && apt install -y $PHPIZE_DEPS \
    && docker-php-ext-configure intl \
    && docker-php-ext-install -j$(nproc) \
        pdo \
        pdo_pgsql \
        pgsql \
        pcntl \
        sockets \
        intl \
        opcache \
    && pecl install xdebug \
    && docker-php-ext-enable intl \
    && pecl clear-cache \
    && apt purge -y $PHPIZE_DEPS \
    && apt clean

COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

ADD .docker/php/php.ini /usr/local/etc/php/conf.d/40-custom.ini

WORKDIR /var/www

ARG USER_ID=1000
ARG GROUP_ID=1000

RUN groupadd -g $GROUP_ID appuser && \
    useradd -m -N -g $GROUP_ID -u $USER_ID appuser && \
    usermod -L appuser && \
    chown appuser:appuser .

USER appuser

COPY --chown=appuser:appuser ./composer.* configuration.php ./

RUN composer install \
        --prefer-dist \
        --no-ansi \
        --no-dev \
        --no-interaction \
        --no-plugins \
        --no-progress \
        --no-scripts \
    && vendor/bin/rr get --no-config -q -n

COPY --chown=appuser:appuser ./ ./
RUN composer du --classmap-authoritative

CMD ["./rr", "serve"]

В нем происходит следующее:

1. Ставим все необходимые системные пакеты с помощью apt, docker-php-ext и pecl, включаем расширения PHP.
   1. Заметьте: xDebug я устанавливаю, но не включаю. Включу и настрою я его отдельным файлом настроек чуть ниже. Поступаю я так для того, чтобы на проде он не работал ни при каких условиях, включая невнимательность.
2. Устанавливаем composer
3. Добавляем конфиг PHP для прода
4. Создаём пользователя, под которым будет работать приложение. Это важно, т.к. внутри контейнера будут создаваться и изменяться файлы (пакеты композера, логи, результаты изменения от phpcsfixer и пр.), и нам нужно, чтобы пользователь с хост-системы (мы сами) мог читать и редактировать эти файлы. Значения id пользователя и группы мы принимаем в виде аргументов, чтобы была возможность установить их разными для разных систем.
5. Отдельно добавляем в контейнер файлы composer.json, composer.lock и configuration.php (конфиг для yiisoft/config), да ставим зависимости с помощью composer install. И сразу скачиваем бинарник RoadRunner. Делаем этот шаг до копирования файлов проекта, т.к. докер закеширует результат и не будет повторять эти действия, пока два исходных файла не поменяются, т.е. пока список зависимостей и их версий остается неизменным.
6. Добавляем все файлы проекта
7. Делаем composer du --classmap-authoritative. Этот шаг преследует сразу две цели:
   1. Очевидная: после добавления файлов проекта мы оптимизируем скорость работы автолоудера.
   2. Неочевидная: по хуку команды dump-autoload генерируется карта мержей для yiisoft/config. Если есть вопросы по его содержимому - всегда рад ответить на них в своем телеграм-канале.

Конфиг docker compose

Во-вторых, в репозитории с проектом всегда есть файл docker-compose.yml. Да, мне пора его переименовать в compose.yaml под новый стандарт, но я все забываю 😅 Вот его примерное must have содержимое:

version: "3.8"  
  
services:  
  php:  
    depends_on:  
      db:  
        condition: service_healthy
    build:  
      dockerfile: .docker/php/Dockerfile  
      context: ./  
      args:  
        USER_ID: ${USER_ID:-1000}  
        GROUP_ID: ${GROUP_ID:-1000}  
    command: "./rr serve -c .rr.dev.yaml"  
    user: "${USER_ID:-1000}:${GROUP_ID:-1000}"  
    restart: unless-stopped
    ports:
      - ${WEB_PORT:-80}:80
    volumes:
      - ./.docker/php/php.ini:/usr/local/etc/php/conf.d/40-custom.ini:ro
      - ./.docker/php/xdebug.ini:/usr/local/etc/php/conf.d/99-xdebug.ini:ro
      - ./.docker/data/composer:/home/appuser/.composer
      - ./:/var/www
    environment:
      TZ: Asia/Almaty
      PHP_IDE_CONFIG: ${PHP_IDE_CONFIG:-}
      DB_NAME: ${DB_NAME}
      DB_HOST: ${DB_HOST}
      DB_PORT: ${DB_PORT}
      DB_LOGIN: ${DB_LOGIN}
      DB_PASSWORD: ${DB_PASSWORD}
      XDEBUG_MODE: ${XDEBUG_MODE:-off}
      XDEBUG_CONFIG: "client_host=host.docker.internal"
      XDEBUG_TRIGGER: "yes"
  
  db:
    image: postgres:15-alpine
    restart: unless-stopped
    volumes:
      - .docker/data/postgres/db:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD:-dev}
      POSTGRES_USER: ${DB_USER:-dev}
      POSTGRES_DB: ${DB_NAME:-dev}
    ports:
      - "${DB_PORT:-5432}:5432"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${DB_USER:-dev}"]
      interval: 3s
      timeout: 3s
      retries: 10

Из этого примера видно, что я активно пользуюсь переменными окружения. Их значения задаются в файле .env, который добавлен в .gitignore. В репозиторий вместо него я коммичу .env.example, который содержит все возможные переменные окружения с пустыми или фейковыми значениями. Благодаря такому подходу приложение зависит от переменных окружения, а не от способов их добавления. Ну а вот - пример моего .env.example:

##################################
# Port forwarding
##################################
WEB_PORT=80

##################################
# xDebug settings
##################################
# Uncomment next line for xDebug usage with PhpStorm
# PHP_IDE_CONFIG=serverName=docker
# XDEBUG_MODE=develop,debug

# LINUX ZONE. Next configs are for xDebug in linux environment only.
# COMPOSE_FILE=docker-compose.yml:docker-compose.linux.yml
# Uncomment HOST_IP and set host ip in the docker network when using linux, look at docker-compose.linux.yml
# Although it usually is 172.17.0.1, your real value can be easily found with command `ip address | grep docker`,
# you'll see it like "inet 172.17.0.1/16 ..."
# HOST_IP=172.17.0.1

##################################
# Database settings
##################################
DB_HOST=db
DB_PORT=5432
DB_NAME=dev
DB_LOGIN=dev
DB_PASSWORD=dev

Если вы не знаете, зачем нужны те или иные настройки xDebug - рекомендую прочесть мой пример настройки xDebug в докере.

Особенности разработки под Linux

Если вы ведете разработку на Linux и не используете Docker Desktop (а я именно так и делаю), то внутри контейнеров вам недоступен хост host.docker.internal. И чтобы была возможность пользоваться xDebug (ему ведь надо самостоятельно коннектиться к IDE из контейнера) всегда добавляю в docker-compose.yml в сервис с PHP этот блок:

extra_hosts:
  - host.docker.internal:${HOST_IP:-172.17.0.1}

А когда я планирую работать над проектом не один, то вытаскиваю этот блок в соседний файл, который обычно называю docker-compose.linux.yml, в основном же файле остаётся все остальное. И чтобы каждый раз не писать в каждой команде список подключаемых конфигов (например, docker compose -f docker-compose.yml -f docker-compose.linux.yml run --rm php php -v), в .env я также добавляю такую переменную окружения:

COMPOSE_FILE=docker-compose.yml:docker-compose.linux.yml

Запуск

В первую очередь, конечно, добавляем composer.json и прочие файлы проекта. А непосредственно запуск такого окружения прост до банальности:

docker compose up -d

При первом запуске контейнер сначала сбилдится. Это может занять больше 5 минут в зависимости от мощности машины и качества канала в интернет. А когда он окончательно запустится - все готово к работе и отладке.

docker composer run --rm --no-deps php composer require foo/bar

Заключение

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

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

Использование Docker, тщательно продуманная структура .docker директории, гибкие настройки через переменные окружения - все это позволяет достичь этого баланса. Мы получаем стабильное окружение, которое при этом легко кастомизировать.

Особое внимание я уделил оптимизации производительности (кеширование данных, грамотное построение слоев в Dockerfile, оптимизация автолоудера) и удобству. Эти аспекты часто упускаются из виду, особенно на ранних этапах проекта, но они критически важны для долгосрочного успеха.

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

Сегодня я прошелся по верхам, не углубляясь. Здесь затронуто очень много тем, копать вглубь которых можно очень долго. Пишите мне о том, что из этого вам интересно, ставьте лайки в соцсетях, и на такие темы я опубликую больше контента. А связаться со мной можно в телеграм-канале. Давайте вместе делать процесс разработки более эффективным и приятным!

Итак, первый пациент. Внутри трейта используются поля его наследников. То есть, что-то такое:

trait Foo
{
    public function bar(): string
    {
        return $this->field . self::CONSTANT . $this->method() . true;
    }
}

Что плохого?

Проблема кроется в том, что технически класс, использующий этот трейт, не обязан объявлять ни поле, ни константу, ни метод. Их там может не быть. При этом можно даже статический анализатор обмануть, если добавить трейту такой комментарий:

/**
 * @mixin SomeClass
 */

Разумеется, только в том случае, если в SomeClass есть и $field, и CONSTANT, и method().

Проблема возникнет, когда этот трейт добавят еще к одному классу, а разработчик не будет знать или забудет объявить эти три вещи.

Как правильно?

Использовать абстрактные методы:

trait Foo
{
    public function bar(): string
    {
        return $this->getField() . $this->getConstant() . $this->method();
    }

    abstract protected function getField(): string;
    abstract protected function getConstant(): string;
    abstract protected function method(): string;
}

Таким образом у нас появляется техническое ограничение на уровне языка: любой класс, подключающий в себя этот трейт, будет обязан объявить также три метода, от которых зависит основной функционал трейта.

Правильный вариант 2

Для адептов идей "Трейты - зло" и "Композиция - сила":

interface BarInterface
{
    public function getField(): string;
    public function getConstant(): string;
    public function method(): string;
}

readonly final class Foo
{
    public function bar(BarInterface $bar): string
    {
        return $bar->getField() . $bar->getConstant() . $bar->method();
    }
}

Здесь мы заменяем трейт на две вещи:

• Интерфейс с теми же тремя методами, что в трейте были abstract и protected
• Класс, в который мы реализацию этого интерфейса передаем, чтобы вызвать эти методы и использовать результаты их выполнения.

• те, из-за которых бизнес теряет много денег
• и те, которые встречаются реже всего.

Почему первые - понятно сразу, а что со вторыми? Дело в том, что чем реже мы встречаем какой-то тип ошибок - тем сложнее понять, чем они вызваны.
Так случилось и у меня на работе. Однажды утром тестировщики заметили, что часть запросов бэкенду возвращала ошибку 502 (Gateway Timeout). Эта ошибка тормозила релиз, и за неё взялись все старшие разработчики и devops-инженер. Поначалу считали, что эту ошибку возвращает Nginx, и бэкенд не при чём. Через некоторое время поняли, что виноват всё-таки PHP. На что только не грешили: отключали BlackFire, меняли настройки OpCache, пробовали разные патч-версии в PHP, и так далее. Однако, сама ошибка оказалась не в инфраструктуре, а непосредственно в коде приложения.

Предисловие

В качестве вводных данных расскажу, что приложение основано на фреймворке yii2 и изначально писалось не самыми толковыми разработчиками. Например, DI-контейнер не использовался, вместо него были компоненты, как это и было задумано изначально в фреймворке на заре его существования. Когда проект выстрелил, в него пришли специалисты выше уровнем, и к старому коду начали писать более выверенный архитектурно. Из-за одного такого изменения у нас и получилось ошибка, которая на фронтенде выглядела как 502, и по которой ни в каких логах не было записей. Первое, что пришло в голову: такая ситуация с логами возникает из-за переполнения памяти. То есть, когда php-процесс использует больше памяти, чем ему выделено системой. С этой ситуацией мы знакомы и умеем её распознать, почему и проверили её сразу же. Но это была не она.

Описание проблемы

Оказалась, что наша проблема была схожего характера: процесс отваливался из-за достижений другого системного ограничения, не памяти. В весьма неочевидном месте мы достигали лимита по максимальной вложенности вызовов функций. Другими словами, мы вошли в рекурсию. Причём рекурсия эта была неявной, то есть функция вызывала не сама себя, а другую функцию, которая в свою очередь вызывала первую функцию, а та снова вторую, а та снова первую…

Пришли мы к этому следующим образом. В конфигурации у нас был компонент (назовём его для ясности foo). Конфигурация этого компонента выглядела вот так:

'foo' => [
    'class' => FooClass::class,
    'property1' => 'value1',
]

Один из наших разработчиков добавил определение этого класса в DI-контейнер, чтобы была возможность получать этот класс уже настроенным в конструтор других классов:

FooClass::class => static fn() => Yii::$app->get('foo'),

Что мы имеем в результате? Когда код проекта обращался к компоненту, фреймворк пытался создать этот компонент. Видя в определении компонента необходимость получить объект класса, он искал этот класс сначала в контейнере, где находил определение Yii::$app->get('foo'), и снова пытался получить компонент. И так - по кругу. В качестве хотфикса мы удалили определение для DI-контейнера (оно нигде не использовалось). Правильным же решением было перенести настройку класса из описания компонента в определения DI-контейнера, в настройках компонентов оставив только 'foo' => FooClass::class.

Вот так простейшая ошибка сумела обмануть разработчиков с опытом более 10 лет. Просто мы слишком редко ее встречаем.

Неожиданно долгие поиски

Мои зарплатные ожидания остались на том же уровне, но после публикации резюме на HeadHunter мне не написала ни одна компания. Ни одного отклика. Я, скажем цензурно, удивился, и стал писать отклики сам. Заодно опубликовал свое резюме на других job-бордах. Не все компании, кому я писал, отправили хоть какой-то ответ, часть из них отказала молча. С какими-то я некоторое время ещё вел диалог. Прошел несколько собеседований по всем этапам, но мне везде отказали. Я начинал потихоньку паниковать: мои запасы денег истощились еще в момент переезда в Казахстан, позже я добавил себе еще 1 кредит. А клиентов, тем более - постоянных, на фрилансе быстро не найти.

Лишь в одной компании сделали своеобразный подарок на новый год в виде оффера 😃 К ним я и вышел после новогодних праздников в РФ.

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

Ну а до тех пор, пока не вышел к новому работодателю, я решил сосредоточиться на проектной работе, фрилансе и консультациях других компаний. Всё же, опыта у меня довольно много: я не только писал код, но также участвовал в формировании и изменении процессов it-отделов компаний, в которых работал. Много наблюдал за тем, насколько хорошо или плохо работают те или иные процессы в более продвинутых it-компаниях.

Post Scriptum и внезапная развязка

Когда я уже нашел работу, hh наконец показал мне уведомление о том, что мое резюме видят только компании в Казахстане: ведь я в нем честно указал Алматы. Зарплату при этом я указал в рублях. При курсе рубля, выросшем в 1.5 раза с весны 2022 года, такая з/п в пересчете на тенге была неадекватно высокой, и казахстанские компании я заинтересовать не мог. А российские просто не видели мое резюме. Как на ваш взгляд, проблема у меня была только в этом, и с наймом в IT и PHP все в порядке, или таки сдулся наш пузырь? Да и пузырь ли это вообще? Давайте обсудим.

На текущий момент это произошло лишь однажды. Обычно я работал на взрослых проектах, где либо подобные задачи уже были решены, либо это было страшное легаси без ресурсов на рефакторинг. Итак, где же мне понадобился Строитель?

Задача: оптимизировать товарные фиды

Проект был интернет-магазином и маркетплейсом сразу. С него выгружался добрый десяток товарных фидов. Это были файлы различных форматов со списком товаров, их категорий и характеристик. А выгружались они на другие маркетплейсы или, что чаще, на различные платформы, предоставляющие услуги рекламы и аналитики. У каждого фида были собственные настройки: какие товары/бренды/категории должны в него входить, какие данные должны быть доступны по товарам и т.п. Они хранились в БД и выставлялись в UI нашими маркетологами.

Генерация каждого фида происходила независимо от остальных. Изначально она занимала до 10 минут на каждый фид и сильно нагружала систему, т.к. очень активно читались данные из БД. И если к определенному времени надо было сгенерировать все фиды, то процедура эта растягивалась на полтора часа, в течение которых реплика БД для чтения работала на пределе.

Первая итерация оптимизации

Первым делом я сделал две вещи: Использовал для поиска товаров и получения части данных по ним SphinxSearch. Начальная версия фидов писалась еще до внедрения Сфинкса, внедрить в нее что-то новое было сложно, поэтому руки до него дошли только теперь. Сделал генерацию фидов единым процессом. Данные можно было получить один раз, и по ним - построить необходимые фиды. Фид поделился на две вещи: фильтр, который отбирал только нужные товары, и шаблон, который создавал файл из данных. Мы брали товар и пропускали через все фиды. Если фильтр пропускал его - писали информацию об этом товаре в файл. И так - каждый товар.

Такой подход вывел время создания фидов в константу: около 6 минут вне зависимости от их количества. Однако, можно было и лучше: в некоторых фидах использовалось только 20-25% товаров, но при их отдельном запуске все равно прогонялись через фильтр все товары.

Вторая итерация: Строитель

Второе, что пришло мне в голову - создать собственный QueryBuilder с верхнеуровневыми “запросами”: withBrands(), withCategories(), withPhotoType() и пр. Когда требовалось сгенерировать несколько фидов - по каждому из них брался инстанс QueryBuilder’а, и они сливались в один, чтобы выбрать из БД только те товары, которые необходимы текущему набору фидов. При этом сохранилась независимость сущностей в модуле генерации фидов от структуры БД, а код непосредственно генерации изменился только в одном месте: получение товаров из репозитория изменилось с getProducts(): iterable на getProducts(QueryBuilder …$queries): iterable

Расскажите, как часто случалось вам в вашей практике писать Строители? Расширение QueryBuilder из ActiveRecord не в счет 😉 Жду ваших комментариев в телеграм-чате блога 👍 А в новой статье увидимся через две недели!

Вообще есть несколько популярных подходов:

• Налево пойдешь - хайповый инструмент найдешь
• Направо пойдешь - что-то проверенное и надежное возьмешь
• Прямо пойдешь - любимый инструмент прикрутишь

Они хороши тем, что при их использовании не надо думать. Просто берешь то, что хочется - и дело с концом 😃 Ну а если есть нужда или желание подойти к вопросу более серьезно - прошу под кат, будем разбираться.

Итак, если не “по-быстрому”, то как же выбирать?

1. Составить список требований

Самый первый и самый очевидный шаг. Но не все так просто, как хотелось бы. Он должен быть актуален на прямо сейчас и обозримое будущее. То есть, нужно выдержать баланс между двумя направлениями:

• Не заглядывать в далекое будущее с потенциальным ростом компании “ва многа разов” и увеличением RPS с текущих 0.1 до 1000.
• Не оставить за бортом реальных требований, если и не текущих, то из обозримого будущего (скажем, в 1-3 года)

2. Выбрать несколько кандидатов, отвечающих всем требованиям

А как выберете - провести их сравнительный анализ, учитывая составленные ранее требования. И не забыть учесть еще несколько пунктов:

1. Удобство использования.
   Инструмент, которым вы собираетесь регулярно пользоваться, не должен чинить препятствий своему использованию, а еще лучше - делать этот процесс приятным и удобным.
2. Частота обновлений.
   Некоторые старые, надежные инструменты со временем уходят в стагнацию и перестают обновляться. В этом случае даже если сейчас такой инструмент представляется идеальным решением, есть довольно большая вероятность, что его вскоре снова придется менять, так как он либо перестанет соответствовать требованиям безопасности, либо не станет реализовывать новые возможности, которые появятся у него быстро развивающихся конкурентов. С другой стороны - молодые проекты. Они могут загнуться из-за маленького комьюнити и недостатка мейнтейнеров.
3. Наличие комьюнити, интеграций, плагинов.
   Отсутствие у нового крутого инструмента большого комьюнити и большого количества интеграций, которые есть у более проверенных его собратьев, может стать очень серьезным препятствием в развитии вашей компании. Отсутствие возможности быстро встроить инструмент в ваши текущие процессы - это ощутимая проблема. С более старыми инструментами, медленнее работающим, менее удобными, вы нередко можете сэкономить десятки, а то и сотни часов работы просто потому, что ваши проблемы уже кем-то решены. А каким бы классным инструмент ни был, на заре своего развития у него всегда есть одно препятствие: пользователям необходимо решать свои проблемы самостоятельно.
4. Наличие экспертизы в команде.
   Даже если незнакомый инструмент не выглядит сложным, а гайды по установке и настройке умещаются на один экран, это отнюдь не значит, что у вас не возникнет сложностей через месяц. А поскольку экспертизы в работе с этим инструментом у вас нет - неизвестно, сколько времени уйдет на устранение ошибок или оптимизацию его работы.

В общем случае при анализе стоит учитывать только основной, общий для всех систем функционал. Я говорю о том, что все без исключения инструменты инфраструктуры рано или поздно устаревают. Сразу думайте о том, как вы будете менять этот инструмент на какой-то другой. Не на какой-то конкретный, а на абстрактный, систему кэширования - на другую систему кэширования. В случае с системами, для которых нет стандартов вроде PSR, для этого придется самостоятельно провести более глубокий анализ, чтобы выявить этот самый общий функционал.

3. Взвесить все за и против выбранных инструментов

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

Пример из жизни

А теперь давайте пройдемся по какому-нибудь реальному инструменту, который мы попробуем выбрать по схеме выше. В компании, где я работаю, недавно столкнулись с необходимостью сменить сервер очередей. До замены использовался Redis, но он перестал нас устраивать. Объем информации, пропускаемой через него, растет, ценность ее высокая, и мы не готовы терять ее в случае сбоя. Отсюда вытекает главный критерий, по которому он нас не устраивает: надежность доставки сообщений. Маршрутизацией сообщений между очередями, сложной логикой их доставки и прочими подобными вещами мы не занимаемся. Рост же трафика, пропускаемого через очереди, увеличивается максимум в два раза за год. Еще один критерий: скорость запуска нового инструмента в продакшен, нам необходимо запустить его в течение месяца. Поэтому какой-нибудь совсем новый инструмент не подходит, т.к. мы не готовы тратить лишнее время на его внедрение.

На этапе выбора инструмента все свелось к классическому противостоянию:

• RabbitMQ. С ним у пары наших разработчиков уже был опыт работы. Также-это довольно популярный сервер очередей, имеющий богатый набор функционала и работающий по стандарту amqp. Он наиболее хорошо документирован и проще в установке и обслуживании, чем другие брокеры, реализующие amqp.
• Apache Kafka - весьма популярен среди компаний энтерпрайз-уровня. Работает по собственному стандарту.
• NATS долго рассматривался как один из вариантов, т.к. не сразу выяснилось, что он не персистит сообщения, а значит - теряет их после выключения. А еще против него говорило то, что он принимает сообщения только по UDP, что добавляет рисков к их потере.

Итак, оценим двух оставшихся конкурентов по их возможностям и недостаткам.

RabbitMQ

• С ним уже работали некоторые люди в нашей команде, так что у него есть преимущество на старте.
• Есть возможность гибкого роутинга сообщений благодаря протоколу amqp. Фишка крутая, но не учитывается в рейтинге, т.к. это нельзя переиспользовать при переходе на другой брокер. Их использование приведет к усложнению перехода к другому инструменту, когда наступит соответствующий момент.
• Способ кластеризации. У RabbitMQ для кластеризации и поддержки высокой доступности используется синхронизация баз данных. Это работает быстро, четко, но не прощает сетевых ошибок. Другими словами, если ноды брокера находятся на разных серверах, в разных дата-центрах, неизбежно будут возникать сетевые проблемы, которые будут приводить к рассинхронизации данных в нодах.

  Shovel

  Также есть альтернатива в виде плагина Shovel, который под капотом использует стандарт amqp и просто пересылает сообщения из очереди одного сервера на обменник (exchange) другого, при этом корректно обрабатывая сетевые ошибки, но добавляя ощутимые накладные расходы, т.к. это не копирование сырых данных, а полноценная обработка сообщения.

• Гарантии доставки сообщений зависят от настроек и поддерживаются только два типа:
  • at least once, сообщение будет доставлено не менее одного раза (иногда может быть и больше)
  • at most once, сообщение будет доставлено не более одного раза (но может и не быть доставлено вовсе)
• Есть возможность включения записи сообщений на диск для того, чтобы они не терялись при перезапуске брокера очередей.
• Пропускная способность у Кролика неплохая, но серьезно падает при включении записи сообщений на диск, до нескольких тысяч сообщений в секунду. У других брокеров пропускная способность на порядки выше (от сотен тысяч до миллионов в секунду), но мы и в эти числа в обозримом будущем укладываемся.

Apache Kafka

• Мы много о нем слышали, но вживую - не видели.
• Реализует только паб/саб, не умеет в маршрутизацию сообщений. Что, опять-таки, не минус, а констатация факта.
• Возможность кластеризации - есть из коробки, без ощутимой потери производительности и ограничений на локальную сеть, что позволяет делать readonly реплики, хранить разные шарды очереди на разных серверах и пр. Минус: требуется еще один инструмент, ZooKeeper.
• Гарантии доставки сообщений также зависят от настроек, но поддерживаются все три возможных типа, включая “exactly once”, т.е. гарантию того, что сообщение будет доставлено получателю ровно один раз, не больше и не меньше. Однако, с этим режимом гарантий доставки возникают сложности при настройке кластеров Кафки. Конечно, соответствующие рецепты уже есть в интернете.
• Запись сообщений на диск не выключается ввиду архитектурных особенностей: очереди в Кафке - это журналы, в которые сообщения добавляются продюсерами, и откуда они читаются консьюмерами. Другими словами, все пришедшие в Кафку сообщения всегда доступны для чтения, в т.ч.давно обработанные.
• Пропускная способность - около 1 миллиона сообщений в секунду.

При сравнении плюсов и минусов этих двух инструментов становится очевидно, что Кафка ощутимо выигрывает. И все же, мы сделали выбор в пользу RabbitMQ. Все дело в самом первом его плюсе: эта система нам уже знакома, и меньше вероятность того, что мы встретимся с проблемами в продакшене. При этом мы не планируем делать географически распределенную систему, т.е. особенности кластеризации Кролика в нашем случае не являются минусом.

У Кафки же его архитектурное отличие приносит значительные сложности. Во-первых, у Кафки нет собственно очереди: у него есть журналы, разбитые на партиции, и из каждой партиции может читать ровно один консьюмер. Мы с такой схемой никогда не работали, и высока вероятность выстрела в ногу при работе с реальными данными в продакшене. Особенно сильно мы чувствуем опаску при мыслях о масштабировании при обработке сообщений. Кролику можно просто добавить консьюмеров. А с Кафкой необходимо заранее продумывать количество партиций и распределение сообщений по ним для сохранения очередности выполнения задач в некоторых случаях.

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

Выводы

Если следовать приведенному выше плану, то можно выбрать любой инструмент из доступных вариантов. Конечно, он оставляет место для риска: если выбрать однозначно самый лучший из доступных, но незнакомый инструмент, можно во время эксплуатации наткнуться на подводные камни. Эти риски тоже стоит закладывать при выборе инструмента. Приведу план подготовки к выбору инфраструктурного инструмента еще раз:

1. Составить список требований, не упуская реальных и не выдумывая чего-то сверх необходимого.
2. Выбрать несколько кандидатов и провести их сравнительный анализ.
3. Оценить выигрышные и проигрышные позиции у разных инструментов, руководствуясь текущими приоритетами.

Расскажите, следовали ли вы подобному плану в своей практике? Какие курьезы случались из-за неучтенных требований или особенностей инструмента? Жду вас в телеграм-чате, буду рад услышать ваши истории и пообщаться!

Интро

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

Табуированность этой темы приводит к почти полному отсутствию материалов о ней в открытом доступе, из-за чего нам приходится самостоятельно выбираться из собственноручно вырытой ямы. И если не удается - следом идет то самое выгорание. Посмотрите, знакомая схема?

1. Я прокрастинирую и не могу эффективно работать
2. Я злюсь на себя за то, что не могу сделать достаточно много, либо обижаюсь на неинтересные задачи/неправильное руководство/устаревание инструментов.
3. Результативность снижается, самобичевание - повышается
4. Полное выгорание

Да, море статей про выгорание рассказывают, как его не допустить. Но при этом почти нигде не говорится о прокрастинации, хотя она приходит задолго до выгорания. А самое забавное - что статьи о выгорании читают те, кто в него уже попался. Как правило, за первые несколько лет работы в профессии у большинства из нас случается парочка выгораний. Конечно, в результате мы получаем богатый опыт, благодаря которому в следующий раз таких кризисов становится избежать проще. Но, тем не менее, редко кому удаётся сделать это в полной мере. И уж тем более - мало кому приходит в голову делиться своим опытом с младшими коллегами.

И в то же время прокрастинация - это то, что случается абсолютно со всеми людьми. Рано или поздно, так или иначе. Обычно с прокрастинацией мы плотно знакомимся ещё в школе. И если в этом возрасте все шишки принято валить на систему образования и наших учителей, то в случае с любимой работой всё оказывается гораздо сложнее. Человек снова сталкивается с ощущением невозможности продолжать свою работу, при этом испытывая чувство ответственности перед собой и работодателем, в результате чего делает худший из возможных выборов: начинает себя винить.

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

Каюсь, я и сам грешен. Я до сих пор не смог избавиться от этого рефлекса. И всё же, это не более, чем рефлекс. Прокрастинация - это состояние, в которое много раз в течение жизни попадает любой человек. А значит, у него есть определённые механики. Определённые причины появления и способы устранения.

Как бороться с прокрастинацией?

Никак.

Как работает прокрастинация?

Важно понять: это защитный механизм. С ним не надо бороться, т.к. это всего лишь сигнал о том, что что-то не так. И хотя локальных причин ее возникновения может быть бесконечное множество, в общем и целом прокрастинация - это сигнал об усталости. Вы устали и не можете продолжать работать. Усталость может быть любой, в том числе и по не вполне очевидным причинам: физическая, моральная, от запрета себе быть собой. Конечно, в первую очередь стоит отдохнуть. Сходить в отпуск или хотя бы один-два вечера посвятить себе любимому вместо всяких “должен”.

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

Причины возникновения прокрастинации и ее решения

Невыполнение хотелок.

Наш ум устроен так, что мы все время вынуждены выбирать между "хочу" и "надо". И для максимальной эффективности их необходимо чередовать. Если вы все время свои хотелки откладываете на потом, на после “более важных вещей”, после "надо", вас ждёт прокрастинация и выгорание. Какими бы ненужным и глупыми ни казались ваши хотелки - позвольте их себе, регулярно позволяйте их себе. Например, для меня долгое время отдушиной была работа над фреймворком yii3. Рабочие задачи я писал "как надо", а фреймворк писал "как хочу". Сюда же - компьютерные и спортивные игры, походы, музыка, кино и пр.

Перегруженность планами.

Как часто вы откладывали какую-то задачу на потом? Может быть, меняли приоритеты? А бывает ли такое, что какая-то задача откладывается на потом ещё и ещё раз? Конечно, так бывает у всех. И порой это превращается в проблему. Проблема состоит в том, что мы стараемся удержать в голове очень большое количество задач. Необязательно это большие задачи по написанию кода. Это может быть проверка почты, обязательства кому-то ответить, ожидающее ревью кода и так далее. Проблема в том, что чем больше таких задач мы пытаемся запомнить - тем больше сил на это тратим. Ее решение - список дел. Лично я подхожу к нему в два этапа:

1. Сначала - выписываю все свои планы. Вернее, все свои планы и хотелки. Всё, что я так или иначе собираюсь сделать и в ближайшее время, и позже. После чего этот список подвергается редактуре: я убираю из него всё, что считаю ненужным в текущей ситуации. Это не просто вычеркивание пункта из списка, это решение не двигаться в этом направлении, не тратить никакие силы на достижение цели. Полный отказ от нее.
2. А затем этот список сортирую по срочности и распределяю по нескольким категориям. Например, домашние дела и рабочие дела. Плюс помечаю некоторые дела как срочные. Цель этого списка - в том, чтобы в дальнейшем делать только то, что в нем находится. Снять когнитивную нагрузку с попыток вспомнить и верно приоритизировать все задачи.
   Звучит это дико, однозначно. Для меня это тоже выглядело странной хренью поначалу. Но вы все же попробуйте. Этот метод освободит вам значительное количество ресурсов, позволит эффективно работать значительно дольше, чем это возможно сейчас. И отвечаю сразу на вопрос о ситуации, когда необходимо сделать что-то, чего нет в списке: вносите это дело в список. Ещё раз: не делайте ничего, чего нет в списке, а если что-то такое всё же надо сделать - внесите это дело в список.

Частое переключение.

У людей есть такая особенность: нам нужно время, чтобы переключаться на разнотипные задачи. Другими словами, если вы работали, и вас что-то отвлекло, то вам потребуется до получаса времени на то, чтобы вернуться обратно в рабочее состояние и работать также эффективно, как вы работали до этого. И это - если вы в хорошем состоянии: выспались, не утомлены и так далее. В менее продуктивном состоянии этот процесс займёт ещё больше времени.
Таким образом, появляется простая рекомендация: на время работы обеспечить себе максимально комфортную среду, исключив отвлекающие факторы: выключите уведомления на телефоне, попросить жену не беспокоить, отправить детей в детский сад, и так далее. Только представьте: если раз в 10 минут на ваш телефон будет приходить уведомления, это будет на 10 минут выбивать из колеи. А это значит, что в течение рабочего дня вы так и не начнёте работать настолько эффективно, насколько вы можете. И, уверяю, вам только кажется, что уведомление из чата вас не отвлекают: на самом деле на долю секунды ваш ум отвлекается на мысль: "А надо ли мне прочесть это сообщение?". И это сбивает с рабочего ритма.

Избыток эндорфиновых всплесков.

Результат другой крайности между "хочу" и "надо". Когда мы выполняем свою хотелку, то получаем заряд эндорфинов прямо в мозг. А если регулярно идём на поводу у своих хотелок, то со временем получаем зависимость от них и неизбежно приходим к самым простым способами получения дозы эндорфинов. Это еда и всевозможные ленты: тикток, инстаграм, сериалы, чтение содержимого чатов и т.п. И, конечно, игры. Особенно - игры с короткими раундами и кликеры.
Все эти вещи объединены одним: каждая из них - простой и доступный способ получения дозы эндорфинов. А мозг их любит. И если вы дошли до этого этапа, путь к продуктивности будет связан с абстинентным синдромом. Вам все время будет хотеться ещё. Хотя бы один бутерброд, хоть одним глазком посмотреть сериал, всего один квест завершить в игре… Поверьте моему опыту 😄 В какой-то момент я понял, что любую свободную минуту я обязательно заполняю телефоном. Если времени совсем мало или нет желания что-то конкретное делать - листаю чаты. В других случаях - игры/сериалы. По сравнению с этим все остальные способы времяпрепровождения стали скучными, в том числе - работа.
А технически дело в том, что рецепторы в мозгу выработали привыкание к эндорфинам. И единственный путь - уменьшить дозу, чтобы чувствительность восстановилась, и мир снова заиграл яркими красками. Заодно освободится куча времени на другие дела, а общий тонус повысится.

Психотерапевт.

Сегодня сходить к психотерапевту - не такой зашквар, как считалось 10 лет назад. Не пренебрегайте этой возможностью. Хороший психотерапевт обязательно сократит ваш путь от прокрастинации к продуктивности, т.к. поможет быстро и эффективно найти и устранить причины ее возникновения. Почему я говорю “психотерапевт”, а не “психолог”? Если совсем коротко, поэтому:

• Психолог - это выпускник с корочкой. Так же, как и любой ваш бывший однокурсник - программист. Можно утверждать, что любой психолог знает основы работы психики, а вот глубже - далеко не факт.
• Психотерапевт - это психолог, прошедший теоретическую и практическую подготовку к ведению психотерапии, т.е. работе с людьми. В нашем понимании - это человек, освоивший как минимум php, MySQL, JS, CSS и хотя бы один php-фреймворк или CMS. Психотерапевт уже знает не только о психике абстрактно, но и том, как с ней работать.
• Психиатр - это психотерапевт, который имеет право выписывать лекарства. При прокрастинации в этом обычно нет нужды.

Постскриптум и литература

Есть и другие причины для прокрастинации, как и другие способы борьбы с ней. Главное - не надо воспринимать ее как нечто ненормальное и пытаться с ней бороться. Это лишь сигнал организма. Если вам не подошло ничего выше, или есть желание разобраться в вопросах прокрастинации и эффективности получше, рекомендую этого отличного парня, професионального прокрастинатолога: Максим Дорофеев. Он дает очень дельные советы в доступной форме и в разных видах: книги, видео, форум и чат. Ссылка не оплачена, мне действительно нравится то, что и как он делает. Искренне советую познакомиться с его творчеством, а начать можно с одного из его выступлений на конференции.

Хорошего вам дня и не выгореть! 😊

TL;DR: Как начать.

Моя история

А сейчас я один из core-разработчиков фреймворка Yii3. Я очень люблю этот фреймворк, и люблю помогать ему становиться лучше. История о том, как я вошел в команду разработки популярного фреймворка, проста до банальности. Однажды я зашел в чат фреймворка в telegram и увидел, как Александр Макаров, мейнтейнер фреймворка, отвечает на вопросы в чате. На все, не выбирая "интересное" или "полезное". Кажется, он тогда написал что-то на тему того, чтобы ему писали в личку, если есть какие-то вопросы лично к нему, но я не уверен. Признаться, я был ошарашен. Можно сказать, Александр был моим кумиром, и вдруг - вот он, в чатике, где с ним можно поболтать так же, как с моими друзьями. В тот момент я понял, что не общался с ним до сих пор лишь по той причине, что почему-то решил, что он не станет со мной общаться. И по той же причине я не участвовал в жизни Yii.

Тогда я решился на авантюру. Мне было страшно, но я это сделал: написал ему. Казалось бы, где Александр, а где я, но я убеждал себя, что в первую очередь мы оба - люди, а значит - нам не чуждо общение, да и вообще - за спрос не бьют. Я написал что-то вроде этого:

Привет! Меня зовут Виктор, я PHP-разработчик. Мне очень нравится фреймворк Yii, и я хотел бы помочь в выпуске новой, третьей версии. Подскажи, пожалуйста, с чего можно начать?

И он поблагодарил меня за энтузиазм и дал несколько ссылок на тикеты на гитхабе, за которые я вскоре принялся. Тикеты действительно были на уровне "с чего начать". Не помню, что именно, но это были мелочи. Постепенно я втянулся в этот процесс и стал делать все более сложные вещи. Например, я написал первую версию библиотеки yiisoft/validator. Не полностью, proof of concept. А потом я сменил основную работу и сколько-то месяцев не мог заниматься OpenSource-разработкой. Но ребята взяли мой код, доработали и превратили в полноценную библиотеку. Сейчас у нее уже совершенно другие архитектурные подходы, но лично для меня это много значит: это был мой первый серьезный вклад в популярный и, ИМХО, лучший фреймворк.

Что я вынес из OpenSource-разработки

Конечно, я вынес много опыта. Я продолжаю с радостью заниматься OpenSource в свободное время и продолжаю получать все новый опыт. Но если вычленить самые яркие приобретения, я назову эти пункты:

Глубокое понимание принципов SOLID и в целом архитектуры приложений и библиотек.

В коммерческой разработке у тебя обычно нет возможности спокойно сесть и проанализировать различные архитектурные решения, написать несколько вариантов и выбрать один из них, или даже полностью переработать первоначальный вариант, проведя глубокий рефакторинг. В OpenSource другие ценности: если в коммерческой разработке один из основных критериев выбора чего угодно - это соотношение цены/качества, то здесь ставка всегда на качество. И полученный в OpenSource опыт создания SOLID'ных архитектур я теперь применяю в коммерческой разработке, где важнее не следовать принципам до конца, а понимать, где и в какой степени им следовать стоит, и какова будет цена их соблюдения и нарушения.

Тестирование.

До Yii у меня было мало опыта в написании тестов. В основном - то, чему я научился сам. А здесь мы начали применять комплексный подход:

• Psalm, инструмент статической проверки типов.
• PHPUnit, фреймворк для написания автоматических тестов.
• Infection, инструмент проверки качества тестов, написанных на PhpUnit (мутационное тестирование).

И при этом мы делаем максимально полное покрытие кода тестами. К релизу любого пакета Psalm выставляется на уровень 1, а Infection показывает почти 100% MSI (например, yiisoft/assets. Особенно ценно то, что я попал на новый виток развития фреймворка, и эти инструменты и способы их использования мы выбирали вместе, вместе покрывали тестами первые пакеты. Надо сказать, свой первый пакет я покрыл тестами так, что потом сам держался за голову: это было весьма сложно поддерживать, развивать. Но это тот случай, когда на ошибках учатся. Хотя именно те тесты на момент написания этой статьи еще не отрефакторены 😆

Опыт работы в самоуправляющемся коллективе.

Да, в core-команде разработки фреймворка Yii все равны. Как правило, мы придаем больше значения мнению Александра Макарова (@samdark), но и он от остальных не отмахивается. Если у кого-то есть вопросы или возражения - мы обсуждаем их до тех пор, пока не придем к какому-то общему решению.
У нас тоже не без минусов, конечно. Например, долгое время именно Александр выполнял всю менеджерскую и управленческую работу. Он фактически был нашим начальником. Он принимал архитектурные решения, мержил PR и релизил пакеты, он же определял приоритеты команды. И в какой-то момент на пару месяцев выпал из разработки фреймворка. Нам пришлось крутиться самим. И я очень рад, что мы выкрутились. Не сразу, но мы наладили процессы так, что они не требовали присутствия Александра. Мы созвонились и обсудили самые острые вопросы, договорились о компромиссах и приоритетах. А потом и @samdark подтянулся. Теперь он больше стал помогать остальной команде налаживать процессы по новой схеме, чем непосредственно управлять нашей деятельностью. Он по-прежнему самый уважаемый член команды и мейнтейнер фреймворка, но уже не является бас-фактором. Это чудесный, замечательный опыт: люди, объединенные одной идеей, по своей инициативе скооперировались и делают общее дело. И большинство из нас делает это бесплатно. Что-то подобное, вероятно, можно получить в т.н. "бирюзовых компаниях", но их на сегодня довольно мало, так что OpenSource остается более простым способом получить подобный опыт.

Это тот опыт, который оказался самым ярким для меня. Для каждого он свой. Но самое главное - для каждого найдется много такого, что очень сложно получить в коммерческой разработке. Не говоря уже о том, насколько ценна строчка о том, что у вас есть опыт разработки популярного OpenSource-инструмента, в резюме.

Как самому начать писать код в OpenSource-проекте

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

1. Узнать, в чем именно нужна помощь.
2. Написать требуемый код и отдать его на ревью.
3. Поправить код по замечаниям, которые появятся во время ревью.

Это действительно все. После этого вашим кодом начнут пользоваться сотни/тысячи/миллионы людей. Остаётся лишь продолжать попеременно выполнять пункты из этого списка.

Однако, самое сложное - это начать. Надо откуда-то узнать, чем именно можно помочь. Но тут тоже все просто: если вы не видите тикетов, которыми могли бы заняться прямо сейчас, задайте вопрос в сообществе продукта. Сейчас, наверное, у всех OpenSource-продуктов есть свои чаты или хотя бы форумы. Например, у Yii3 это телеграм-чаты @yii3ru и @yii3en. Алгоритм просто: заходим в чат, выражаем желание помочь и просим подкинуть тикет, которым стоит заняться. Если это для вас впервые - стоит попросить что-нибудь самое простое, чтобы на паре мелких задач прочувствовать весь процесс от чтения тикета до мержа вашей задачи в мастер.

Что мешает заняться разработкой OpenSource-продукта

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

1. Нет времени

Скорее всего, у вас есть фултайм-работа, может быть - семья. И 24 часа в сутки заняты, а то и все 25. Однако, секрет прост: можно заниматься OpenSource в свободное рабочее время. Может показаться, что "свободное" и "рабочее" - вещи несовместимые, однако это не так. Дело в том, что действительно продуктивны мы всего 2-4 часа из всего рабочего дня. Все остальное время занимают другие вещи: ревью кода, текучка, бюрократия и т.п. Но это - в идеале, а обычно все это время занято прокрастинацией. Подумайте: действительно ли ваши задачи для занимать столько времени на реализацию, сколько они занимают? Нет? Тогда предлагаю эксперимент: занимайтесь 2 часа в день своей работой с максимальным погружением в нее, не отвлекаясь ни на что. Подготовьте четкий план действий, переключите все чаты и почту на беззвучный, и - вперёд. Вторая часть плана - обязательно посвятить часть времени тому, что приносит удовольствие, чему вы искренне рады. Лично я порой это время трачу на разработку фреймворка 😃 Ну и значительную часть времени - на вялотекущие рабочие задачи, не требующие большой концентрации. И не стоит забывать про обед, где вы не будете заниматься работой ни в каком виде в течение часа. И ещё желательно устраивать себе прогулку или какие-то физ. упражнения в перерывах от работы.
Бьюсь об заклад, что при таком режиме ваша эффективность вырастет, а часть освободившегося времени можно будет отдать любимому OpenSource-проекту.

2. Я неопытен

Значит, OpenSource - для вас! Это превосходное место для наработки опыта. Как правило, задач хватает самой разной сложности: не только по разработке новых архитектурных подходов и оптимизации производительности, но и различные простые, но нужные мелочи: изменить стиль кода, дописать документацию, переименовать файлы и классы и т.п. И вы очень поможете, если возьмёте эти вещи на себя. При этом вы вольны брать и то, в чем ещё надо будет разобраться для реализации, и даже просить помощи у основных разработчиков продукта. Вход в OpenSource-разработку возможен на любом этапе профессионального развития, если вы уже хорошо знаете применяемый в продукте язык программирования.

3. Боюсь, что меня засмеют

Для меня очень странно было услышать эту причину. Я ещё не встречал настолько токсичных разработчиков OpenSource-инструментов, чтобы они как-то высмеивали тех, кто хочет им помочь. Да и за что? Единственное, что приходит в голову - что знакомые, услышав, что вы решили сделать свой вклад в OpenSource, из зависти и неуверенности в себе могут попытаться как-то оскорбить вас, остановить, чтобы ни в коем случае не оказалось, что вы "лучше их". Бросайте таких знакомых, если они у вас есть: не стоит идти ко дну вместе с ними. Наш с вами путь - только вперёд!

4. Мне страшно.

Конечно, страшно. Как и любому человеку, который собирается заняться чем-то новым. Это нормально. Без страха нет развития, а смелый человек - не тот, кто не боится, а кто действует, несмотря на страх. А потому лучшее решение - бояться и сделать 😊 Найти новых коллег, и кто знает, может быть - друзей и призвание?

• Не надо морочаться с настройкой локального окружения, переключением версии PHP, установкой дополнительных библиотек и разрешением конфликтов
• Достаточно одного текстового файла с алиасами командной строки, чтобы любая актуальная версия PHP работала на любом компьютере. А отсюда
  • Легкость переноса данных между машинами
  • Можно спокойно снести систему на своем основном компьютере, восстановление работы с PHP будет просто как git pull

Что такое алиасы

Алиас - это дополнительная или переопределенная команда в терминале, при вызове которой на самом деле вызывается другая команда. Например, если вы для вывода списка файлов в папке всегда пишете ls -la, имеет смысл сделать алиас alias ls='ls -la'. Таким образом каждый раз, когда вы будете набирать в терминале команду ls, фактически будет вызываться ls -la.
Создание алиаса - это команда для терминала. Т.е. вы можете в терминале написать alias ls='ls -la', и это будет работать. Но только в этой сессии терминала. Чтобы это работало всегда - надо запускать такую команду во всех сессиях. Это делается по-разному в разных shell-оболочках. Я расскажу про то, как это делается в bash, который стоит по умолчанию в большинстве linux-дистрибутивов. Если вы используете ZShell или другую оболочку - будем считать, что вы в курсе, как в ней создаются алиасы.

Итак, bash. Любой пользователь баша может создать в своем домашнем каталоге файл .bashrc, который выполняется всегда при старте терминала. Убунту создает его по умолчанию и по умолчанию же делает в нем такую запись:

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

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

PHP

Для PHP я создал набор вот таких алиасов:

alias php='docker run --rm -it -u `id -u`:`id -g` --volume `pwd`:/app -w /app ghcr.io/mileschou/xdebug:8.1 php  $@'
alias php81='docker run --rm -it -u `id -u`:`id -g` --volume `pwd`:/app -w /app ghcr.io/mileschou/xdebug:8.1 php  $@'
alias php8='docker run --rm -it -u `id -u`:`id -g` --volume `pwd`:/app -w /app ghcr.io/mileschou/xdebug:8.0 php  $@'
alias php74='docker run --rm -it -u `id -u`:`id -g` --volume `pwd`:/app -w /app ghcr.io/mileschou/xdebug:7.4 php  $@'

В итоге я пишу в терминале команды вроде php -a для интерактивной работы или php vendor/bin/phpunit для запуска тестов, и все работает так, будто php стоит локально на мой машине. А когда для какого-то проекта мне нужна другая версия php, я пишу, например, php74 vendor/bin/psalm.

Итак, айда разбирать приведенные выше команды. Для каждой версии у меня написано одно и то же, меняется только собственно версия.

• docker run запускает новый контейнер на основе указанного образа (он - в конце команды). Документация по docker run. Все опции этой команды описаны в документации на той же странице.
• --rm - этот параметр говорит о том, что контейнер должен быть удален после того, как закончит работу. Если его не указать, то при каждом docker run будет создаваться новый контейнер, после остановки он никуда не денется, и вскоре у вас закончится место на жестком диске.
• -it - этот параметр нужен для работы в интерактивной сессии командной строки. Если его не указать, то не будут работать те команды php, которые ждут какой-то реакции от пользователя (например, php -a или скрипты, просящие ввести данные).
• -u запускает контейнер от имени определенного пользователя. По умолчанию контейнер запускается от имени суперпользователя root, что может привести к проблемам с правами доступа к файлам, которые монтируются с локальной машины и изменяются/создаются в контейнере. `id -u` и `id -g` возвращает id пользователя и его группы соответственно, и в большинстве случаев это будет 1000. Эти команды заключены в обратные кавычки для того, чтобы они выполнились до вызова алиаса. В итоге команда в алиасе вызовется с таким значением параметра пользователя: -u 1000:1000, если ваши id пользователя и группы равны 1000.
• --volume `pwd`:/app - этот параметр монтирует текущий путь в файловой системе (pwd) в контейнер по пути /app. Другими словами, ваши файлы из текущей папки будут доступны во контейнере по пути /app.
• -w /app - устанавливаем путь /app в качестве рабочей папки в контейнере.
• ghcr.io/mileschou/xdebug:8.1 - название запускаемого образа контейнера и его тег (версия). Я использую этот образ вместо официального php, т.к. в официальном нет XDebug, а порой бывает нужна отладка или вычисление покрытия кода тестами. Тег всегда указывается после двоеточия, в этом примере - это 8.1
• php $@ - это команда, запускаемая внутри контейнера. При этом $@ - это переменная bash, указывающая на строку после алиаса. Покажу на примере. Если я напишу в терминале php vendor/bin/phpunit --foo --bar, в переменной $@ окажется vendor/bin/phpunit --foo --bar.

PhpStorm

Шторм прекрасно работает с контейнерами. Для того чтобы была возможность кнопкой запускать тесты, статический анализ или другие скрипты из Шторма, надо добавить контейнер в качестве интерпретатора. Документация.

Однако, на этом не приключения заканчиваются. Есть еще один частый кейс использования php в терминале, composer.

Composer

С композером все максимально похоже. Однако, команда тут значительно длиннее, т.к. добавляются переменные окружения и тома. Нужны они для двух целей: хранить настройки и кеш композера между запусками контейнера и прокидывать данные для ssh-авторизации с хост-машины в контейнер. У меня для него два алиаса на случай, если еще придется работать с проектом, где жестко вшита первая версия. Тут я уже использую официальные образы.

alias composer='docker run --rm -it --tty -u 1000:1000 -e COMPOSER_HOME=/composer-data/.composer -e COMPOSER_CACHE_DIR=/composer-data/.composer/cache -e SSH_AUTH_SOCK=/ssh-auth.sock --volume `pwd`:/app --volume /home/`whoami`/.composer:/composer-data/.composer --volume /run/user/1000/keyring/ssh:/ssh-auth.sock --volume /etc/passwd:/etc/passwd:ro --volume /etc/group:/etc/group:ro composer:2 $@'
alias composer1='docker run --rm -it --tty -u 1000:1000 -e COMPOSER_HOME=/composer-data/.composer -e COMPOSER_CACHE_DIR=/composer-data/.composer/cache -e SSH_AUTH_SOCK=/ssh-auth.sock --volume `pwd`:/app --volume /home/`whoami`/.composer:/composer-data/.composer --volume /run/user/1000/keyring/ssh:/ssh-auth.sock --volume /etc/passwd:/etc/passwd:ro --volume /etc/group:/etc/group:ro composer:1 $@'

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

• -e - этот параметр задает переменную окружения внутри контейнера. Я задаю их несколько:
  • COMPOSER_HOME=/composer-data/.composer - где композер будет искать и хранить свои данные (например, токены доступа на GitHub)
  • COMPOSER_CACHE_DIR=/composer-data/.composer/cache - где композер будет искать и хранить свой кеш. Это нужно для оптимизации. Если не хранить кеш на хосте, он будет каждый раз заново скачивать все пакеты. Если же в кеше есть пакет нужной версии - композер просто скопирует файлы из кеша в проект.
  • SSH_AUTH_SOCK=/ssh-auth.sock - путь к авторизационному сокету для ssh-агента
• Плюс я подключаю еще несколько томов с хоста. Это пары к указанным выше переменным окружения.
  • --volume /home/`whoami`/.composer:/composer-data/.composer - сохраняю данные композера на хосте между запусками контейнеров
  • --volume /run/user/`id -u`/keyring/ssh:/ssh-auth.sock - прокидываю в контейнер авторизационный сокет для ssh-агента
  • --volume /etc/passwd:/etc/passwd:ro и --volume /etc/group:/etc/group:ro прокидывают в контейнер учетные записи пользователей с хоста в режиме "только для чтения" (за это отвечает :ro в конце). Стоит сразу заметить, что это небезопасно, и делать так стоит, только если вы понимаете, что и зачем делаете. Лично я считаю, что официальные образы композера достойны доверия, но это лишь мое личное мнение. А без этих томов не будет работать авторизация на гитхабе по SSH с ключами с хост-машины.

Стоит помнить, что в контейнере - минимально необходимая для работы композера сборка. Это значит, что порой вам придется дописывать флаг --ignore-platform-reqs к вызываемой команде: composer i --ignore-platform-reqs.

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

Если я захочу наследовать класс, а там метод private, мне придется изучать код, чтобы понять, зачем его сделали private и могу ли я сделать его публичным.

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

interface FooInterface {
  public function foo();
}

class Foo implements FooInterface {
  public function foo() {
    // do stuff
    $this->bar();
    // do stuff
  }

  public function bar() {
    // do stuff
  }
}

Условимся, что на момент написания кода метод bar нигде больше не используется, и технически нам все равно, делать его публичным или приватным.

Private

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

Public

Если сделать метод публичным по умолчанию, мы избежим вероятности того, что нам понадобится выполнять описанную выше работу в будущем. Шучу, конечно не избежим 😄

Давайте подумаем, с какими ещё проблемами мы сможем столкнуться через несколько лет после написания такого кода. Мы думаем о будущем, поэтому давайте представим, что мы не меняли этот метод года 3. И теперь нам надо удалить его или изменить сигнатуру. Первый вопрос, который встанет: используется ли этот метод в других местах проекта? Кто угодно из разработчиков мог вызвать публичный метод из любого другого места, и их все надо найти. Вы можете сказать, что современные IDE решают этот вопрос мгновенно, но что, если использовалась черная магия фреймворков?

Усложним ее ещё немного: мы нашли несколько мест, где метод bar использовался, но не вполне понятно, зачем, а авторы того кода уже не работают в вашей компании. Что делать в этом случае?

Добавим в копилку ещё одну потенциальную проблему. Какой-то разработчик решил немного изменить функционал bar, но не стал глубоко искать вызовы этого метода. А они были, но спрятанные.

Выводы

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

Пример рефакторинга из private в public

Итак, в нашем проекте есть версия класса Foo с приватным методом bar. В какой-то момент стало очевидно, что функционал этого метода нужен ещё в паре мест проекта. В большинстве случаев можно вынести bar в отдельный класс, который можно будет использовать где угодно в проекте с помощью любимого DI-контейнера. Итого полный код будет выглядеть так:

class Bar {
  public function bar() {
    // do stuff
  }
}

interface FooInterface {
  public function foo();
}

class Foo implements FooInterface {
  __construct(private Bar $bar) {}

  public function foo() {
    // do stuff
    $this->bar->bar();
    // do stuff
  }
}

В этом случае публичный контракт на функционал bar будет заключён ровно в тот момент, когда он стал нужен. Соответственно, и отношение к нему будет соответствующее: как к сознательно реализованному контракту, а не "еще одному публичному методу, который навряд ли где-нибудь используется". Потому что в таком проекте ничего публичного просто так не делается.

Ловушка долгоживущих процессов

Ваше приложение растёт, и вы решаете оптимизировать его производительность, переведя на современный веб-сервер вроде RoadRunner, Swoole или FrankenPHP. Теперь PHP-процессы не умирают после каждого запроса, а переиспользуются. И тут начинается самое интересное: данные одного пользователя случайным образом "просачиваются" в запросы другого пользователя, потому что состояние сервиса сохраняется между запросами.

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

Эволюция использования

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

• Код, который вызывался один раз, начинают вызывать в цикле
• Простой обработчик HTTP-запроса переносят в консольную команду
• Синхронные операции становятся асинхронными
• Появляется необходимость масштабирования и параллельного выполнения

В каждом из этих случаев наличие внутреннего состояния становится источником проблем и требует переработки кода.

Решение: Сервисы без состояния

Stateless сервис - это класс, который не хранит внутреннего состояния между вызовами своих методов. Каждый метод работает только с теми данными, которые были переданы ему в качестве параметров.
Такой подход позволяет абстрагироваться от контекста использования сервиса. Stateless сервис может быть вызван и разово, и в цикле, и в long running приложении. Ему это не важно.

Какие же есть альтернативы? Это сервисы с состоянием, или stateful. Рассмотрим пример, который я часто вижу в разных проектах.

Пример сервиса с состоянием

class OrderProcessor
{
    private PaymentGateway $paymentGateway;
    private float $taxRate;
    private ?User $currentUser = null;
    
    public function __construct(PaymentGateway $paymentGateway, float $taxRate)
    {
        $this->paymentGateway = $paymentGateway;
        $this->taxRate = $taxRate;
    }

    public function setUser(User $user): void
    {
        $this->currentUser = $user;
    }

    public function processOrder(array $items): void
    {
        $total = $this->calculateTotal($items);
        $this->paymentGateway->charge($this->currentUser, $total);
    }

    private function calculateTotal(array $items): float
    {
        $subtotal = array_sum(array_map(
            fn($item) => $item['price'] * $item['quantity'],
            $items
        ));
        
        return $subtotal * (1 + $this->taxRate);
    }
}

В этом примере обязательно нужно указывать корректного пользователя в качестве состояния сервиса. И результат выполнения метода processOrder() полностью от него зависит. Если по какой-то причине не был вызван метод setUser(), будет попытка списать деньги с другого человека. Что еще может пойти не так? Что угодно. Основная причина - человеческий фактор: можно быть уверенным, что рано или поздно какой-то из программистов проекта не уследит за корректной установкой пользователя в сервис, что приведет к серьезной ошибке. А вот, что может произойти технически:

• Метод забыли вызвать
• После установки корректного пользователя установили другого (например, в момент обработки цепочки событий между вызовами setUser() и processOrder())
• После установки корректного пользователя была подмена инстанса сервиса

Пример stateless реализации

Для того, чтобы избавиться от состояния в примере выше, достаточно убрать поле с пользователем и соответствующий метод, а самого пользователя добавить в параметры того метода, который действительно от него зависит:

class OrderProcessor
{
    private PaymentGateway $paymentGateway;
    private float $taxRate;
    
    public function __construct(PaymentGateway $paymentGateway, float $taxRate)
    {
        $this->paymentGateway = $paymentGateway;
        $this->taxRate = $taxRate;
    }
    
    public function processOrder(User $user, array $items): void
    {
        $total = $this->calculateTotal($items);
        $this->paymentGateway->charge($user, $total);
    }

    private function calculateTotal(array $items): float
    {
        $subtotal = array_sum(array_map(
            fn($item) => $item['price'] * $item['quantity'],
            $items
        ));
        
        return $subtotal * (1 + $this->taxRate);
    }
}

Преимущества такого подхода

1. Предсказуемость:

   • Поведение методов зависит только от входных параметров
   • Один и тот же ввод всегда даёт один и тот же результат (в этом примере в качестве результата мы всегда вызываем paymentGateway->charge() с одними и теми же аргументами)
   • Нет неявных зависимостей между вызовами

2. Простота тестирования:

   • Не нужно заботиться о начальном состоянии
   • Тесты становятся проще и понятнее
   • Можно тестировать методы изолированно

3. Потокобезопасность:

   • Можно безопасно использовать в многопоточной среде
   • Нет проблем при масштабировании
   • Отсутствуют race conditions

Разбираемся с разными типами данных в сервисах

Не всё, что хранится в свойствах класса, является вредным состоянием. Давайте разберем три принципиально разных типа данных:

1. Настройки (Configuration)

Это неизменяемые значения, определяющие поведение сервиса:

class OrderProcessor
{
    private readonly float $taxRate;
    private readonly float $minimumOrderAmount;
    
    public function __construct(float $taxRate, float $minimumOrderAmount)
    {
        $this->taxRate = $taxRate;
        $this->minimumOrderAmount = $minimumOrderAmount;
    }
}

Настройки допустимы в свойствах класса, потому что:

• Не меняются во время жизни объекта
• Определяют базовое поведение сервиса
• Являются частью конфигурации приложения
• Не зависят от контекста выполнения

2. Зависимости (Dependencies)

Это другие сервисы или ресурсы, необходимые для работы:

class OrderProcessor
{
    public function __construct(
        private readonly OrderRepository $orderRepository,
        private readonly PaymentGateway $paymentGateway,
        private readonly LoggerInterface $logger
    ) {}
}

Зависимости можно хранить в свойствах, так как они:

• Являются инструментами для выполнения операций
• Обычно сами stateless
• Внедряются через конструктор
• Не меняются во время работы

3. Эфемерное состояние (Ephemeral State)

Это и есть то, чего следует избегать - данные, меняющиеся в процессе работы:

// Анти-паттерн!
class BadOrderProcessor
{
    private ?User $currentUser = null;
    
    // Избегайте таких методов!
    public function setUser(User $user): void
    {
        $this->currentUser = $user;
    }
}

Рекомендации по проектированию

1. Настройки:

   • Передавайте через конструктор
   • Делайте неизменяемыми (readonly)
   • Используйте value objects для сложных конфигураций

2. Зависимости:

   • Внедряйте через конструктор
   • Используйте интерфейсы
   • Не меняйте после создания объекта

3. Эфемерное состояние:

   • Передавайте через параметры методов
   • Избегайте методов set*
   • Используйте DTO для группировки параметров
   • Храните в БД или кэше при необходимости

Заключение

Проектирование сервисов без состояния - это не просто модное архитектурное решение. Это необходимость в современном PHP-разработке, где приложения должны быть готовы к масштабированию, параллельному выполнению и работе в долгоживущих процессах.

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

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

Существует два основных подхода к организации работы с сущностями: так называемые "богатая" и "анемичная" модели. Богатая модель подразумевает, что сущность сама знает, что и как с ней можно сделать. Итак, в интернет-магазине есть такая сущность, как "заказ". В богатой модели предметной области его интерфейс будет выглядеть примерно так:

interface OrderInterface
{
    public function getId(): OrderId;
    public function getProducts(): array;
    public function getCustomer(): Customer;
    public function getStatus(): OrderStatus;
    public function create(): void;
    public function update(): void;
    public function delete(): void;
    public function moveTo(OrderStatus $status): void;
    public function removeProduct(Product $product): void
    // etc.
}

То есть он содержит методы, не только сообщающие информацию о состоянии заказа (геттеры), но и каким-то образом его изменяющие: сохраняющие в БД, изменяющие статус и пр.

Логика подсказывает, что у такого подхода будут проблемы с принципами Single Responsibility и Interface Segregation из SOLID, а связанность (coupling) кода будет крайне высокой (вы только представьте, сколько действий в других подсистемах надо совершить, чтобы создать заказ: платежи, логистика, склад и пр.). Кроме того, я ни разу не видел успешного применения этого подхода. Не исключаю вариант, что просто не умею готовить богатую модель. Так что если у вас будет пример проекта, в котором она оправданно применена, буду рад увидеть его код.

Итак, мы подробнее остановимся на "анемичной модели". Называется она так потому, что у сущности нет никаких дополнительных обязанностей и знаний о чем бы то ни было, кроме ее собственного состояния. То есть, если брать пример выше, у Заказа останутся только геттеры. А начиная с php8.1, можно даже без них:

class Order
{
    public function __construct(
        public readonly OrderId $id;
        /** @var Product[] */
        public readonly array $products;
        public readonly Customer $customer;
        public readonly OrderStatus $status;
    ) {
    }
}

Итак, сущность в анемичной модели предметной области является DTO (Data Transfer Object, объектом для передачи данных).

Data Transfer Object

DTO - это представление данных, которое кочует из одного места в системе в другое. В идеале DTO создается на входе в систему и подается на выход из нее. Например, веб-контроллер: пользователь присылает данные, в контроллер они приходят в виде $_POST-массива, мы тут же формируем из них соответствующий DTO. И уже его отдаем внутренним сервисам системы. И внутри системы данные ходят исключительно в виде DTO.

Ключевыми особенностями DTO являются два нюанса:

Только представление данных, и ничего больше

В DTO по определению отсутствует какая бы то ни было логика. Это исключительно представление данных.
Такой подход позволяет использовать DTO для сквозной передачи данных между разными подсистемами, в том числе, когда эта передача осуществляется по сети: через API, очереди и т.п. Поскольку это лишь данные, их легко сериализовывать и десериализовывать. А отсутствие в них бизнес-логики гарантирует отсутствие сайд-эффектов от передачи объекта в очередной сервис или подсистему.

Иммутабельность

DTO по сути неизменяемы, и это их главное преимущество. Зачем? А представим, что DTO может измениться.
Допустим, у нас есть такой код: $service->foo($dto);, и мы знаем, что методу foo вообще незачем изменять состояние переданной в него DTO. Но время идет, код меняется, и где-то ниже по цепочке вызовов, не в самом foo появилось нечто подобное: $dto->bar = 'baz';. Как на это отреагирует код, который идет после вызова foo? Когда вы заметите, что поведение изменилось? Сколько часов уйдет на отладку?
Либо мы можем сразу сделать объект иммутабельным любым из этих способов:

• пометить все поля readonly
• сделать их private и обеспечить доступ через геттеры
• пометить класс @psalm-immutable, если Psalm используется в CI

Как же тогда внести изменения в данные? Никак. В этом и суть. Если бизнес-логика подразумевает изменение данных - необходимо создать новый объект с этими новыми данными. Иногда DTO может само подразумевать подобные операции. Для этого в соглашениях команды YiiSoft есть with-методы, возвращающие новый объект того же класса с измененными данными. Лично мне приятнее называть переменную $instance, а не $new, но это уже мелочи.

Сервис

Второй тип классов, необходимых в любом проекте. В противовес DTO, сервисы, наоборот, не имеют состояния и реализуют какую-то логику. Это репозитории, контроллеры, фабрики и прочие виды классов, которые что-то делают. Часто сервисы выполняют некоторую работу над данными, то есть над передаваемыми им DTO.
Каких же ошибок стоит избегать при написании сервиса и какую выгоду мы при этом получим?

Хранение состояния

Это единственная по-настоящему грубая ошибка при проектировании любого сервиса. Если сервис хранит некое состояние, есть большие шансы получить неожиданные сайд-эффекты при его повторном использовании. Если сервис не хранит никакого состояния, его легко можно использовать снова в другом месте. Либо в том же, в рамках того же php-процесса. А это не только облегчает дальнейшую разработку, но и даёт возможность использовать инструменты вроде RoadRunner и Swoole.
Итак, неправильно: $service->setData($data)->foo(), правильно: $service->foo($data). Если вам все же кажется необходимым в вашем сервисе оставить состояние для работы каких-то отдельных методов, вполне вероятно, что вам стоит разделить этот сервис на два.

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

• Зависимости - это другие сервисы, позволяющие текущему делать его работу. Просто следуем принципу dependency Inversion и доставляем классу его зависимости в конструктор.
• Настройки - значения, позволяющие сервису работать. Данные для подключения к БД у репозитория, веб-адрес для API-клиента, префикс у кеша и т.п.
• Рантайм-кеш хранит в себе уже вычисленные значения в случае, если эти значения не изменяются со временем, а их повторное вычисление ресурсозатратно. Выглядит его использование примерно так:

  if (!isset($this->cache[$id]) {
    $this->cache[$id] = $this->build($id);
  }
  
  return $this->cache[$id];
• Состояние же не задаётся глобально для всего проекта/модуля, а изменяется в зависимости от контекста. Это единственный вид данных в сервисе, который может меняться в течение выполнения программы. Именно над ним или с его помощью сервис выполняет какую-то работу.

Таким образом, "хорошие" сервисы могут иметь зависимости, настройки и рантайм-кеш, а DTO - только состояние.

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

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

Dockerfile

Начнем с Dockerfile. Установка xDebug в поддерживаемых версиях php стала совсем тривиальной. Надо лишь установить PECL и вызвать pecl install, после чего - включить xDebug в настройках php. Для образа, основного на Alpine (например, php:8.2-fpm-alpine), эта команда выглядит вот так:

RUN apk add --no-cache linux-headers  \
    && apk add --update --no-cache --virtual .build-dependencies $PHPIZE_DEPS \  
    && pecl install xdebug \  
    && docker-php-ext-enable xdebug \  
    && pecl clear-cache \  
    && apk del .build-dependencies

Готово, образ с xDebug собран!

PhpStorm

Открываем окно настроек, идем в PHP -> Servers и добавляем новый сервер, обязательно указывая корректные маппинги.

Самые важные части на скриншоте выделены.

• Absolute path on the server: указываем, по какому пути доступны файлы проекта в контейнере В примере docker-compose.yml выше я прокинул их томом в контейнер по пути /var/www

• Name. Да, название сервера в данном случае играет ключевую роль, хотя обычно это поле - исключительно для ввода человекопонятного названия. Для корректной работы с xDebug оно должно полностью совпадать с тем, что мы написали в переменную окружения PHP_IDE_CONFIG. В конфиге выше написано serverName=docker, поэтому сервер в настройках PhpStorm я назвал тоже docker. Нужно это для того, чтобы PhpStorm смог сопоставить локальные файлы с файлами на сервере (в контейнере).

  Заметка

  Есть и другой вариант их сопоставления: вместо PHP_IDE_CONFIG можно использовать сопоставление по полям Host и Port, но тогда не будет работать отладка скриптов, запускаемых из консоли.

docker-compose.yml

Минимальный конфиг docker-compose у меня выглядит обычно вот так:

version: "3.8"

services:
  php:
    build:
      dockerfile: .docker/php/Dockerfile
      context: ./
    user: "${USER_ID:-1000}:${GROUP_ID:-1000}"
    restart: unless-stopped
    volumes:
      - ./:/var/www
    working_dir: /var/www
    environment:
      PHP_IDE_CONFIG: ${PHP_IDE_CONFIG:-serverName=docker}
      XDEBUG_MODE: ${XDEBUG_MODE:-off}
      XDEBUG_CONFIG: "client_host=host.docker.internal"
      XDEBUG_TRIGGER: 'yes'
    extra_hosts:
      - host.docker.internal:${HOST_IP:-172.17.0.1}
    dns:
      - 1.1.1.1
      - 8.8.8.8

Настройка xDebug здесь происходит через переменные окружения, спасибо Дерику Ретансу за столь удобный способ. Все возможные настройки xDebug и соответствующие переменные окружения можно посмотреть на специальной странице.

Изменять значение переменных окружения при локальной разработке очень удобно через файл .env. Он может содержать что-то вроде такого:

# Изменим название сервера PHP в настройках PhpStorm с docker на project-server
PHP_IDE_CONFIG=serverName=project-server

# Включим xDebug, ведь по умолчанию он выключен
XDEBUG_MODE=develop,debug,coverage

Минус этого подхода: чтобы debug-сессия не запускалась, надо либо убрать переменную окружения XDEBUG_TRIGGER, либо убрать debug из XDEBUG_MODE. В первом случае вы оставите себе возможность запускать дебаг-сессию через get-параметры и cookie, например с помощью расширения для Chrome.

Отдельного внимания заслуживает настройка extra_hosts в конфиге docker-compose.yml. Она добавляет в hosts контейнера указанные в ней записи, в данном случае - что домен host.docker.internal следует искать по IP 172.17.0.1. Обычно хост-машина доступна именно по этому адресу, но бывают и исключения, поэтому конфигурируется IP тоже через переменную окружения: чтобы ее можно было изменить.

Готовый проект

Простой проект с указанными настройками я выложил на гитхаб по адресу https://github.com/viktorprogger/xdebug-sample. Чтобы проверить на нем, что указанные настройки работают, склонируйте его к себе и выполните следующие шаги:

1. Настроить PhpStorm как я описывал выше
2. Создать файл .env со следующим содержимым:

   XDEBUG_MODE=debug
   XDEBUG_TRIGGER=yes
3. Поставить брейкпоинт в файле index.php
4. Включить прослушивание коннектов от xDebug в PhpStorm
5. Удалить extra_hosts из docker-compose.yml,если вы используете Windows или MacOS
6. Запустить команду docker-compose up -d. Поднимать сервисы нам ни к чему, а вот сеть создать надо.
7. Запустить команду docker-compose run --rm php php index.php. Перед первым запуском соберется образ контейнера, это займет несколько минут.
8. Вуаля, выполнение скрипта остановилось на вашем брейкпоинте!