OpenCart/Laravel Blog

Хочу рассказать вам о принципах GRASP. Это набор принципов, которые помогают правильно распределять ответственность между объектами и классами в объектно-ориентированном коде.

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

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

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

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

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

Но здесь возникает другая проблема.

Сложную архитектуру не всегда удобно описывать только текстом.

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

Идея очень простая: Opus используется для планирования, а Sonnet — для выполнения уже готового плана. Причём переключение происходит автоматически.

Именно такая схема кажется мне наиболее логичной.

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

Один из таких паттернов — Active Record.

Последнее время я довольно активно изучаю паттерны проектирования и архитектуру приложений. И чем больше в это погружаюсь, тем чаще встречаю два понятия, которые лежат где-то в основе практически всего — coupling и cohesion.

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

Последние годы я в основном работал с MySQL. PostgreSQL периодически встречался, но особой необходимости глубоко в него погружаться не было.

Ситуация изменилась, когда появился новый проект — AI-ассистент. Для него мне понадобились PostgreSQL, JSONB, Full-Text Search и, самое главное, pgvector для векторного поиска.

И вот после нескольких недель более плотного знакомства с PostgreSQL я понял, что это не просто «ещё одна SQL-база, почти такая же, как MySQL».

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

В последнее время начать немного изучать Python. Это на сегодня очень популярный язык программирования, входит в тройку наиболее популярных языков и по количеству вопросов на разных сайтах типа стековерфолоу и по коллчичеству репозиториев на гитхабе.

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

Заинтересовался темой телеграмм ботов.
Написал свой первый телеграм бот с использованием PHP, Laravel и Telegram Bot SDK