Всё о разработке | Леонид Ченский

⌨️ «вайбкодинг-вайбкодинг-вайбкодинг»

В последнее время из каждого угла слышно о «вайбкодинге» и о том, как любой может легко создать приложение или сайт с нуля.

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

Давайте будем говорить начистоту, если бы разработка ПО была бы таким легким делом, не требовалось бы столько разработчиков на рынке, а их зарплаты не были бы такими какие они есть.

Да, нейронки сейчас хорошо обучены и могу решать конкретные задачи по образу и подобию того, что они уже знают. Да, можно навайбкодить какой-то прототип сайта или MVP приложения, при этом совершенно не зная языка программирования и не имея опыта в разработке (хотя и это не совсем правда). Однако этот прототип потом вряд ли сможет конкурировать с реальными приложениями без привлечения настоящих экспертов.

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

Это значит что, чтобы навайбкодить приложение, которое бы по качеству и объему кодовой базы было такое же, как настоящее Enterprise решение, потребуется не один ИИ агент на компьютере. Для такой задачи потребуется огромная команда из тысячи ИИ агентов, которые между собой будут постоянно коммуницировать, должны быть агенты координаторы, архитекторы, валидаторы и интеграторы (все прям как сейчас у людей в больших компаниях:)). В общем, чтобы вайбкодинг смог заметить разработчиков, нужно обзавестись огромными вычислительными мощностями, которых у человечества пока нет.

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

На мой взгляд ИИ позволяет оптимизировать и ускорить работу инженеров, а также расширить горизонт возможностей. Я думаю, что нейронки приведут к тому, что сильные инженеры и разработчики (имеющий реальный опыт) станут еще более продвинутыми и ценными на рынке, а вот джунам и людям без опыта наврятли получится сильно прокачаться, ведь таких как они будет много, а задач уже не будет… Получается, что порог входа в IT вырастет, а дефицита кадров больше не будет.

А что вы думаете о вайбкодинге?

ПРОРЫВ В ОБЛАСТИ ПРОТОКОЛОВ КОНСЕНСУСА

На днях узнал о шокирующей новости — появлении ACID транзакций в Apache Cassandra (в распределенной leaderless базе КАРЛ!)

Да да, случилась по-сути революция в Computer Science: то что еще недавно считалось невозможным иметь строгие и быстрые распредленные транзакции в leaderless базах данных, теперь — реальность!

За счет чего такой прорыв?

Умные инженеры (видимо еще и очень упорные) в Apple при содействии Университета Мичигана, решили бросить вызов одной из самых сложных проблем в индустрии — быстрые транзакции в leaderless-архитектурах, и разработали новый протокол консенсуса ACCORD.

Accord — это первый практичный протокол, который одновременно дает: - 🤯 Strict-Serializable Consistency: Serializable и Linearizable (подробнее про модели согласованности) - 🧠 Leaderless: Отсутствие глобального лидера - 🚀Устойчивый к Contention: конкурирующие транзакции не приводят к гарантированному slow-path (за счет reorder buffer) - ⚡️Согласование ВСЕГО ЗА 1 ROUND TRIP в оптимистичном сценарии и за 2 Round Trip при конфликтах - ⚛️ Может работать на произвольных multi-key / multi-shard транзакций (ваши ключи могут быть в разных партициях и даже таблицах, и при этом вы можете атомарно их обновить)

Что это дает?

Этот протокол дает современным БД возможность быть одновременно масштабируемыми, быстрыми и транзакционными — без лидеров, без компромиссов и без атомных часов. Это кардинально меняет целый класс AP-систем — таких как Cassandra (а в перспективе, вероятно, и другие базы данных начнут интегрировать Accord). Уверен, что в ближайшие пять лет мы увидим массовый переход компаний на подобные решения, и это станет новым технологическим трендом.

Уже в следующей версии Cassandra должны добавить поддержку транзакций. Классическая задача резервации стоков теперь будет решаема на Cassandra: BEGIN TRANSACTION // Find out how many PlayStations are left LET inventory = (SELECT inventory_count FROM ks.products WHERE item = 'Play Station 5'); // Return the inventory_count SELECT item, inventory_count FROM ks.products WHERE item = 'Play Station 5'; // Take a PlayStation out of inventory and put it in users shopping cart IF inventory.inventory_count > 0 THEN UPDATE ks.products SET inventory_count -= 1 WHERE item = 'Play Station 5'; INSERT INTO ks.shopping_cart(user_name, item, item_count) VALUES ('leo', 'Play Station 5', 1); END IF COMMIT TRANSACTION;

Найм в IT требует реформ

Всё чаще замечаю, что текущая система отбора кандидатов и проведения собеседований разработчиков не работает — или работает исключительно по теории вероятности!

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

Бывает и так, что кандидат — отличный «книжный эксперт»: натренированный на собеседованиях (в лучшем случае, а в худшем — благодаря ChatGPT), он блестяще проходит интервью и выглядит увереннее остальных. А потом выходит на работу и… решения получаются с багами или просто черновыми, задачи задерживаются, требуется постоянный контроль за разработчиком и валидация его решений.

Про отбор резюме на уровне HR молчу — это отдельная проблема индустрии. От части это и вина самих разработчиков: резюме нужно уметь составлять грамотно (отдельный вид искусства так сказать). Всё осложняется тем, что в больших компаниях есть «задачники», куда какие-то эксперты когда-то занесли «оригинальные» вопросы, и теперь всех гоняют по ним, как на экзамене. Но главный вопрос — на что они нацелены? Создают ли эти вопросы нужную воронку? Возможно, раньше так и было, но сейчас… сейчас нужно что-то новое.

Знаю, что в последнее время некоторые руководители практикуют очные собеседования (дабы ChatGPT не смог помочь), но, к сожалению, это не всегда возможно. А что остаётся? Возможно, стоит просматривать GitHub кандидата? — так не все туда что-то дельное пушат. Может быть, тогда live-кодинг реальных задач? — одного часа может и не хватить. Или техническое тестовое задание из доменной области «на дом» со сроком выполнения? (Однажды я выполнял такое задание — было интересно: смог поработать с CGO и TCP-протоколом на низком уровне. Правда, фидбэк по выполнению так и не получил…)

Я пока нахожусь в поиске лучших вопросов и задач, которые нацелены на проверку именно нужных компетенций.

Были ли у вас интересные, необычные задачи или вопросы на собеседовании, которые вам запомнились?

Go 2025: главное из исследования DevCrowd

1. Почти половина Go-разработчиков уже используют AI в работе.

В этом плане я отстаю от большинства: я все еще не настроил в IDE нормального AI ассистента...

2. Многие совмещают Go с Python, но не собираются уходить с Go.

Сам грешу python-ом частенько) На мой взгляд после разработки на Go у человека меняется подход к написанию кода на python: код становится чище и понятнее. Никто не замечал за собой?

3. Большинство сообщества — мидлы и сеньоры, джунов почти нет.

Зрелое комьюнити, это радует🥲

🔗 Исследование Go-разработчиков 2025 от DevCrowd

🔥 На этой неделе было жарко — и не только из-за погоды.

Мне досталась задача с категорией «что это вообще такое?» — реализовать аутентификацию в БД через JWT. Да-да, не в backend-приложении, а прямо в базу данных. ⠀ На первый взгляд — странная идея. На второй — всё ещё странная. Но раз надо, значит, разберёмся.

Первая остановка — знакомство с CQL и SASL. Сначала всё выглядело как очередная боль с патчами в движок БД. Но потом пришла гениальная здравая мысль: «А может, не будем трогать исходники БД, а обойдёмся встроенным механизмом saslauthd + pam?» ⠀ Почему бы и нет. Чтобы быстро проверить гипотезу, накидал мини-сервер на Python, который выступает в роли PAM-скрипта. Почему Python? Потому что не надо компилировать, править и деплоить, когда нужно ковыряться в auth flow прямо на тачке, скорость важнее всего.

На бумаге всё работало. В реальности — нет. Документация уверяла, что всё ок. Но мы же с вами знаем: лучшая документация — это исходный код. ⠀ Погружаюсь в C++ код БД — и, неожиданно, кайфую. Там тебе и coroutines, и lambda, и futures, и promises, и iterators. Весь код на C++23 как он есть. После Go, где всё прямолинейно, минималистично и «пресно», это было как попасть в пряничный домик. Уровень сахара подскочил до предельного уровня, частота пульса подскочила. Еще пару дней придется отходить…

Увы, выяснилось, что в моей версии БД нужного функционала просто нет — поддержка saslauthd появилась позже. Собираем образ с нужной версией. Через ONE HOUR LATER я вспоминаю, почему не скучаю по C++: сборка проекта — это медитация, но против воли. ⠀ Обновил базу. Начинается весёлый блок под названием «танцы с бубном вокруг saslauthd и pam». Попытка номер ∞, и наконец — успех. Скрипт принимает тестовый admin/admin — можно жить!

Теперь самое интересное: пробуем отправить JWT. И… ничего! Ошибка! Даже не ошибка — тишина. В логах — пусто. Скрипт даже не вызвался. ⠀ Значит, где-то на пути client → DB → saslauthd → pam → мой скрипт что-то сломалось. Подозрение на длину токена.

Лезу в код БД — там всё ок, длина пароля кодируется 2 байтами, ограничений на буфер жестких нет, можно пихать токены хоть длиной 65536. Лезу глубже — в исходники saslauthd (да-да, снова та самая документация). И вот он, убийца надежды: #define MAX_BUF_LEN 256 🙃 Да, кто ж в 2000-х думал, что кто-то будет пихать в пароль пару килобайт JSONа. Протокол может, а реализация — нет.

Ладно, значит, пишем свой saslauthd. Снова Python, снова быстрая проверка. И... ура! Всё работает! Теперь можно коннектиться к БД с JWT в 2025 году. Без хаков, без патчей. Просто красиво.

Осталось дело за малым: переписать всё на Go, для скорости, стабильности и душевного спокойствия перформанса. Но это уже не сегодня…

Итого, за неделю удалось потрогать Python и Go, вспомнить C и С++, поперекладывать байтики и доказать работоспособность идеи.

А у вас как неделя прошла? Были задачки на стыке "невозможно" и "ну попробуем"?

ИЗЯЩНАЯ РАБОТА С ОШИБКАМИ В GO, ИЛИ КАК ИХ СРАВНИВАТЬ

Обычное err == myErr в Go работает не всегда так, как ты ожидаешь. Особенно если ты оборачиваешь ошибку через fmt.Errorf("context: %w", err). В таких случаях Go предоставляет более мощные инструменты — errors.Is и errors.As.

❓Как работает errors.Is

Когда ты используешь %w в fmt.Errorf (врапинг ошибки), ты как бы упаковываешь одну ошибку внутрь другой, добавляя контекст. errors.Is умеет разворачивать такие обёртки и проверять, есть ли внутри нужная ошибка:

var ErrNotFound = errors.New("not found") err := fmt.Errorf("ошибка в поиске: %w", ErrNotFound)

if errors.Is(err, ErrNotFound) { fmt.Println("Ничего не найдено") }

Под капотом errors.Is делает так: если ошибка обёрнута через %w, она вызывает Unwrap() и идёт по цепочке, пока не найдёт нужную. Если ты просто сравнишь err == ErrNotFound, то получишь false, потому что это уже не тот же объект — он обёрнут.

❓А что делает errors.As

Иногда нужно не просто узнать, была ли ошибка определённого типа, но и получить доступ к её полям. Например: type MyError struct { Code int Msg string }

func (e *MyError) Error() string { return fmt.Sprintf("code: %d, msg: %s", e.Code, e.Msg) }

err := &MyError{Code: 499, Msg: "custom"} var myErr *MyError

if errors.As(err, &myErr) { fmt.Println("У нас ошибка кода", myErr.Code) }

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

❓Как кастомизировать сравнение — метод Is()

Ты даже можешь сам определить, когда твоя ошибка считается «равной» другой. Для этого нужно реализовать метод Is(target error) в своей реализации: type HttpError struct { Code int Msg string }

func (e *HttpError) Error() string { return fmt.Sprintf("HTTP %d: %s", e.Code, e.Msg) }

func (e *HttpError) Is(target error) bool { t, ok := target.(*HttpError) return ok && e.Code == t.Code }

Теперь, даже если сообщения об ошибках разные, но коды совпадают — errors.Is вернёт true: var Err404 = &HttpError{Code: 404} err := fmt.Errorf("обёрнутая ошибка: %w", &HttpError{Code: 404, Msg: "page not found"})

if errors.Is(err, Err404) { fmt.Println("Обнаружена 404") }

❓Когда и где это реально нужно (примеры из практики)

— В библиотеках: ты возвращаешь ошибки вроде ErrInvalidConfig или ErrNotConnected, и хочешь, чтобы пользователи могли их отловить независимо от контекста

— В сервисах: API может возвращать ошибки с кодами, а внутри тебе удобно описывать их кастомными типами — и потом ловить их по errors.Is

— В middleware: например, хочешь логировать всё, кроме ErrUnauthorized — тогда errors.Is(err, ErrUnauthorized) спасёт от лишнего шума

— В gRPC/HTTP-хендлерах: удобно классифицировать ошибки и автоматически подставлять нужный статус код в ответе

— В CLI-инструментах: логика выхода с кодами ошибок может зависеть от типа ошибки, а не только от текста

Если ты до сих пор сравниваешь ошибки через ==, самое время освоить errors.Is и errors.As. Это делает твой код гибким, читаемым и гораздо ближе к надёжной архитектуре. Go даёт тебе все инструменты — просто используй их.

Больше примеров работы с ошибками даю в бесплатном уроке на своем курсе Go!

P.S. все еще действует промокод на скидку 30% - FEIN

ПРО АЛГОРИТМЫ НА СОБЕСЕДОВАНИЕ

Раньше я искренне не понимал, зачем некоторые IT‑компании так помешаны на алгоритмах.

Казалось, на реальных проектах алгоритмические задачи почти не встречаются, и фронт‑ и бэкенд‑разработка сводится к знанию фреймворков, «перекладыванию JSON-чиков» и API. Однако за несколько лет участия в десятках собеседований и после собственного опыта в разработке я убедился: алгоритмы — это самый надёжный способ оценить не только знание синтаксиса, но и скорость разработки и качество мышления на собеседовании. Все остальное можно заучить и «натаскаться» проходя собеседования.

Личный пример. В начале карьеры я мог быстро писать CRUD на знакомом фреймворке, но на реальную задачу уходило по несколько дней: то упирался в нестандартный кейс, то долго выстраивал логику, код писал не быстро. После целенаправленного изучения алгоритмов и регулярной практики на LeetCode время на решение типичных задач сократилось в разы: я просто «видел» шаблон и быстро его имплементировал.

Почему это не прихоть компаний Алгоритмические задачи — это как игра на фортепиано: профессионал, играющий разные жанры и виртуозно владеющий инструментом, способен «прочувствовать» любую мелодию и сразу попасть в нужный темп и тон. Так же и разработчик, хорошо натренировавший алгоритмическое мышление, в коде «чувствует» структуру задачи и без лишних проб и ошибок строит оптимальное решение. А скорость выполнения задач - очень важный показатель. Можно выучить и зазубрить любую теорию: computer science, устройство языка, SQL и NoSQL, брокеры сообщений. Но алгоритмы - это тот навык, который прививается со временем.

Конечно, перегибать палку не стоит: несколько тяжелейших секций на графах и динамическом программировании, далеких от повседневных задач, часто лишь валят кандидатов и отнимают время (возможно это тактичный способ слить кандидата). Главное, что дают алгоритмы — шаблоны мышления и «насмотренность», благодаря которым вы почти на автопилоте пишете чистый, понятный и эффективный код.

Пишите в комментариях, практикуете ли вы алгоритмические задачи, и если да, видите ли у себя прогресс в скорости разработки?

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

Пока я как и вы на знаю во что это выльется. Буду активно следить за трендами и рассказывать вам о них.

Каждый второй go разработчик использует ChatGPT в своей работе согласно опросу dewcrowd.ru.

Интересная статистика, конечно, помогает понять основной тренд в индустрии.

Советую ознакомиться 🙂