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

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

Привет, Хабр!

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

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

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

Но это в теории. А что на практике? Рассмотрим под катом.

Привет! Меня зовут Олег Мифле. В Skyeng работаю над проектом Skypro. В IT я уже больше десяти лет, семь из которых пишу на PHP. За плечами десятки разных проектов: e-commerce, финтех, CRM, а недавно добавился и EdTech. Были и классические фуллстек-проекты, и проекты, где фронтенд и бэкенд «живут» отдельно и коммуницируют друг с другом по API. Боль от отсутствия версионирования я испытал на себе. Хочу поделиться, как избежать проблем, как всё структурировать и организовать.

Обсудим:

• Что такое API.

• Зачем версионировать API и нужно ли вообще.

• Какие способы версионирования существуют и как его организовать — и с точки зрения подходов, и с точки зрения кода.

• Разберёмся, когда избавляться от старой версии или как жить с легаси до конца существования проекта.

Эта статья представляет собой краткий (шутка!) конспект одноименного (почти) вебинара, недавно проведенного автором.

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

Ну и немного раскрыть глаза на то, что, оказывается в PHP есть и асинхронность, и многопоточность, и в общем-то не нужно ждать мифической версии PHP 10, чтобы начать их использовать уже прямо сейчас!

В последнее время в новостях все чаще и чаще упоминаются L-слои блокчейна (например, инвестиционный фонд A16z вкладывается в L2 решение на Ethereum Optimism или L3 компания Orbs расширяет свое решение на блокчейн TON).

Концепция слоев — это категоризация блокчейнов, необходимая для быстрого понимания как тот или иной проект вписывается в экосистему в целом. В этой статье мы разберем что такое слои L0, L1, L2 и L3, зачем они нужны и рассмотрим примеры.

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

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

TL; DR: JSONB может значительно упростить разработку схемы БД без ущерба производительности в запросах.

Введение

Соблазн использовать модель EAV (Entity-Attribute-Value) при организации структуры БД весьма велик, особенно когда предметная область заранее плохо известна (или разработчик просто не хочет в нее углубляться). Это ведь так удобно - создать "универсальный" способ описания характеристик объектов, который больше не потребует доработок базы ни при появлении новых типов объектов, ни при возникновении новых атрибутов...

Однако, за любую универсальность приходится платить сложностью и производительностью запросов - так что json[b] может оказаться более эффективной заменой. Но если уж такая модификация невозможна - давайте попробуем выжать максимум производительности из доставшегося нам legacy на самом простом примере.

Проектирование своего проекта по DDD последнее время становится всё более популярным. Сейчас не будем углубляться в данную методологию с её принципами, плюсами и минусами. Я хочу рассказать с какой проблемой столкнулась наша команда при использовании данной методологии на PHP, а именно внедрении Data Mapper’а Doctrine ORM.

Чтобы более понятно донести нашу проблему я буду использовать известный всем Агрегат Заказа (Order) и позиции заказа (OrderLine), которые являются коллекциями Dortrine ORM. Так же сильно упростим данный агрегат, чтобы фокусироваться на самой проблеме. И так начинаем!

Для начала мы создадим наш агрегат заказа.

TL;DR

Эта статья является переводом материала «Cohesion and Coupling: the difference». 

Возможно, вы слышали рекомендацию, в которой говорится, что мы должны стремиться к достижению low coupling (низкой связанности) и high cohesion (высокого сцепления) при работе над кодовой базой. В этой статье хотелось бы обсудить, что на самом деле означает эта рекомендация, и взглянуть на некоторые примеры кода, иллюстрирующие ее. И также хочется провести границу между этими двумя идеями и показать различия в них.

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