Как я думаю об инженерии
Я не строю «фичи» — я строю системы. Разница важна. Фича живёт до следующего спринта. Система живёт годами и продолжает работать, когда автора уже нет в компании.
Это означает: прежде чем писать код, я задаю неудобные вопросы. Почему именно так? Что произойдёт при нагрузке × 10? Кто будет это поддерживать через три года? Правильный дизайн на раннем этапе стоит дешевле, чем рефакторинг в продакшне.
Что я делаю
Более пяти лет разрабатываю бэкенд-системы на PHP и Laravel — от API для мобильных приложений до высоконагруженных веб-сервисов.
Сейчас в one.pix занимаюсь бэкендом и архитектурой API. В работе — сложная бизнес-логика, очереди, интеграции (включая Netsuite), Docker-окружения, CI/CD и администрирование Linux-серверов.
Специализируюсь на:
- Архитектуре бэкенда — проектирование REST API, сложная бизнес-логика, интеграции
- Производительности — оптимизация запросов, кэширование, очереди, рефакторинг legacy
- Инфраструктуре — Docker, CI/CD, Nginx, AWS, Linux
- Фронтенде — периодически закрываю задачи на Vue.js
Как я подхожу к задачам
Сначала понимаю, потом пишу. Большинство технических проблем — это на самом деле проблемы с пониманием домена или требований. Я трачу время на то, чтобы разобраться в сути, а не прыгать к решению.
Я предпочитаю скучный, предсказуемый код интересному. Clever code — это технический долг с отложенным платежом. Простое решение, которое легко читать, дебажить и расширять — лучший выбор почти всегда.
Тесты — это не опция. Код без тестов — это код, в котором нельзя быть уверенным. Я пишу тесты не для галочки, а чтобы иметь уверенность при изменениях.
Что меня мотивирует
Сложные задачи с высоким давлением на correctness. Системы, где ошибка стоит дорого — платёжные процессинги, логистика, финансовые расчёты. Там нет места для «должно работать» — только для «работает».
Мне нравится работать в командах, где код-ревью — это обмен знаниями, а не формальность. Где junior задаёт вопрос «почему?» и получает нормальный ответ, а не «так принято».