Как стать автором
Обновить
74.1

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

Как Макконнелл завещал

Сначала показывать
Порог рейтинга
Уровень сложности

Виртуализация, которую можно трогать руками

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров473

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

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

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

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

Читать далее

Новости

Агентное кодирование. Инструция по созданию надёжного программного продукта (LLMDD)

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров654

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

Читать далее

Наш CEO хочет no-code в проде. Я против — и готов уйти

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров29K

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

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

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

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

Читать далее

Как NASA ошиблись в исходном коде планеты

Уровень сложностиСредний
Время на прочтение13 мин
Количество просмотров2.8K

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

Поехали!

Об (отсутствии) синтаксической поддержки обработки ошибок в Go

Уровень сложностиПростой
Время на прочтение10 мин
Количество просмотров4.6K

Программисты на 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 воспринимает отзывы сообщества со всей серьёзностью, поэтому мы много лет пытались придумать решение этой проблемы.

Читать далее

Творческая переработка MVVM и TCA на примере iOS

Уровень сложностиСредний
Время на прочтение22 мин
Количество просмотров798

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

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

Читать далее

Форматирование без боли: ESLint Stylistic вместо Prettier

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров3.9K

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

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

Читать далее

Код-ревью: борьба или мотивация?

Время на прочтение6 мин
Количество просмотров1.9K

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

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

Читать далее

Почему разработка через тестирование (TDD) не приводит к плохому коду

Время на прочтение3 мин
Количество просмотров2.5K
Только вот если…

Мне не верится, что я до сих пор пишу такие вещи, но что поделать. Разработка и реализация кода, управляемого тестами (TDD), хороша ровно настолько, насколько хороши решения по проектированию и имплементации, принятые в этом коде. Точно так же, как и код, который разрабатывается не через тестирование.

Вот один ложный аргумент, который я хочу опровергнуть: используя TDD, вы никогда не сможете обобщить код.
Читать дальше →

Может, если бы у C++ было больше времени, он стал бы лучше?

Уровень сложностиСредний
Время на прочтение9 мин
Количество просмотров11K

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

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

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

Но так ли это?

Читать далее

Каждому сотруднику по личному помощнику: как мы подружились с AI-ревью

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров2.1K

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

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

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

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

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

Читать далее

1С: Дичь, серия 2

Уровень сложностиПростой
Время на прочтение1 мин
Количество просмотров8.8K

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

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

Читать далее

Код-ревью под микроскопом: как нетоксично давать обратную связь и проверять код без нервов

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров1.4K

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

Читать далее

Ближайшие события

Поднимайте If вверх, опускайте For вниз

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров31K

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

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

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

// ХОРОШО

fn frobnicate(walrus: Walrus) {

... }

// ПЛОХО

fn frobnicate(walrus: Option<Walrus>) {

let walrus = match walrus {

Some(it) => it,

None => return,

};

...

}

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

Читать далее

Go-микросервисы: Стандартизация архитектуры с Clean Architecture и DDD

Уровень сложностиСредний
Время на прочтение5 мин
Количество просмотров7.1K

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

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

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

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

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

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

Читать далее

Clojure — стабильность по определению

Время на прочтение10 мин
Количество просмотров2.9K

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

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

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

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

Читать далее

The Clean Structure — Универсальная структура PHP-проекта на примере Laravel

Уровень сложностиСредний
Время на прочтение12 мин
Количество просмотров6.4K

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

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

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

Читать далее

Чистый код — красивая архитектура. А работает ли это?

Уровень сложностиПростой
Время на прочтение12 мин
Количество просмотров19K

Вы пишете код не для компилятора — он съест любую абракадабру, если синтаксис верен. Вы пишете для людей, для того парня из соседнего отдела, который будет разбирать ваш код через полгода. Для себя, когда забудете, о чём думали в момент написания. Для тимлида, у которого нет времени расшифровывать ваши «фичи», замаскированные под техдолг. 

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

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

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

Давайте разберём, как превратить кошмар в конфетку — детали внутри.
Читать дальше →

Разбираем архитектуру. Часть 1. Чистая архитектура и её корни: история и взаимосвязи

Уровень сложностиПростой
Время на прочтение24 мин
Количество просмотров12K

Предисловие

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

Я решил написать серию статей, посвящённых различным аспектам проектирования программных систем, но первоначальной идеей было показать архитектурное решение моего pet-проекта на FastAPI — пример реализации «чистой архитектуры» с использованием современного стека: Python3.13, FastAPI, Uvicorn, Nginx, PostgreSQL, Alembic, Celery, Redis, Pytest, Filebeat, Logstash, Elasticsearch, Kibana, Prometheus, Grafana, Docker и Docker Compose.

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

Читать далее

BI в тестировании — сравнение результатов бенчмарков двух веток с помощью однофакторного ANOVA (критерий Кохрена-Кокса)

Время на прочтение5 мин
Количество просмотров1.1K

Business Intelligence (BI) находит применение в самых разных сферах, в том числе, например, при анализе результатов бенчмарков. Часто возникает задача сравнения производительности двух версий приложения на основе результатов бенчмарков (время выполнения тестов для нескольких прогонов и нескольких тестов), например, сравнение master ветки и feature ветки. Улучшение производительности в feature ветке (особенно, если она для улучшения производительности и создавалась) проверить можно условно и вручную, но также важно проверить, что нет деградации в других кейсах бенчмарков для feature ветки по сравнению с master веткой. Это можно решить статистическими методами, например, достаточно однофакторного дисперсионного анализа (ANOVA), здесь будет рассмотрен критерий Кохрена-Кокса, особенности его имплементации на PostgreSQL и возможные виды графиков для представления результатов. Интересующимся применением BI и ANOVA для сравнения производительности двух версий приложения на бенчмарках — добро пожаловать под кат :)

Читать далее
1
23 ...