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

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

Эта статья — не лекция. В интернете полно материалов про технический долг с графиками, квадратиками и теориями. Будем честны: большинство просто игнорирует его. Здесь мы попробуем посмотреть на технический долг так, как он есть на практике — как финансовый инструмент. Как кредитная карта с высоким процентом и мелким шрифтом: ею можно пользоваться, чтобы держаться на плаву, но потеря контроля может стоить проекту слишком дорого. Так и как же им управлять?

Всем привет! Меня зовут Виктор, и более трёх лет я работаю с языковыми моделями – от проприетарных решений вроде ChatGPT до open-source систем, которые можно разворачивать локально и встраивать в собственные продукты. Я застал времена жутких галлюцинаций GPT-3.5 и ждал обещанного GPT-5 – того самого почти AGI, которое, казалось, вот-вот появится.

За это время многое изменилось: появились десятки моделей, которые можно запустить даже на слабом ноутбуке, и мощные коммерческие системы, способные понимать с полуслова. Но одно остаётся неизменным – AGI так и не случилось.
Если два года назад нам уверенно обещали, что «всё уже близко», то теперь даже крупнейшие компании признают: ждать придётся долго.

И это не плохо. Просто разработчикам, приходится учиться работать с тем, что есть, и извлекать максимум пользы из нынешних LLM.

За годы работы с моделями я выработал ряд принципов, которые помогают получать стабильные и читаемые результаты. На первый взгляд – ничего нового: это те же инженерные практики, которые мы применяем в обычном программировании.
Но в контексте LLM они начинают работать совсем иначе.

Привет, Хабр! Меня зовут Константин Репин, я старший программист в Fix Price. В этой статье расскажу, как мы облегчили жизнь нашим коллегам-ревьюерам, внедрив в процесс AI-ассистента для код-ревью. Начну с краткого описания инструмента, а затем перейдем к практике — покажу нашу реализацию и поделюсь опытом, включая примеры кода.

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

Автоматизация CI/CD для embedded-систем решает эти проблемы, хотя требует начальных усилий на настройку инфраструктуры.

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

Мы решили выяснить, какие инженерные практики превращают разработку в систему с понятными процессами и предсказуемыми результатами.

Исследование 100+ респондентов.

Hawk — это open-source трекер ошибок, разработанный в России. Позволяет отслеживать ошибки в веб-приложениях, API и мобильных сервисах. В этой статье подробно рассмотрим функциональность, которая сегодня доступна пользователям Хоука — от регистрации до продвинутых SDK-функций и планов на будущее.

Ночь. Курсор мигает, как маяк в тумане. Логи шепчут о том, что в коде — своя улица, свои правила и кодекс общения. Объекты — не безмолвные элементы системы. У каждого свой характер, привычки и слабости. Один щёлчок и поведение меняется: кто-то отдаёт приказы, кто-то внимательно прислушивается, а кто-то терпеливо ждёт сигнала. Эта статья — карта такого города.

Всем привет! Меня зовут Бромбин Андрей и сегодня разберёмся в поведенческих паттернах ООП. Короткие определения, идеи через ясные метафоры и рабочие примеры на Java. Всё это для того, чтобы система не трещала по швам, а решения были ясными, предсказуемыми и поддерживаемыми.

Многие разработчики привыкли везде ставить if-проверки, даже для условий, гарантированных кодом. Зачем проверять то, что не может нарушиться? Такие проверки создают шум в коде и мусор в релизе. Assert решает эту проблему: документирует допущения и исчезает из финальной сборки. В статье покажу все преимущества assert'ов и предостерегу от подводных камней их использования.

Взгляд на интеграцию ИИ в программирование от опытного программиста (миллион строк кода я, наверное, написал за всю жизнь). Текст писал я сам, это не мусор от GPT, ИИ здесь только исправил ошибки.
Если дать этот текст ИИ на фактчек, то он может как полностью подтвердить мою статью кучей проверенных фактов, так и полностью опровергнуть, и тоже с кучей фактов, т.е. по сути будет заниматься черри-пикингом - всё зависит от формулировки вопроса. И где же тогда правда? Правда, я думаю, у тех, кто в этой среде годами работает и получает много опыта как разработки с ИИ, так и без него. Т.е. имеет хоть какие-то экспертные знания. В этой статье мнение одного из таких людей. Мнения одного человека, конечно, мало, нужно обобщать опыт сотен людей из разных сфер программирования. Я вношу в это обобщение свой небольшой вклад.

Я верил, что с приходом ИИ жизнь разработчика превратится в сказку. ИИ будет писать код, а я — придумывать фичи и строить продукт. В реальности я полдня пишу промты, а еще полдня трачу на правки за Copilot. Быстрее написать код самому.

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

За 9 лет разработки ПО  я периодически выступал в  роли ментора и сталкивался с проблемой, которую недавно озвучил начинающий программист после онлайн-курсов: 

«Не понимаю, как делить код на классы».

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

Я показал студенту несколько готовых шаблонов классов, чтобы он мог сразу применить, и хотел дать методичку по теории, но под рукой не оказалось ни заметок, ни статей, ни книг. Поиск в интернете и запросы к ИИ выдавали только материалы по ООП и принципам SOLID, которые мало касались нужной темы. Выходило так, что вся нужная для такой методички информация, лежит у меня в голове.  

Так и родилась идея написать эту статью.

Тестирование — это не просто поиск ошибок. Это способ убедиться, что продукт действительно работает так, как должен, и делает жизнь пользователей проще, а не сложнее. Хорошее тестирование начинается задолго до первого нажатия кнопки “Run tests” — с понимания логики продукта, требований и рисков.

Мы переживаем величайший кризис качества программного обеспечения в истории вычислительной техники. Калькулятор теряет 32 ГБ оперативной памяти. ИИ-помощники удаляют рабочие базы данных. Компании тратят 364 миллиарда долларов, чтобы избежать решения фундаментальных проблем.

Всем привет! Меня зовут Виктор, и я программист. Восемь лет работаю в команде Т-Банка и все это время вместе с коллегами занимаюсь проектом «Т-Телефония». Моя команда разрабатывает сервисы, которые обеспечивают голосовую коммуникацию внутри и вне банка. 

Звонки — один из основных способов связи с нами, поэтому система критична для бизнеса с высоким требованием к доступности. Она обрабатывает более 2 млн звонков в день. Если происходит сбой в любой пользовательской системе и нашим клиентам плохо, количество звонков сразу увеличивается, а нагрузка на систему повышается в два-три раза.

Когда мне прилетела первая задача с дампом, единственным инструментом, который я знал, был WinDbg. Я потратил несколько дней, чтобы хоть немного разобраться в нем. С развитием проекта приходилось все чаще снимать дампы, и теперь я знаю о них намного больше.

В статье покажу, что такое дампы, какие есть инструменты для работы с ними и какие у них особенности, покажу наши примеры проблем, расскажу, как мы их решали.

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

Привет, Хабр!

«Разработчики исчезнут, но не все» — когда я услышал эту фразу в дискуссии на канале Dev Q&A, она засела в голове надолго. Вот факт: за 10 лет средняя зарплата разработчика в России выросла с миллиона до 2,8 миллиона рублей в год. Стоимость часа работы — с $30-50 до $80-100, у крупных агентств доходит до $300-400. И это происходит как раз тогда, когда появились ИИ-ассистенты, low-code платформы и масса других инструментов, которые вроде бы должны всё удешевлять.

Когда тест проходит с первого раза — это пугает. Стоицизм в TDD — не методология, а форма выживания.

Статья Парнаса «О критериях...» давно стала классикой, на которую постоянно ссылаются, но мало кто ее реально читает. Высказанные в ней идеи о «сокрытии информации» как основе модульности упоминаются повсеместно, однако оригинальный текст с его тщательной аргументацией и яркими примерами остается для многих терра инкогнита. Данный перевод призван восполнить этот пробел.

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

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

Всем привет! Меня зовут Михаил, я веду Telegram-канал «Python Шпильки», где делюсь изящными приемами программирования. Сегодня я хочу рассказать об универсальном декораторе, который может принимать аргументы, а также вызываться без их приема. Для тех кто хорошо знает тему декораторов - ничего нового они тут не увидят! Этот пост для тех, кто, возможно, хочет более подробно понять тему декоратора. Итак, поехали.

Для начала приведу пример конструкции универсального декоратора: