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

Работа с внешними ресурсами — файлами, базами данных или сетевыми соединениями — требует строгой дисциплины. Забыли закрыть соединение? Приложение в итоге столкнется с утечками памяти или исчерпанным пулом коннектов.

Чтобы не писать громоздкие и плохо читаемые конструкции try…finally, в Python используется оператор with. Однако многие разработчики применяют его исключительно как встроенный инструмент для функции open(), упуская огромный архитектурный потенциал этой конструкции.

В начале 2024 года я устроилась Senior Software Test Automation Engineer в финтех-стартап. После работы в большой стабильной корпорации это был настоящий вызов ― попасть в живой дышащий мир молодой продуктовой  компании, пытающейся занять своё место на рынке. Мне понравился продукт и привлекала возможность влиять на процессы, даже устанавливать новые.

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

Так вот, в этой компании я встретила подход automation first. Это означало, что весь разрабатываемый функционал сразу же покрывался автотестами. В добавок к этому были задействованы многие продвинутые инженерные практики, к которым, как я знала из опыта, компании и проекты приходили через боль, страдания, унижения и годы беспросветного мануального регрессионного тестирования. 

Однако не всё было идеально, проблем тоже хватало, даже при том, что скорости релизов мы достигли прямо таки нереальной, обеспечивая при этом отличное качество. В этой компании существовала доселе не встречавшаяся мне структура ― инженерное комьюнити. В каждой дисциплине было своё. У инженеров по качеству ― QA Community. Польза его для процветания компании неочевидна при первом взгляде. Как человеку, который любит докопаться до причин всего на свете, мне было любопытно как это работает и почему. В том числе влекомая этом любопытством я спустя некоторое время выдвинула свою кандидатуру на должность очередного QA Community Lead. Да, должность выборная, как президенство, срок правления ― год, потом смена власти. Немного ранее выборов у нас сменился СТО и объявил, что теперь теперь избранный кандидат должен получить также апрув от него, а также он может оставаться на должности дольше, если нет возражений от комьюнити и/или СТО. Или пока не настанет импичмент, а такое тоже было в истории компании. 

Я прошёл тест на hh.ru с помощью ИИ. Мне не поверили и обвинили во лжи. Я прошёл его ещё раз. Под катом немного рассуждений, немного оскорблений и 30-минутный видеопруф.

…

За эти полгода я кое-что узнал о том, как можно (и как не стоит) обращаться с тем замечательным созданием, что живёт в вашем терминале, виэскоде, курсоре или где вы там его запускаете, и счёл не бесполезным записать некоторые наблюдения. Тем более что меня спрашивают, а каждому лекцию не прочитаешь. Собственно, на то и статья, а точнее, эссе…

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

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

Потом отпустило. Я не поехал. Просто работа переехала, а я не сразу заметил.

Короче. Код стал дешёвым. Любой агент перепишет тебе модуль по запросу, в третий раз, в десятый, на другой язык, ему вообще всё равно. То, за что раньше платили деньги, теперь стоит примерно ничего. А дорого стало то, что по краям от кода. Спереди и сзади. И оба края про одно: сделать правду, которую агент не сможет заболтать.

Потому что заболтать он умеет шикарно. «Готово, всё работает, тесты зелёные». Ага.

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

Месяц назад начал делать собственный язык программирования Nova с Claude Code. За это время агенты автономно закрыли около трёхсот инженерных планов, написали около 120 тысяч строк Rust (компилятор, рантайм, кодоген), почти две тысячи проходящих тестов и собственную стандартную библиотеку на Nova. Один человек физически такой объём не вытянет — но и автономия даётся не бесплатно.

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

AI-инструменты уже давно перестали быть просто «умными чатами». Сегодня Claude Code, Codex и другие агенты постепенно превращаются в полноценную инженерную инфраструĸтуру: с памятью, workflow, sub-agentʼами, orchestration и reusable праĸтиĸами.

В этой статье команда разработки СВОЙ Тех собрала праĸтиĸи, ĸоторые реально помогают использовать Claude Code эффеĸтивно. Дисклеймер: будет много списков — не обессудьте и, надеемся, вам так же, как и автору, легче усваивать информацию.

Привет, Хаброжители! Более десяти миллиардов строк кода C++ в настоящее время используется в реальных проектах, и 98 % разработчиков ежедневно находят и исправляют в них ошибки. Даже в критически важных приложениях встречаются баги, проблемы с производительностью и читаемостью. Эта книга поможет выявить их в коде, который вы поддерживаете, и избежать — в коде, который вы пишете.

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

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

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

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

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

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

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

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

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

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

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

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

Оптимизация кода сервисов на 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, сходятся в одном: если вы не можете измерить качество работы ИИ - вы не можете им управлять.