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

Из трёх мажоров, описанных в предыдущей статье, два не всплыли в тестах. Они всплыли в двух дизайн-ревью, которые тесты провести не могут.

Всем привет, на связи команда ZeBrains. Этот текст про то, как мы перестали просто использовать ИИ и начали с ним работать по-настоящему. Про настоящие проекты, шишки и один файл, который изменил всё.

Спойлер: один разработчик теперь закрывает полный цикл от ТЗ до прода. Без дизайнера, без аналитика, без DevOps. За месяц. Но путь к этому был не таким прямым, как кажется.

Представьте, что вы работаете над кодом магазина, который живёт уже много лет. Бизнес доволен, продажи растут, но есть одна проблема — модуль обращения к весам превратился в чёрный ящик. Когда-то давно он работал прекрасно, но со временем разросся. Многопоточность, низкоуровневый код и бизнес-логика сплелись в один клубок, каждое изменение могло что-то сломать. И так дошло до того, что появились несколько фич, которые не реализовывались уже полгода... Стало ясно, что требуется не столько рефакторинг, сколько новая, удобная для работы абстракция.

Приветствую! Меня зовут Иван Матвеев, я разработчик в компании X5, и сегодня я расскажу, как мы начали рефакторить наши весы.

Я выпал из IT на месяц. Причина банальна, но сурова – капитальный ремонт. По квартире проложено пара километров кабеля, из них 600 метров витой пары для шины управления, на полу разложен макет двух щитов по 54 модуля общей стоимостью под 150 тысяч рублей – и чем глубже я лезу в ПУЭ и считаю сечения, тем чётче одна мысль: если бы инженеры-электрики проектировали системы так же, как мы, разработчики, проектируем распределённые приложения – мы бы все давно сгорели заживо.

Привет, Хабр. На связи Александр Сахаров, директор по работе с партнерами компании "Диасофт". Про вайб-кодинг сейчас говорят так, будто индустрия уже все решила. Спойлер: не решила. Из всех разговоров осели три самых громких тезиса, и каждый при ближайшем рассмотрении ломается в конкретной точке.

Кому лень читать лонгрид, полная запись беседы лежит на Youtube. Спорить и задавать свои вопросы приходите в Telegram-канал Департамент разработки, где собирается сообщество разработчиков.

Решил поделиться вполне элементарными, но такими полезными приемами работы с гитом, которые нарушаются постоянно не только новичками или молодыми сотрудниками, но и вполне опытными разработчиками !

Всем снова привет!

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

В этой статье мы разберём, как действовать и, главное, мыслить в таких ситуациях. Проблема в том, что конфликтов в git может случиться куча: может сломаться ручной git merge, при git pull, может полететь при git rebase , git cherry-pick и т.д. Из-за этого одного конкретного решения нет, но зато есть общий принцип решения.

Если вы хоть раз поднимали Laravel-проект в Docker Compose, наверняка сталкивались с ситуацией: контейнер с приложением стартует раньше, чем база данных успевает принять соединения, и миграции падают с ошибкой SQLSTATE[08006] или Connection refused. Перезапустишь — всё работает. На локалке терпимо, но в продакшене — это в падающие деплои.

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

Решение — правильно настроенные healthcheck’и и условие depends_on с параметром condition: service_healthy. В этой статье разберём, как это сделать для типичного стека Laravel: PHP-FPM, PostgreSQL, Redis и Nginx.

Оптимизация кода сервисов на Go под реальную нагрузку

Когда сервис на Go начинает «тормозить» под реальной нагрузкой, проблема почти всегда не в самом языке и даже не в алгоритмах. Чаще всего узкие места лежат на уровне работы с памятью, сериализации данных и неочевидных накладных расходов рантайма. Если сервис упирается в сеть, базу данных или внешние API — оптимизация кода даёт ограниченный эффект. Но в CPU-bound сценариях (парсинг JSON, агрегации, обработка данных) каждая лишняя аллокация и копирование начинают стоить дорого.

Ключевая особенность Go — автоматическое управление памятью через garbage collector. Это удобно, но под нагрузкой GC становится заметным фактором:

Баги — неизбежная часть разработки. 

В этой статье расскажу наш опыт: как мы внедрили Zero Bug Policy в нашем стартапе (B2B fintech) и за месяц сократили backlog с 77 до 18 багов. А главное — как это изменило культуру и отношения с клиентами.

Мысли о нейминге приватных переменных в C++ и неочевидные моменты из стандарта, о которых легко забыть в реальном коде

// todo: тут N+1 на invoice — надо переделать через entity graph.

Этот комментарий висел в коде полтора года. Все, кто заходил в файл, его видели. Никто не завёл тикет. В пятницу вечером он сработал — и забрал с собой три пода, 30% запросов на критичной ручке и моё спокойствие на выходные.

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

Если это ваша повседневная реальность, у нас плохие новости: вы не управляете продуктом, вы играете в лотерею.

В мире, где LLM-агенты становятся основой бизнес-процессов, AI Evals (оценки) — это не дополнительная нагрузка на инженеров, а единственная возможность контролируемых улучшений. Лидеры индустрии, от OpenAI до Anthropic, сходятся в одном: если вы не можете измерить качество работы ИИ - вы не можете им управлять.

Взгляд на экосистему SQL-разработки под MS SQL SERVER через призму контроля качества кода. Обзор существующих инструментов, описание самостоятельной наработки для линтинга T-SQL кода.

Все мы начинали писать на Python примерно одинаково: создавали пустой список, запускали цикл for, проверяли условие через if и делали .append(). Это надежно, предсказуемо, но по мере роста кодовой базы такие конструкции начинают утомлять — мы тратим 4-5 строк на банальную трансформацию данных, которую можно уложить в одну лаконичную строку.

В этой статье мы подробно разберем встроенный инструментарий Python для работы с итерируемыми объектами: map, filter, reduce, any, all, zip и enumerate.

15 мая Vercel Labs релизнули Zero. Экспериментальный системный язык, который сами авторы называют "the programming language for agents". Версия 0.1.1, Apache 2.0, расширение .0, бинарники меньше 10 килобайт, без LLVM. На GitHub лежит компилятор, стандартная библиотека и примеры — можно ставить и щупать прямо сейчас.

Я прочитал доки, поставил себе, погонял пару примеров. Сижу с этой мыслью: серьёзно или очередной хайповый проект под волну агентного кодинга?

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

Привет! Это снова Михаил Федоров. В первой статье — архитектура QA Assist: 11 AI-агентов от декомпозиции требований до готовых автотестов. Во второй — как «4 часа подключения» превращаются в неделю корпоративной реальности. В третьей — почему пирамида тестирования ломается, когда тест-дизайнером работает LLM. Сегодня — про то, как я решил наконец-то перестать оценивать агента «на глаз» и собрал отдельный проект-бенчмарк, на котором можно честно сравнивать прогоны: версии агента, отдельные «улучшалки», даже эксперименты с моделями. В качестве бонуса покажу все артефакты, которые агент готовит за один прогон пайплайна. И бенчмарк, и артефакты — в публичном доступе, ссылки в конце статьи. Обсудить всё это можно в Telegram-группе.

Миграции базы данных вроде бы есть, Liquibase подключен, changelog лежит в репозитории, CI зелёный, релизы проходят регулярно. Значит, процесс под контролем?

Не всегда…

Философия статья начинается с удивления. В данном случае я отметил для себя то, как по-разному начинающие разработчики реагируют на сложности, с которыми сталкиваются. Например, когда надо сделать выбор - какое решение взять, чтобы избежать ошибок? Кажется, все сталкиваются с такими неудобными вопросами. Давайте попробуем разобраться.

Исключения рождаются не только в основном коде, но и в обработчиках этих самых исключений. Зачастую вопросу не уделяется должного внимания. Действительно, что может пойти не так в блоке catch? Там ведь код тривиальный! Но это только на первый взгляд.

Например, безобидный LOG.warn("...") выливается в десяток вызовов нижележащих методов. И чем больше «наслоений» в библиотеке логгирования, тем выше вероятность сбоя. Всё бы ничего, если бы не одна особенность языка Java…