Серия статей с очередным разбором MV* шаблонов, но с интересными деталями
Даже опытные разработчики смогут найти что-то новое для себя
Это третья статья из серии,
в которой подробно разбираем из чего состоит MVI
Статья 3: Из чего готовят MVI
- ⚓️ Парадигма Реактивное программирование (Reactive programming)
- 🌯 Как завернуть все в шаурму Intent?
- 🌽 Как собрать урожай состояние?
- 🚜 Зачем трактору нужен редуктор?
- 🏪 Как открыть магазин с перехватчиками?
- 👷🏼♀️ 5 менеджеров и 1 работник
Серия статей с очередным разбором MV* шаблонов, но с интересными деталями
Даже опытные разработчики смогут найти что-то новое для себя
Это вторая статья из серии,
в которой подробно разбираем MVVM
и является ли класс ViewModel от Google, сущностью ViewModel из шаблона
Статья 2: Подробнее про MVVM
- 🔨 Функции обратного вызова (Callback)
- 🛠 Паттерн Наблюдатель (Observer)
- 📜 MVVM (ViewModel)
- 🔨 Привязка данных (Data Binding)
Мы просто смотрим на экран. Один варнинг. Один, но он красный. Он "орёт". Не получается сразу понять, в чём дело. Условный рефлекс срабатывает, и уже открывается Git. Сейчас пофиксим, а потом подумаем. Даже если предупреждение касается чего-то безобидного, один красный прямоугольник на фоне зелёных строчек может парализовать внимание.
Пересказываю культовую книгу Роберта Мартина "Чистый код" с примерами на C#. Узнайте, как создавать код, который читается как проза: от магии имен переменных и идеальных функций до безупречных тестов и архитектуры, которая не рухнет при первом требовании заказчика. Полный гид, ваш код станет предметом гордости, а не источником кошмаров.
Когда-то всё было проще. В достопамятные двухтысячные годы джунов и в самом деле нанимали. Не спрашивали о «релевантном опыте», не требовали ссылки на боевые проекты и не строили сложных лабиринтов из HR-интервью, технических сессий, тестовых заданий и многоступенчатых собеседований. Но прошло 15–20 лет — и всё изменилось до неузнаваемости. Новички (стажёры и джуны) теперь бесправны и даже подозрительны.
Компьютерная игра на Java — вещь довольно редкая, но всегда интересная. Поэтому мы не упустили возможность проверить статическим анализатором проект XMage и поделиться результатами. Посмотрим, что нашёл PVS-Studio в исходном коде проекта.
Давным-давно программный код хранился на перфокартах, но эти времена прошли и теперь мы храним код в текстовых файлах, что конечно же лучше. Но, может быть, пора сделать еще один шаг и начать использовать другой формат, более удобный?
Платформа 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. С тех пор ревью стало другим. И теперь я не просто верю в автоматизацию — я ею пользуюсь и хочу поделиться с вами своими мыслями об этом.
