Рубрика: engineering-practices

Большинство разработчиков действительно начинают с фреймворков: учат синтаксис, привыкают к API библиотек, собирают первые рабочие приложения. Это нормальный и полезный старт. Но довольно быстро становится видно ограничение такого подхода: знания о Laravel, Vue.js, React, Django или любом другом инструменте сами по себе не гарантируют, что вы сможете собрать устойчивый продукт, который не рассыплется через несколько месяцев активной разработки.

На практике возникают вопросы, на которые документация фреймворка отвечает лишь частично или не отвечает вовсе: как организовать код так, чтобы его можно было без боли менять через полгода? Почему приложение начинает деградировать под нагрузкой, хотя локально […]

Когда я только входил в разработку, все выглядело довольно прямолинейно: пройти курс по PHP, разобраться с Laravel, собрать пару CRUD-приложений — и можно идти искать работу. На старте кажется, что этого достаточно. Но реальный проект очень быстро расставляет акценты по местам. Выясняется, что знание синтаксиса и базовых возможностей фреймворка — это лишь часть профессии, и далеко не самая сложная. Остальное приходит через разбор чужого кода, неочевидные баги, спорные архитектурные решения, code review и попытки понять, почему «вроде рабочий» код через полгода становится дорогим в поддержке.

Когда помогаешь разработчикам расти дальше junior-уровня, одна закономерность бросается в глаза […]

Когда разработчик берётся за новый язык или фреймворк, фокус почти всегда один и тот же: синтаксис, базовые конструкции, типовые CRUD-задачи, несколько учебных примеров. Это нормальная точка входа. Проблема в другом: на реальных проектах сложности почти никогда не возникают из-за того, что кто-то забыл синтаксис PHP, JavaScript или не до конца выучил API фреймворка. Куда чаще всё ломается на уровне архитектуры, границ ответственности, тестируемости, качества изменений и командной коммуникации.

За годы работы с коммерческими продуктами это наблюдение только подтверждалось. Разница между разработчиком, который просто умеет написать «работающий код», и инженером, который собирает систему, […]

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

На практике безопасность не живёт отдельно от разработки. Она связана с архитектурой приложения, с тем, как вы работаете с входными данными, как проектируете авторизацию, как настраиваете деплой и как поддерживаете зависимости. Если не заложить базовые меры сразу, позже почти неизбежно придётся возвращаться […]

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

Если говорить по-простому, наблюдаемость — это способ не гадать, а видеть. Не искать проблему вручную по ssh на сервере и не читать десятки несвязанных строк в логах, а иметь минимальную, […]