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

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

Платформа Lovable, позиционируемая как low‑code решение для создания веб-приложений и сайтов, где основное взаимодействие с системой происходит через чат с искусственным интеллектом, столкнулась с критической уязвимостью, связанной с RLS-политиками. Она позволила получать и изменять данные без аутентификации — сотни проектов оказались под угрозой.

После первой статьи про стандарты разработки и зарождение Open vAIR остался резонный вопрос: «А что там под капотом?». Отвечаем.

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

Внутри — модульный backend, изоляция через RabbitMQ, REST API и документация, которая обновляется вместе с кодом, а не спустя квартал.

В этой статье разберём, чем Open vAIR отличается от тяжёлых решений, что умеет прямо сейчас, какие модули в приоритете — и в каких сценариях он уже «заходит в прод».

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

Как визуальные платформы ломают культуру разработки и зачем нам нужен контроль над кодом

У меня 25 лет опыта в веб-разработке. Я видел, как появлялись и умирали сотни инструментов, фреймворков, "революций" и "новых парадигм". Я устал повторять, что я не нео-луддит. Я не против прогресса. Но есть момент, когда вместо прогресса тебе продают иллюзию простоты, замаскированную под инновацию.

Так вот, теперь наш CEO влюбился попал под очарование Lovable и хочет, чтобы мы начали использовать его или Base44 для ускорения разработки и быстрого внедрения новых фич. По его задумке, дизайнер "набрасывает интерфейс" (в этих визуальных платформах для сборки UI/UX дизайнером), а мы "допиливаем чуть-чуть на бэке" (через API, Карл!), и всё - фича в проде. Time-to-Market стремительно сокращается, мир спасён, а мы свободны от "лишней инженерии".

Я против. Категорически. И да, это война.

Баги в коде — явление нередкое, но сегодня мы исследуем не просто ошибки, а настоящие космические баги! Что скрывает проект, созданный в недрах NASA? Готовьте свои шапочки из фольги!

Программисты на Go уже давно и долго жалуются на слишком многословную обработку ошибок. Все мы близко (а иногда и болезненно) знакомы со следующим шаблоном кода:

x, err := call()
if err != nil {
// обработка err}

Проверка if err != nil встречается настолько часто, что может становиться объёмнее остального кода. Обычно это происходит в программах, выполняющих много вызовов API, в которых обработка ошибок рудиментарна и они просто возвращаются. Некоторые программы в итоге выглядят примерно так:

func printSum(a, b string) error {
x, err := strconv.Atoi(a)
if err != nil {
return err
}
y, err := strconv.Atoi(b)
if err != nil {
return err
}
fmt.Println("result:", x + y)
return nil }

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

Команда разработчиков Go воспринимает отзывы сообщества со всей серьёзностью, поэтому мы много лет пытались придумать решение этой проблемы.

Всем привет, меня зовут Дмитрий Лоренц, я iOS-разработчик в IT-компании GRI. Наш основной клиент — Sunlight, для него мы разрабатываем нескольких мобильных приложений по полному циклу и поддерживаем сайт.

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

Привет, Хабр! Меня зовут Никита Ли, я Frontend-разработчик в группе Рунити. Так тяжело бывает удержаться от того, чтобы не усложнить себе жизнь, не так ли? Все любят смотреть на чистый и понятный код, но не все его таким пишут. Сделать его таким помогают наши друзья — форматировщики и линтеры. О них и пойдет речь в этой статье, а конкретно о ESLint Stylistic.

Любой автор хочет, чтобы его кто-то читал, даже на JavaScript, но просматривать читателю хочется грамотный и красивый текст. ESLint анализирует код, выявляя ошибки, чтобы программы выходили из под клавиатуры чистыми и без ошибок. Prettier, в свою очередь, как инструмент форматирования делает текст исходного кода программ единообразным. Оба этих инструмента являются практически стандартом, когда речь заходит о качестве кода. Думаю, что многие сталкивались в проектах с их одновременным применением, что в целом логично — форматирование != линтинг. Однако это решение не всегда обосновано, а зачастую излишне. В качестве альтернативы я предлагаю рассмотреть ESLint Stylistic. В этой статье разберемся, что это, откуда появился инструмент и почему с ним стоит познакомиться.

Привет! Меня зовут Илья, последние 7 лет я занимаюсь фронтендом и наконец решил отметиться на Хабре. Стартую с темы, которая, как кажется, уже успела приесться, но всё ещё вызывает жаркие споры — код ревью (CR). Не смотря на сотни статей и мануалов, каждая команда подходит к этому процессу по‑своему. Хочется зафиксировать и осмыслить собственный опыт, показать, как мы подходили к настройке процесса в реальном проекте, и почему, на мой взгляд, код‑ревью не может быть универсальным, а должен опираться на контекст команды.

В этой статье не будет технических деталей вроде рекомендаций по максимальному количеству строчек в diff‑е или формату названий коммитов. Я хочу подняться на уровень выше и поговорить о целях, ключевых факторах и реальных компромиссах которые встречаются в CR.

В своей предыдущей статье [перевод на Хабре] я говорил о множестве недостатков C++, которые, по сути, устранил Rust. Благодаря этому код теперь легко использовать правильно и сложно использовать неверно. Я не говорил о безопасности по памяти, просто привёл пример того, что пользователь функции не может случайно поменять местами аргументы количества и цены.

На написание статьи меня вдохновил доклад Мэтта Годболта о том, как можно сделать интерфейсы C++ более надёжными: Correct by Construction: APIs That Are Easy to Use and Hard to Misuse. Вам стоит его посмотреть!

В той статье я сказал, что Rust гораздо лучше помогает разработчику, возможно, благодаря тому, что у него были десятки лет, чтобы учиться. В конце концов, первая версия C++ была выпущена в начале 80-х, а Rust — в начале 2010-х. Если дать C++ несколько десятков лет для обучения, то, разумеется, появятся новые структуры, которые будут обладать высоким качеством и которые сложно использовать неправильно.

Но так ли это?

Вы любите делать код-ревью? 

«Не могу дождаться следующего PR!», — ответит абсолютно никто.

Понимаю! Ревью — штука необходимая, но давайте честно: утомляет, забирает время и ресурс, который можно потратить на другие задачи. Делегировать, казалось бы, хорошая идея… но кому? Личного ревьюера на полную ставку ни у кого нет.

Меня зовут Александр Федотов, я руководитель группы разработки в «Лаборатории Касперского». В своей команде я уже не раз пытался упростить ревью: менял подходы, вводил правила, подключал автоматизацию. Но все равно ощущение такое, что можно сделать еще лучше. Тем временем, коллеги реализовали интеграцию TFS с внутренней AI-моделью ЛК. И вот одним морозным зимним днем, во время настройки каких-то доступов, я попал в раздел Manage Features, где наткнулся на неприметный пунктик Pull Request AI, который позволял воспользоваться преимуществами этой интеграции.

Не теряя времени, я активировал фичу и стал счастливым обладателем раздела AI в каждом PR. С тех пор ревью стало другим. И теперь я не просто верю в автоматизацию — я ею пользуюсь и хочу поделиться с вами своими мыслями об этом.

Коллекция интересных кусочков кода и дурацких картинок вам в пятницу. Предыдущая серия здесь.

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

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

Эта статья — краткая заметка о двух связанных друг с другом эмпирических правилах.

Поднимайте If вверх

Если внутри функции есть условие if, то подумайте, нельзя ли его переместить в вызывающую сторону:

// ХОРОШО

fn frobnicate(walrus: Walrus) {

... }

// ПЛОХО

fn frobnicate(walrus: Option<Walrus>) {

let walrus = match walrus {

Some(it) => it,

None => return,

};

...

}

В подобных примерах часто существуют предварительные условия: функция может проверять предусловие внутри и «ничего не делать», если оно не выполняется, или же может передать задачу проверки предварительного условия вызывающей её стороне, а при помощи типов (или assert) принудительно удовлетворить этому условию. Подъём проверок вверх, особенно в случае предварительных условий, может иметь лавинообразный эффект и привести к уменьшению общего количества проверок. Именно поэтому и возникло это правило.

Go-разработчики часто сталкиваются с парадоксом: изначально простой и понятный проект со временем превращается в сложный для поддержки монолит.

✔️ Бизнес-логика оказывается размазана между слоями?

✔️ Замена базы данных требует переписывания половины кода?

✔️ Новым разработчикам требуется недели, чтобы разобраться в проекте?

В этой статье мы разбираем практическое применение DDD и Clean Architecture в Go. Обсуждаем возможный стандарт структуры микросервиса. Оптимизируем существующие.

🔥 Для разработчиков, которые хотят создавать проекты, остающиеся поддерживаемыми даже через годы развития.

Недавно мне попался следующий твит от OneHappyFellow:

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

— One Happy Fellow (@onehappyfellow) 5 мая 2025

Этот тезис меня заинтересовал. Дело в том, что по работе мне в основном приходится иметь дело с Clojure. Это динамический язык, но его экосистема на редкость известна своей стабильностью. В этой статье мы подробно разберём, почему именно так сложилось, но для начала я приведу некоторые доказательства, подкрепляющие мою точку зрения.

К написанию этой статьи меня подтолкнуло изучение архитектурных подходов для Vue.js-проектов, а вдохновила - детально описанная методология Feature-Sliced Design.

К сожалению, PHP-сообществу не хватает подобных развернутых рекомендаций, да и вообще, каких-то общепризнанных стандартных подходов в структуре проекта.

Моя статья - это попытка обобщить изученную мною за много лет информацию и сформировать универсальную структуру проекта, основанную на принципах Clean Architecture и модульного монолита.