Веб Мастерская | Веб разработка и программирование | ИТ | IT

КЕЙС:

Коллеги, небольшой клиент попросил внутреннюю CRM: клиенты, задачи, статусы, пара отчётов. Бюджет скромный, срок — две недели.

Стажёр предлагает: «Давайте честный MVC: роуты, контроллеры, модели, middleware, валидация, слои!» Звучит солидно. Но я посчитал: 15 сущностей, 3 экрана, 1 роль. Если строить дворец, не успеваем.

Выбрал классическое ООП: аккуратные классы, простые сервисы, тонкий слой БД. Без фреймворочной магии.


Что сделали:

— Client, Task, Status как сущности;
— ClientService и TaskService для логики;
— один входной файл с простым роутингом, PDO-обёртку и минимум зависимостей.


Почему это быстрее:

— меньше слоёв — меньше кода, который надо писать и отлаживать;
— не нужно спорить о «правильном» разделении ответственности там, где задача на один метод;
— правку в продакшене можно найти за 5 минут, а не блуждать по папкам.


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

Спустя месяц клиент попросил экспорт в Excel. Добавили один метод в сервис и простой шаблон, а не переписывали половину проекта.

Важно: я не против паттернов. Для большого проекта с командой, ролями, API и сложными сценариями слои оправданы. Но для маленькой внутренней системы классическое ООП часто выигрывает у «архитектуры ради архитектуры».

Совет: выбирайте сложность под масштаб задачи. Лучше скучный рабочий код, чем красивый, но не сданный в срок.

Вот так. Идем кодить дальше! 🚀

ДАЙДЖЕСТ НОВОСТЕЙ:

Привет, коллеги! 👋 Пока одни паникуют из-за ИИ, мы с вами как всегда спокойно пилим проекты. Но следить за индустрией надо, поэтому я собрал для вас топ-5 новостей веб-разработки за эту неделю.

🚨 Срочный патч для Next.js и React!
Vercel выкатили внеочередное обновление безопасности, закрыв критические уязвимости в Next.js и React. Если у вас или ваших клиентов висят проекты на этом стеке, бегом обновляйтесь. Безопасность — это не шутки, коллеги.

🚀 Bun 1.4.3 залетел в прод!
Вышел новый релиз Bun 1.4.3, который снова хвастается космической скоростью установки пакетов. Если вы еще не пробовали заменить npm на Bun в своих пет-проектах или на фрилансе — самое время. Сэкономите кучу времени при CI/CD.

🎨 CSS и HTML в 2026 году
В нативном вебе активно закрепляются View Transitions, API Popover и Anchor Positioning. Это значит, что сложные попапы и плавные переходы между страницами теперь можно делать без тонны JavaScript. Фронтендерам на заметку — код станет чище, а клиенты будут в восторге!

🛠 Обновление Chrome DevTools
В Chrome DevTools добавили поддержку soft navigation в разделе Performance и улучшили работу с MCP-серверами. Теперь отлавливать просадки FPS и следить за производительностью SPA-приложений стало еще удобнее.

📝 WordPress 7.2 уже на подходе
Для тех, кто делает сайты для малого бизнеса: Beta 1 версии 7.2 выходит 20 октября. Это финальный крупный релиз года, так что готовимся обновлять клиентские сайты и тестировать новые фишки.

Какую из этих технологий вы уже щупаете в своих проектах? Делитесь в комментах! 👇

Вот так. Идем кодить дальше! 🚀

ФАКТЫ И ЦИФРЫ:

Сколько сайтов уже на HTTPS в 2026?

Коллеги, давайте без лирики — только цифры, которые заставляют задуматься.

По данным на осень 2026 года:

🔒 ~96–97% страниц, загружаемых в Chrome и Firefox, отдаются по HTTPS. Три года назад было 91%. Прогресс есть, но он замедлился.

🌐 Если смотреть на все зарегистрированные домены (включая заброшенные блоги 2014 года и лендинги, которые «потом доделаю»), картина скромнее — порядка 84–87%. То есть каждый 7-й сайт в интернете до сих пор встречает посетителя надписью «Не защищено».

📱 В мобильном трафике доля HTTPS ещё выше — ~98%, потому что браузеры на смартфонах просто пессимизируют и блокируют mixed-content агрессивнее.

🏢 Среди топ-10 000 сайтов мира — 99,2%. Тут без вариантов: нет сертификата — нет тебя в выдаче, нет в рекламных сетях, нет в доверии пользователя.


А теперь практический вывод, коллеги:

Если вы делаете сайт для малого бизнеса и клиент говорит «да ладно, у нас же не банк, зачем SSL» — покажите ему эти цифры. В 2026 году сайт без HTTPS — это как вывеска «Мы не заботимся о ваших данных». Конверсия падает на 12–18% просто из-за красного замка в адресной строке.

И да, бесплатный Let's Encrypt никто не отменял. Настройка — 15 минут. Автопродление — одна строчка в cron. Отмазка «дорого и сложно» умерла ещё в 2019-м.

Проверьте свои проекты сегодня. Особенно те, что «на поддержке с прошлого года». Один curl -I https://ваш-домен — и сразу видно, не протух ли сертификат.

Вот так. Идем кодить дальше! 🚀

ИЗ ПРОФЕССИИ:

Как задавать правильные вопросы на код-ревью

Коллеги, давайте честно: код-ревью у многих вызывает либо панику («сейчас меня разнесут»), либо скуку («опять формальность»). А всё потому, что мы не умеем задавать вопросы. Не отвечать на них — а именно задавать.


Из мастерской. Вот что реально работает:

❌ «Почему ты так написал?». Звучит как допрос. Собеседник сразу уходит в оборону.

✅ «Вижу, тут выбран подход X. Расскажи, почему не Y? Хочу понять контекст, вдруг я что-то упустил.». Вы не нападаете — вы учитесь. И даёте человеку пространство объяснить.

❌ «Это неправильно.». Точка. Без аргумента. Без альтернативы. Просто приговор.

✅ «А что будет, если сюда придёт null / пустой массив / юзер без токена? Давай разберём кейс.». Конкретный сценарий вместо абстрактного «неправильно».


Три правила, которые я вбил себе в голову за годы в продакшене:

1️⃣ Вопрос > Утверждение. «Может, здесь лучше вынести в хук?» работает в сто раз лучше, чем «Вынеси в хук». Вы предлагаете диалог, а не приказ.

2️⃣ Спрашивайте про «почему», а не про «что». Код вы видите сами. А вот контекст решения — нет. «Почему тут не useMemo? Есть причина?» — и вам ответят: «Да, ререндер тут дешевле, чем мемоизация». И вы станете чуть умнее.

3️⃣ Не копите вопросы в один комментарий-простыню. Лучше три коротких треда по делу, чем стена текста на 40 пунктов. Человеку физически тяжело это разгребать.

Бонус для джунов: не бойтесь спрашивать «глупое». Серьёзно. Я на ревью спрашивал, зачем нужен key в React-списке, хотя «уже должен был знать». И мне объяснили нюанс с реконсиляцией, которого нет ни в одном учебнике.

Код-ревью — это не экзамен. Это парное программирование, растянутое во времени. И чем лучше ваши вопросы, тем быстрее растёт вся команда.

Вот так. Идем кодить дальше! 🚀

БАЗА:

Тег <picture> и srcset: отдаём правильные картинки разным экранам

Коллеги, признавайтесь: кто до сих пор грузит один и тот же баннер 2560px и на десктоп, и на мобилку? 😅 А потом пользователь на 4G ждёт 8 секунд, пока страница «прогрузится». Знакомо?

Сегодня разберём два инструмента, которые решают эту боль раз и навсегда.


srcset — «выбери сам»

Когда у вас одна и та же картинка, но в разных размерах:

<img src="hero-800.jpg"
srcset="hero-400.jpg 400w,
hero-800.jpg 800w,
hero-1600.jpg 1600w"
sizes="(max-width: 600px) 100vw, 50vw"
alt="Наш крутой проект"
>

Браузер сам смотрит на ширину экрана, плотность пикселей и выбирает оптимальный файл. Вы не управляете выбором напрямую — просто даёте варианты.


<picture> — «я решаю»

Когда нужна другая картинка для другого экрана (арт-дирекшн):

<picture>
<source
media="(min-width: 1024px)"
srcset="hero-desktop.webp"
type="image/webp">

<source
media="(min-width: 1024px)"
srcset="hero-desktop.jpg">

<source
srcset="hero-mobile.webp"
type="image/webp">

<img src="hero-mobile.jpg" alt="Проект">
</picture>

Здесь вы жёстко говорите: «на десктопе — одна, на мобилке — другая». Тег <img> внутри обязателен — это фолбэк для старых браузеров.


Когда что юзать:

→ srcset — одна картинка, разные размеры (оптимизация веса)
→ <picture> — разные кропы, форматы или вообще другие изображения под брейкпоинты


Из продакшена:

— Всегда указывайте width и height у <img>, чтобы не было скачков макета (CLS скажет спасибо)
— Формат WebP/AVIF через type в <source> — экономия 25–50% без потери качества
— Ленивая загрузка: loading="lazy" для всего, что ниже первого экрана

Коллеги, адаптивные картинки — это не «плюшка», а гигиена. Пользователь на бюджетном смартфоне не должен качать ваш 4K-хиро.

Вот так. Идём кодить дальше! 🚀

SEO:

Тонкости атрибута rel="canonical"

Коллеги, знакомая боль: пишешь годный контент, а в выдаче Google — тишина. А потом открываешь Search Console и видишь 300 «дублирующихся страниц без указанной пользователем канонической». Знакомо? Добро пожаловать в мир canonical 👇


Что это вообще такое?

<link rel="canonical" href="..."> — это шёпот поисковику: «Эй, оригинал вот тут, а остальное — копии, не распыляй вес». Простыми словами — страховка от дублей.


Кейс из мастерской

Делали редизайн интернет-магазину автозапчастей. Трафик упал на 40% после переезда. Причина? UTM-метки из рекламных кампаний плодили тысячи дублей вида ?utmsource=yandex&utmmedium=cpc.... Робот индексировал каждую. Поставили canonical на чистый URL — через 3 недели позиции вернулись, а вес сконцентрировался на нужных карточках.


5 тонкостей, о которых молчат учебники:

1️⃣ Самоссылающийся canonical — ставь даже на оригинальной странице. Это защита от паразитных параметров.

2️⃣ Пагинация ≠ главная. site.ru/blog?page=1 не должен каноникалиться на site.ru/blog/ — это разные интенты.

3️⃣ HTTPS и www. canonical должен указывать на ту версию, которую ты считаешь основной. Иначе权重 теряется.

4️⃣ Не путай с 301! Canonical — это «покажи, но учитывай оригинал». 301 — это «навсегда переехали». Для устаревших страниц — только редирект.

5️⃣ Кросс-доменный canonical работает, если ты syndicating контент на партнёрские сайты. Укажи источник — и вес останется у тебя.

Лучше генерировать чистый URL без query-параметров — так надёжнее.

⚠️ Фатальная ошибка: canonical, указывающий на 404 или заблокированную в robots.txt страницу. Поисковик это проигнорирует и решит сам. А его решения нам редко нравятся 😅

Проверяй свой сайт прямо сейчас: site:твой-домен.ru в Google — если выдача пестрит URL с параметрами, пора чинить.

Вот так. Идем кодить дальше! 🚀