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

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

Давайте вспомним как мы строим роутинг в наших приложениях. В примере ниже – react-router-dom, но в других фреймворках/библиотеках все примерно также:

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

Конечно, в крупных проектах такое стремление к лаконичности совершенствованию ни к чему. Очень часто мы даже не можем заранее сформулировать ТЗ и двигаемся шагами, только постепенно понимая направление совершенствования нашего проекта. Современные среды разработки заточены на диалог с ИИ-агентом, который по шагам добавляет функциональность в наше приложение, исправляет возникшие ошибки и т.д.

Эта статья содержит разбор эксперимента по вайб-кодингу, проведённого oldschool-разработчиком с 20+ летним стажем (Assembler, 1C, C/C++, Go, Pascal, Perl, PL/SQL, Python). Я покажу:

• В каких случаях вайб-кодеру достаточно минимальных знаний предмета, а в каких необходимы экспертные навыки и опыт?

• Что изменилось в инструментах вайб-кодинга за текущий год, и что изменится в ближайшем будущем?

• Сравним обычные и «премиум» языковые модели.

• Поймём, есть ли предел у диалога с ИИ-ассистентом, и как понять, что он достигнут?

Ситуация: пишешь код на JS, хочешь обработать исключение, пробрасываешь throw, ловишь его с помощью try‑catch. Но добавим нюанс: пусть это нужно сделать для setTimeout. Эта функция использует окружения браузера — не JS‑функция, асинхронная.

Загвоздка: catch не сможет поймать ошибку.

Этот пример — одна из нескольких особенностей JS, из‑за которых я считаю обработку исключений «из коробки» на этом языке неудобной. Но есть и хорошие новости — для JS существуют альтернативные способы работы с исключениями, с которыми дела обстоят получше; например, паттерн «контейнерный тип».

Давайте разбираться.

Привет, заводчане! В этой статье вы найдете реальные технические советы по особенностям общения с бездушными ИИ моделями, в частности я расскажу про GPT 4o и свежую 5, но эти советы также применимы и к другим AI.

‼️Сразу внесу ясность: рекомендации предназначены для личных пет-проектов и
не призывают нарушать политику конфиденциальности вашей компании!

Я инженер по тестированию и уже около года поддерживаю работу своей песочницы по практике тестирования и подготовке к собеседованию на позицию Full Stack QA. Опыт вайбкодинга повлёк за собой понимания работы JS, CSS и HTML, если говорить конкретно про веб-проект. Благодаря такому проекту и подходу вайбкодинга, я собрал технические инструкции и заметки как выжать максимум из ответа ИИ моделей, здесь будет больше технических особенностей работы с моделями, нежели готовые промпты. Ниже указал 12 советов, которые упростят вам написание кода, разработку своего проекта, изучение нового стека или учебную практику.

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

Я просто включил «open to work» на LinkedIn — и неожиданно получил оффер в продукт. Пошёл на собеседование «чисто посмотреть» и остался.

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

Иногда запрос на слияние (merge request) даже не стоит отправлять на код‑ревью, так как при его составлении кто‑то злоупотреблял искусственным интеллектом, и это повредило как проекту, так и команде. Например:

1. Удалив часть кода, можно значительно улучшить запрос на слияние.
2. Вы не знаете основ языка, на котором подавали запрос.
3. Спам в документации.
4. Вопиющая несогласованность материала.
5. Чрезмерно подробно рассмотрены пограничные случаи.
6. Вы добавили бессмысленные или нежелательные зависимости и сами не понимаете, зачем.

Если я прислал вам обратно ваш запрос на слияние с невычищенным ИИ и без всяких прочих комментариев — значит, какие‑то из этих пунктов вы выполнили.

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

Есть небольшая книжка написанная более 20 лет назад, переведенная на русский как «Экстремальное программирование». При обсуждении этой книжки с коллегами я часто встречал мнение, что она только про то, что надо сначала тесты писать, а потом код и больше в ней нет ничего полезного. Когда у самого добрались руки до нее, я понял, что видимо читают выжимки из статей на Хабре или просто статьи википедии, потому что там есть и паттерны проектирования, и правила написания тестов и практические примеры. А все запоминают только мантру «Утром тесты — вечером стулья код».

«У чат-GPT спросил?» — эта фраза стала мемом в нашей команде. Техлид Иван постоянно экспериментировал с AI, а коллеги подшучивали над его энтузиазмом. Вдохновлённые энтузиазмом техлида, мы решили протестировать возможности искусственного интеллекта для автоматизации код-ревью. За 48 часов хакатона мы создали рабочее MVP, которое уже упрощает работу разработчиков. Читайте, как AI помог нам сократить время на ревью кода и какие результаты мы получили всего за два дня.

Привет, Хабр! Меня зовут Владимир Добрынин, я ведущий разработчик в МТС Web Services. Наша команда занимается плагинами DevTools, которые упрощают и ускоряют создание софта, в том числе за счет сокращения рутинных операций.

У нас уже есть целое семейство внутренних инструментов. Один из них — DevTools Copilot, который непосредственно из среды разработки позволяет взаимодействовать с LLM в режиме чата. А теперь мы реализовали DevTools Code Review, который помогает проводить самостоятельное код-ревью. В этой статье расскажу, как работает плагин и чего мы с его помощью добились.

Оживленная дискуссия под моей первой статьей (https://habr.com/ru/articles/940782/) показала: разговор о единстве языка со сферой программирования задевает многих за живое. Тем не менее, cпасибо всем за сотню комментариев, сохранений и невероятно полезного и ценного опыта!

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

Вместе с тем один из наиболее сильных и частых аргументов от скептиков звучал примерно так: «весь код — это чистая, бездушная логика для машины». На мой взгляд, это самое большое заблуждение в этой индустрии. Знали ли вы, что оператор + в вашем коде семантически богаче, чем многие слова в русском языке? Или что конструкция if not my_list — это не просто синтаксис, а настоящая идиома, которая отделяет «носителя языка» от «иностранца»? Задача настоящей работы — исследовать, как в строго детерминированной среде кода возникают сложнейшие семантико-прагматические явления, свойственные живому языку. 

Давайте забудем про имена и заглянем в самое сердце кода — в его грамматику и риторику. Пристегните ремни безопасности :-)

Сегодня хотелось бы поговорить с вами о такой теме как Легаси.

Давайте дадим определение, что такое легаси.

Легаси - это тот код, который писали до нас и который пришел нам от других.

Легаси - это не всегда «плохой» код, а просто код, который устарел по технологии, по структуре или по пониманию.

Почти любой проект со временем превращается в легаси, если его не обновлять.

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

1) Технологии, которые еще работают, но есть обновленные версии пакетов, фреймворков и инструментов. Просто в данный момент код работает на предыдущих версиях. Самый очевидный пример  проект написанный на Vue2, когда есть Vue3. Переписать его на новую версию с одной стороны не так уж и трудно. А с другой это связано с подводными камнями. Если мы переходим с Option Api на Composition Api то простой заменой одного кода на другой не обойтись. Некоторые вещи работают иначе. И придется отлавливать локальные проблемы. Если проект небольшой и сложной логики там мало, то это делается быстро. Если же она есть то проблемы точно будут. Кроме того не стоит забывать, что часть пакетов и библиотек, которые работают с Vue2, не работают с Vue3. Следовательно придется искать аналоги. В целом проблемы и способ перехода здесь прозрачны и это самый легкий вариант.

2) Нельзя переписать, но можно работать. Это проекты написанные на старых технологиях, как jquery и других. Они не могут быть быстро и легко переведены на современные инструменты. Так как для этого придется все писать заново. Однако код, который был написан, достаточно понятен и его не так сложно поддерживать. А переезд на новый вариант это параллельная разработка нового. Здесь тоже все понятно. Мы не имеем возможности бесшовно перейти на новые версии, потому что их просто может не быть. Поэтому приложение пишется с нуля на новом стеке. 

TL;DR

Автоматическое ревью кода с помощью ИИ уже работает в продакшене крупнейших компаний. Microsoft обрабатывает 600 000 пулл-реквестов в месяц, экономя сотни тысяч часов. ByteDance достигла 75% точности с 12 000 активных пользователей еженедельно. Google автоматизировал 7,5% всех комментариев ревьюеров. В статье — детальный разбор архитектур, метрики эффективности и пошаговое руководство по внедрению с расчётом окупаемости.

Дэвид Истман, разработчик ПО для Oracle Corp. и British Telecom, тестирует ИИ-инструмент для кодинга под названием Bolt. Совместно с ИИ-ассистентом он пробует разработать простенький проект блога, попутно рассуждая о сильных сторонах, ошибках и нюансах сервиса. Статья будет полезна новичкам и желающим приобщиться к вайб-кодингу работе с ИИ-помощниками.

Кажется, про TDD давно всё известно: сперва тест — потом код — получаем покрытие. Но на деле его суть понимают неправильно — как критики, так и сторонники.

Эта статья — не инструкция и не религиозная проповедь. Это разбор заблуждений. Причём речь пойдёт не только о критиках TDD, но и о его сторонниках.

TDD часто воспринимают как способ добиться максимального покрытия или как дисциплину «писать тесты вперёд». Но настоящая цель — не в тестах, а в итеративном проектировании поведения и архитектуры.

Если вам кажется, что TDD — это занудно, медленно, не подходит к реальному коду или убивает гибкость — возможно, вы всё делали правильно.
Но с совершенно другими целями.
Именно поэтому вам не понравилось.

Разберёмся, что такое TDD на самом деле — и почему вы, скорее всего, не знаете TDD.

Привет, Хабр! Меня зовут Илья Андреев, я старший программист в компании Syntacore. Вы, наверно, слышали, что виртуальные функции в C++ пользуются дурной славой — а может, и сами придерживаетесь о них не самого лучшего мнения. В этой статье, подготовленной совместно с Константином Владимировым, я в некоторой степени выступлю адвокатом виртуализации.

Мы начнем с вводной части о статическом и динамическом полиморфизме, рассмотрим факторы, влияющие на девиртуализацию, и ее примеры разной сложности — в том числе те, что мы используем в реальной разработке. А напоследок познакомим вас со спекулятивной девиртуализацией и дадим рекомендации, как подходить к виртуальным функциям в разработке на C++.

Не торопитесь пролистывать эту статью. Я не собираюсь, подобно множеству других статей на Хабре, рассказывать о плюсах или минусах вайб-кодинга и сравнивать это с плюсами и минусами традиционного программирования. Потому что сравнивать нечего, ведь не случилось ничего такого, что бы как-то значительно изменило ситуацию. По сути, я буду говорить о том же, о чём говорил в предыдущей статье ( https://habr.com/ru/articles/938028/ -Михаил Елисейкин «IT-лягушка и новая нормальность» ) - о том, что мир меняется, а наши о нём представления от этих изменений отстают.

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

Привет! Меня зовут Александр Дудукало, я автор базового курса по JavaScript. В этой статье расскажу, как стрелочные функции помогают сокращать записи функций, делают код визуально чище и как использовать их без потери смысла. Также покажу, чем обычные функции проигрывают стрелочным и почему одно нельзя заменить другим.

Привет, Habr! Меня зовут Михаил Тетерин, я разработчик в Lenta tech, и сегодня расскажу, как мы упростили и ускорили процесс code review с помощью собственного инструмента — «ревью-рулетки». Это решение появилось из повседневной боли, когда merge requests зависают, разработчики неохотно разбирают задачи на ревью, а в чатах идет бесконечное «посмотри мой MR, пожалуйста».

Антонио Куни — инженер, давно занимающийся повышением производительности Python, а также разработчик PyPy. Он провёл на EuroPython 2025 в Праге презентацию «Мифы и легенды о производительности Python». Как можно догадаться из названия, он считает многие общепринятые сведения о производительности Python как минимум вводящими в заблуждение. На множестве примеров он показал, где, по его мнению, таятся истинные проблемы. Инженер пришёл к выводу, что управление памятью в конечном итоге наложит ограничения на возможности повышения производительности Python, но у него есть проект SPy, который, возможно, станет способом реализации сверхбыстрого Python.

Он начал своё выступление с просьбы: «Если вы считаете Python медленным или недостаточно быстрым, поднимите руку»; поднялось много рук, в отличие от презентации на PyCon Italy, где руку не поднял почти никто из присутствующих. «Совершенно другая аудитория», — сказал он с улыбкой. Антонио уже много лет работает над производительностью Python, он общался с множеством разработчиков на Python и слышал кучу устоявшихся мифов, которые захотел развеять.

Краткая шпаргалка с определениями принципов. Под катом плюсы/минусы SOLID, чтоб пройти собеседование на мидла\сеньора\архитектора, а в работе принять осознанное решение: «Применять ли здесь SOLID?»