5 из 8 Определение $_ENV происходит только при запуске

Чтение из env происходит только при запуске скрипта

Вообще, есть два варианта инициализации env:

1) приложение читает переменные из файл .env - в этом случае можно просто перечитывать файл раз в какой-то период

$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
$dotenv->load();

2) переменные задаются при запуске контейнера, например, из AWS Secrets Manager, Gitlab Variables, или так же из файл .env через docker compose.

В этом случае простого решения нет. Как правило, всё сводится к тому, что нужно перезапускать контейнер, соответственно и скрипт, поэтому в этом случае также важен Graceful Shutdown.

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

Ну и финалимся по теме Long Running

6 из 8 Мониторинг

Long Running скрипт, который работает около бесконечно, но как понять действительно ли он работает или просто завис?

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

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

Второй способ -- это использование внешних систем мониторинга типа sentry или new relic.

Дальше больше, можно смотреть в сторону реализации healthcheck, который будет использовать кубер и перезапускать скрипт, если тот не отвечает. Есть уйма реализаций, через обновление обычного файла, ключа в редисе, или statsd, через другие способы сбора метрик и т.д.

Вопрос, когда писать лог, или метрики для healthcheck. Здесь опять несколько вариантов:

1) самый простой: где-то в цикле , в самом начале, например;

2) специфичный: используя fibers, особенно если в проекте используются reactphp или amphp;

3) надежный, но и самый неоптимальный — register_tick_function

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



7 из 8 Деплой

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

В зависимости от способа оркестрации приложение может как перезапускаться, так и нет.

Опять нужно помнить на этом этапе про Graceful Shutdown.



8 из 8 Лимит дескрипторов ресурсов в 8,6 миллиарда

К этому пункту отношусь как с забавному факту. В реальности я ещё не встречался с задачами где даже потенциально это могло бы вызывать проблему 🙂

Но существует такой баг.

Дескриптор используется каждый раз, когда открывается какой-то ресурс, сокеты, соединение с БД, открытие файла и т.д. Их доступное кол-во 8,6 миллиардов. Но при закрытии ресурса, дескриптор нельзя переиспользовать.

Более подробно о баге можно почитать здесь https://bugs.php.net/bug.php?id=47396

Баг был обнаружен в PHP 5.2 , остается открытым. Я не проверял, актуален ли он для поддерживаемых версий php но вы можете проверить самостоятельно ради интереса )

Ну, собственно, на этом всё)

package by feature Упаковка кода

Хотел написать пост про package by feature, но когда начал собирать фактуру, понял, что проблема, которую я хотел обозреть, куда глубже. Поэтому сегодня поговорим про упаковку кода в целом.

На своей практике я чаще всего вижу 2 варианта упаковки кода:

1. Package by type - когда проект состоит из таких папок, как Controllers, Services, Repositories, Entities, DTOs и т.д. Обычный скелетон, который предлагает любой фреймворк.

2. Package by layer - когда проект состоит из папок, как App, Domain, Infra и т.д. Те, кто только начинают практиковать DDD, часто используют этот вариант.

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

3. Package by feature - когда проект делится на фичи: Feature1, Feature2, Feature3 и т.д.

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



А вот какой подход лучше?


Каждый подход хорош, пока кодовая база небольшая.

Package by type -- считаю самым отвратительным способом. Можно сказать, одна фича размыта по 5 или 6 папкам, между которыми приходится постоянно переключаться.

Package by layer -- супер, мы выделили слои, но у нас по-прежнему каждый слой содержит кучу функциональности, файлов и папок. Весь проект просто разделен на технические слои, а не по функциональности.

Package by feature -- код фичи инкапсулирован, но вероятно, фич может быть также много, они могут быть связаны между собой и использовать одни и те же сущности. Разбухает количество shared классов. Также несколько фич может относиться к какой-то определенной зоне функциональности продукта.



Что делать?

Забирать лучшее от каждого подхода.

В DDD есть понятие домена. В рамках такого домена существует своя модель, термины и свои правила. Каждый домен развивается независимо друг от друга. И это хорошая точка для начала упаковки. Таким доменами могут быть, например, billing, catalog, users и т.д. Здесь прослеживается подход package by feature. Домены могут быть простыми и сложными, например, billing может быть очень сложным, включать в себя оплату, выплаты, счета и т.д. И такой домен можно ещё покомпозировать и поделить на поддомены. Продолжаем делить по типу package by feature.

Код домена/поддомена можно поделить по-разному, всё зависит от его сложности. Если домен состоит из пары файлов, то смысла делить вообще нет. Если домен типа support или generic, то можно использовать package by type. Если домен сложный и/или core, то стоит поделить на слои App, Domain, Infra, UI, получив все преимущества чистой архитектуры.

Каждый слой также требует декомпозиции. Возьмем слой Domain, который может быть достаточно большим, классы в нём захочется упаковать по папочкам. И тут снова стоит поделить на фичи. Например, Order, Customer, Product. Не стоит делить по типу: Entity, Repository, ValueObject и т.д. Иначе это снова приведет к тому, что код, относящийся к одной функциональности, будет разделен по разным каталогам.



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

Ставь лайк, если любимый релиз - это вечерний пятничный релиз 🍺

В одном из предыдущих постов я писал про упаковку кода.

Хочу ещё обратить внимание на папку utils в проектах.

Ставь 💊 , если в вашем проекте есть папка utils и она похожа на солянку после новогоднего стола.

utils/common/base - набор бессмысленных названий пакетов и модулей, которые открываешь со словами из мема "ЧТО У ВАС ЗДЕСЬ ПРОИСХОДИТ?"

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

Но не нужно бездумно выносить его в "utils", как "нужную" вещь на балкон.

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

Вот пример

❌

utils/
    - Floats.php
    - Integers.php
    - ChunkHelper.php
    - RequestHelper.php
    - Masker.php
    - TimezoneShiftInterface.php
    - UuidUtils.php
    - Pagination.php
    - Config/
        - Parser.php
        - ParseException.php

Декомпозированный вариант, с выделением пакетов по смыслу:

✅

math/
    - FloatOperations.php
    - IntegerOperations.php

  http/
    - CreateRequest.php
    - ErrorHandler.php

  datetime/
    - TimezoneShiftInterface.php

   uuid/
    - UuidFactory.php

  crud/
    - Pagination.php

  config/
    - Parser.php
    - ParseException.php

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

Если у вас был опыт с такой папкой, встречали ли вы две одинаковые функции в ней, написанные разными разработчиками?

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

Tech generation gap

Или старая школа против новой школы


1950-1960

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


1970-1980

70-е принесли C и Pascal, и снова началось: "Слишком много абстракций!" Олды были уверены, что эти языки превратят программирование в детскую игру в конструктор. "Как можно писать код, не зная, что происходит на уровне железа?" — возмущались они. И конечно, все были уверены, что производительность упадёт в пропасть. Знакомо звучит, да?

1990

90-е: на сцену выходят Java и .NET, и С/С++ разработчики хватаются за голову: "Виртуальная машина? Сборщик мусора? Да вы издеваетесь!" По их мнению, garbage collection был костылём для ленивых кодеров, которые не хотят разбираться с управлением памяти. "Настоящие программисты сами освобождают память!" — звучало со всех сторон. История повторялась, только теперь уже C++ разработчики оказались в роли консерваторов.

2000

Нулевые встретили Python, Ruby и PHP громким "фейспалмом" от корифеев: "Интерпретируемые языки? Серьёзно?" Опытные разработчики крутили пальцем у виска: "Какие большие системы? Это же просто игрушки для джунов!" Но мир менялся — open source движение набирало обороты, и молодёжь чувствовала себя в нём как рыба в воде. Старая гвардия, годами строившая закрытые системы, с трудом принимала новую философию разработки, а их богатый опыт внезапно стал казаться менее релевантным.

2010

2010-е принесли мобильную революцию и облака. "Какой еще Swift? React Native? Да на нативном Android/iOS писать надо!" — ворчали опытные разработчики. А молодежь уже вовсю запускала стартапы на AWS и Azure, пока старая гвардия недоверчиво косилась на "эти ваши облака" и продолжала держаться за собственные сервера. "Доверить данные третьей стороне? Да вы с ума сошли!" — и снова история повторялась, теперь уже с новыми технологиями.

2020

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

2022

2022-й принёс нам ChatGPT, и понеслось: "Какой ещё AI-ассистент? Нормальные программисты сами пишут код!" — возмущались опытные разрабы, видя как джуны генерируют целые функции одним промптом. Но пока одни причитали про "деградацию профессии", другие уже вовсю использовали нейронки для рутины и прототипирования. "Это не настоящее программирование!" — кричали хардкорщики, наблюдая как их младшие коллеги решают за час те задачи, на которые раньше уходили дни. И снова знакомая картина: старая гвардия защищает традиционный подход, пока новое поколение осваивает инструменты будущего.


По-любому, лет через 10 мы сами будем те самые олды, которые ворчат на очередную революционную технологию


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

Я не использую LLM, потому что она украдёт мой код


Только этот код никому не нужен, кроме меня/заказчика/работодателя. Заказчику даже нужен не код, а решение проблемы.

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

Код является важной частью бизнеса, особенно в технических компаниях. Но помимо кода, нужно ещё уделять кучу времени на другие вещи. Возьмём аренду квартиры и коммерческих помещений. Представь, я получил код Airbnb. Я готов запустить его уже сегодня и стартовать свою площадку по объявлениям аренды квартир. Это лишь 10%. Нужно подумать о следующем:

1) как привлекать клиентов? Сразу все рванут в аналог Airbnb?
2) как заполучить доверие клиентов?
3) как регулировать юридические вопросы?
4) как регулировать конфликты между арендодателями и арендаторами?
5) как наладить операционные процессы?
6) как выстроить команду разработки, поддержки, маркетинга, продаж, бухгалтерии и т.д.?

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

Поэтому код без продукта не имеет особой ценности.

Вот пару примеров:

Хабр Фриланс - моё мнение, он обрёл популярность, потому что было создано определённое комьюнити вокруг основного продукта - Хабра. Но оказался невыгоден, его закрыли. Сложно ли реализовать такую площадку с точки зрения кода? -- Нет. Простой CRUD на Ларавеле.

Яндекс - слили огромную кодовую базу, такси, маркет, почта, диск, трекер. Был ли взращён на этом новый конкурент? -- Нет. К нам в город заходил DiDi и Ситимобил. Они активно развивались в моём городе, но сейчас я про них уже не слышу. Помог ли им код Яндекса? -- Нет.

Ну и возвращаюсь от размышлений к практичному. Например, я пишу сервис авторизации. Его уже написали миллион и один человек. Витрину в магазине? -- реализация есть в каждом ИМ. Верификация данных -- обычная задача. Куча похожего кода в открытом доступе. LLM ничего не выиграет с моей реализации. После обучения на моём коде, может быть, станет даже хуже решать подобные задачи, извините. 😁😁😁

Провайдеры LLM только и ждут, когда я солью им свою кодовую базу регионального интернет-магазина, реализацию витрины и доски объявлений, или очередную "уникальную" задачу.



Но когда это всё же оправдано, код - это core домен, например:
- алгоритм сжатия данных
- алгоритм шифрования
- алгоритм машинного обучения, разработчики DeepSeek разработали алгоритм для дешёвого обучения моделей, было бы странно, если бы они эту кодовую базу слили в OpenAI, используя ChatGPT.
- военная промышленность
- и т.п.



Короче, никому ваш код не нужен, а вот ассистент ускорит вашу работу в множество раз.

А знаете, в чем парадокс?

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

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

Поэтому внедрение DDD затягивается или не внедряется.

LLM сейчас активно внедряется в разработку, 25% стартапов имеют 95% кода, написанного AI, 60% разработчиков юзают ллм, ттм растет, а время внедрять ддд, обучаться и обучать команду стало ещё меньше. Код генерится быстрее, чем ты успеваешь подумать.

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

Вот такой парадокс, ддд зашел с другой стороны

Чаще всего в проектах встречаю загрузку файлов в S3 через бекенд.

В типичном проекте в прод окружении файл проходит следующие этапы:

frontend -> reverse proxy -> backend -> S3

Если предполагается часто используемый функционал с загрузкой файлов, то это решение может стать узким горлышком. Особенно если речь заходит о больших файлах. В такой конфигурации большой latency за счет большого кол-во узлов, через которые проходит файл, сюда может добавить API Gateway, например, KrakenD или kong. Если проект на php-fpm - может забиться пул. И в целом приложение начинает потреблять больше ресурсов инфры

Этот подход называется Backend File Uploads.



Есть и второй -- Frontend File Uploads

В этом подходе, загрузка файлов происходит с фронта напрямую в S3 bucket. А для достижения безопасности используется Presigned Url (подписанная ссылка).

В этом подходе файл загружается в два этапа:
1) получение подписанной ссылки на бекенде
2) загрузка в S3 по подписанной ссылке


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

- производительность и масштабируемость -- это и увеличение пропускной способности и снижение потребления ресурсов инфры

- снижение latency -- файл проходит меньшее кол-во узлов

- открывается возможность загружать файлы до 5 ТБ

- скорость загрузки ограничивается клиентом и сервером S3. В backend upload нужно учитывать сетевые задержки + ограничение скорости между узлами в зависимости от их сети. Например, провайдер выделяет только 100 МБит/с



Реализацию можно поизучать в opensource, например, как в outline/outline загружаются прикрепляемые к документу файлы

https://github.com/outline/outline/blob/0d1c8490b5ffd0823a1f9ae7c5fa3438ed112eee/server/routes/api/attachments/attachments.ts#L137

Наткнулся на классное объяснение как устроен Claude Code , но по факту это про то, как работает любая агентская система

https://github.com/shareAI-lab/learn-claude-code