Качество кода *

Когда я в прошлом году услышал, что дядя Боб планирует выпустить вторую редакцию «Чистого кода», то был восхищён, а это для меня редкость. Я считал, что и первый выпуск был хорош, хотя сам читаю редко.

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

Или же меня обнадёжило данное Мартином обещание доработать руководства из предыдущей книги. Знаете, то удовольствие, когда читаешь заметки к долгожданным патчам для рабочего ПО.

А может, это была глубинная надежда, что кто-то, наконец, пересмотрел его идеи и осознал необходимость изменения подхода Мартина к написанию «чистого кода». Всё же это была самая жестокая критика первой редакции книги с момента её публикации более 17 лет назад.

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

Так что представьте, каково было моё разочарование, когда я потратил $60 на электронную версию этой книги, в которой Боб не просто не изменил своей позиции по большинству спорных практик, но и продолжил топить за них ещё круче!

Невероятно!

Но я забегаю вперёд…

Привет народ!

Вот и настала моя очередь исповедоваться перед тобой.

У меня есть, не самая оригинальная, гипотеза о том, что большинство из множества статей жанра "Исповедь Разработчика" - это попытка авторов добавить веса своему персональному бренду, в специфических условиях, сложившихся на рынке труда, когда люди с опытом и, казалось бы, правильным майндсетом, вынуждены стоять в одной очереди с теми, кто вкатился в АйТи только ради денег и удаленки.

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

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

Привет, Хабр. С вами снова Вадим.

В прошлом посте я рассказывал, как написал AI‑бота Аврора, который ищет вакансии вместо меня.

Статья залетела, и к нам пришли первые 100 тестеров. И тут началось веселье.

Представьте: вы нажимаете кнопку «Найти работу», а бот молчит. 10 секунд, 20 секунд. Вы думаете: «Сломалось» и жмете кнопку еще 5 раз.

А на самом деле бот не сломался. Он просто «ушел на кухню готовить».

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

Если вы разработчик — найдете тут код про SKIP LOCKED.

Если вы ищете работу — поймете, почему наш бот теперь быстрее, чем пальцы любого рекрутера.

О вечном — о разумной длине строк кода. Мы недавно встретили ошибку, которая одновременно демонстрирует, чем плох "код-колбаса", "эффект последний строки" и последствия неудачного copy-paste.

Данный документ описывает систему взглядов и практических правил для интеграции ИИ-ассистентов в процесс разработки программного обеспечения. Цель — не запретить использование ИИ, а превратить его в управляемый инструмент, который повышает эффективность, не компрометируя качество, безопасность и ответственность инженера.

Когда программист пишет код, он редко задумывается о том, что происходит с программой после того, как он её написал. Но понимание этого процесса необходимо для эффективной отладки, оптимизации и написания надёжного кода. А ещё, это просто интересно.

Несмотря на то, что книга «Чистый код» привнесла в наш лексикон прекрасный термин, она также снискала и дурную славу. Это руководство от 2008 года представляет собой сборник принципов и исследований, которые «дядя Боб» (Uncle Bob, то есть Роберт Мартин) выработал за годы программирования.

В итоге его практики переняли многие разработчики, одни из которых почитают их как святыни, а другие воспринимают, скорее, в качестве ориентиров, нежели строгих правил. Но, как бы вы к этому ни относились, сам дядя Боб смотрит на них не как на руководства. Он следует этим практикам всецело и очень редко допускает исключения.

Так что можно подумать, что его примеры рефакторинга из книги как минимум окажутся лучше среднего кода, который вы встречаете в повседневной работе, или хотя бы будут согласовываться с другими распространёнными советами.

Можно подумать...

Как можно Cursor IDE превратить в полноценную мультиагентную среду разработки, где каждый AI‑агент выполняет роль члена команды: аналитика, архитектора, планировщика или разработчика?

Как обеспечить высокий уровень автономности, когда система не просто отвечает на запросы, а сама движется от высокоуровневой постановки задачи к результату?

Как добиться сходимости к стабильному результату в ходе длительной самостоятельной работы команды ИИ-агентов?

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

Неважно, в какой сфере вы работаете: backend-разработчик, frontend, архитектор БД, системный аналитик, тестировщик или кто-то еще. А может, вы только ищете работу в IT? Или просто интересуетесь, как устроен цифровой мир. Эта статья - возможность освежить в памяти базовые концепции программирования, подготовиться к собеседованию (ведь вопрос про CRUD-операции может прозвучать не напрямую, но почти всегда скрыт в других задачах или кейсах) или просто понять, как устроены ваши любимые приложения.

Вопрос на миллион: Знаете ли вы, что общего между созданием поста в Нельзяграм, покупкой на Ozon и обновлением резюме на hh.ru?

Ответ прост: в их основе лежат четыре базовые операции, скрытые за аббревиатурой CRUD. И да, эти операции — первая ступень к пониманию того, как работают современные API.

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

В этой статье давайте разберём несколько распространенных заблуждений и на примерах посмотрим, как на самом деле работают транзакции.

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

На тот момент я, еще студент последнего курса универа, только получил свою первую работу в IT... Как сейчас помню свои эмоции. Наконец-то, спустя годы подготовок и отказов, вот, наконец получаешь свойпервый «настоящий» проект. Осмотревшись по сторонам, понимаю, что кругом меня не то что других джунов нет, но даже мидлов. Сплошные синьоры и лиды, как тогда казалось — грозные дядьки, с большим опытом... Ну ничего, сейчас я им покажу, что такое «молодая гвардия» 😂.

Получаю компьютер, креды для доступа, мне подробнее рассказывают про проект, присылают ссылки на минимальный набор сервисов, что нужно будет локально поднять для работы и отправляют настраивать окружение. В первый же день я сломал заботливо предустановленную мне убунту 😂 (удалил «не ту» версию питона, которая, как выяснилась, очень нужна), ну да ладно, мелочи, с кем не бывает?

Установил минт, начал настраивать IDE, окружение, забрал себе нужные сервисы, вроде все хорошо, НО в одном из сервисов стабильно падает один и тот же тест. Запускаю отдельно — все хорошо и стабильно. Запускаю через сборщик (mvn test) — падение. Пытаюсь разобраться, что происходит — ничего не понятно. Тест падает из‑за мока, которого вообще нет в этом тестовом сценарии. Больше того, смущает ситуация, что ни на ci, ни у кого из коллег такого не происходит. Тест стабилен, да и в нем не меняли ничего уже довольно давно. Вывод: проблема на моей стороне и разбираться мне с ней самому.

Это начинается незаметно. Сначала — просто «временное решение». Потом — «сделаем рефакторинг». Но «потом» не наступает никогда. Мы называем это техническим долгом, словно он когда-то будет погашен, но прекрасно знаем — чаще всего это просто красивое описание хаоса. 

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

Я пишу всякое на Go в Ви.Tech (IT-дочка ВсеИнструменты.ру) и как и все, люблю подискутировать на технические темы.

У этой заметки сложная судьба, мне загорелось написать ее еще летом, но совершенно не хотел говорить об очевидных вещах и писать миллион первую статью со ссылкой на гугловский go code review comments. Тема уже разобрана всеми кому не лень, на русском языке вот у  Николая @JustSkiv Тузова, есть замечательное видео на его ютуб канале, раскладывающее по полочкам, для чего это нужно.

Последний дисклеймер и перейду к сути: тема на самом деле очень обширна и я сознательно сконцентрировался на одном аспекте (неуместные определения интерфейсов). Буду рад, если продолжим общение в комментариях, очень не хватает Хабра начала 10-х годов, с живыми, а иногда и крайне горячими, инженерными дискуссиями.

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

Из первых уст рассказываю как переход на Temporal обеспечил надежную доставку клиентских услуг в контексте обычного хостинга.

Рассказываем, как безобидная строка JavaScript-кода привела к нарушению стабильности тестов продукта, а также о том, как можно избежать подобных ошибок.

Откройте любой пулл‑реквест в проекте с любой «чистой архитектурой» и вы скорее всего увидите не обсуждение бизнес‑логики, а срач. «Это нельзя класть в UseCase, это логика домена!», «Зачем тут еще один DTO, мы же просто поле прокидываем!», «Этот интерфейс не нужен, у нас никогда не будет другой реализации!». Полагаю, очень много людей с таким сталкиваются.

Эта статья — о том, почему архитектура из спасения превратилась в тонны говнокода. И, что самое главное, — как прекратить этот хаос и, наконец, начать просто писать код, который работает, а не «следует всем концепциям».

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

Индустрия разработки программного обеспечения переживает фундаментальную трансформацию. Еще два года назад идея доверить AI написание производственного кода казалась фантастикой. Сегодня это реальность для сотен тысяч разработчиков по всему миру.

Согласно данным Anthropic, Claude Code используют более 115 тыс. разработчиков, которые обрабатывают 195 млн строк кода еженедельно. Уровень внедрения среди разработчиков составляет 53% — это лидирующий показатель на рынке. База активных пользователей выросла на 300%, а доход увеличился в 5,5 раза за последние месяцы.

Но что действительно важно, это не статистика внедрения, а фундаментальный сдвиг в подходе к разработке. AI-инструменты больше не просто ускоряют написание кода. Они меняют саму парадигму: от «Как это закодить?» к «Что именно нужно построить?».

В этой статье мы рассмотрим практические паттерны и подходы к R&D и проверке гипотез с использованием современных AI-инструментов, в частности Claude Code — терминального агентного инструмента.