Обновить
256K+

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

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

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

Верните непрерывную интеграцию разработчикам

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

Все знают аббревиатуру CI/CD. Continuous Integration and Continuous Delivery - Непрерывная интеграция и Непрерывная поставка. Но едва ли можно найти более неправильно понимаемую нашей индустрией идею, чем непрерывная интеграция. Практика, которая была придумана, чтобы её делали разработчики, почему-то превратилась в объект работы девопсов, хотя к культуре DevOps ну вообще никакого отношения, по идее, иметь не должна.

Так что вот вам статья про то, как так вышло, что сейчас под CI понимают что угодно, кроме того, чем она, на самом деле, является.

Читать далее

Как я пишу код быстрее

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

Вечный вопрос разработчика: как писать код быстрее, не превращая его в поддерживаемый кошмар? Дедлайны давят, требования растут, а перфекционизм подсказывает: «Ещё рефакторинг!»

Автор годами искал баланс между скоростью и качеством в разработке ПО и вывел практические правила. Делимся опытом: черновики вместо идеала, борьба с отвлечениями, маленькие патчи и другие навыки, реально ускоряющие работу.

Готовы ускориться?

Цикл вебинаров про разработку безопасного программного обеспечения (ГОСТ Р 56939-2024)

Уровень сложностиСредний
Время на прочтение3 мин
Охват и читатели3.7K

Обычно я пишу про статический анализ, баги и оформление кода. Однако сейчас меня притянуло к тематике РБПО (разработка безопасного программного обеспечения). Это связано с тем, что статический анализ является одним из основополагающих процессов безопасной разработки.

Всё началось с цикла публикаций про ГОСТ Р 56939-2024 в моём Telegram-канале "Бестиарий программирования". Мой внимательный читатель Виталий Пиков из УЦ МАСКОМ, увидев это, пришёл и сказал: "А давай больше!" Он предложил запустить целый цикл совместных вебинаров, где последовательно разобрать все 25 процессов, описываемых в ГОСТ Р 56939-2024. И идея мне понравилась.

Читать далее

Техдолг: симптомы, диагностика и лечение

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

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

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

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

Читать далее

Как писать красивый и чистый код питонистам?

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

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

Читать далее

Статья 3: Из чего готовят MVI

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

Серия статей с очередным разбором MV* шаблонов, но с интересными деталями
Даже опытные разработчики смогут найти что-то новое для себя

Это третья статья из серии,
в которой подробно разбираем из чего состоит MVI

Статья 3: Из чего готовят MVI
- ⚓️ Парадигма Реактивное программирование (Reactive programming)
- 🌯 Как завернуть все в шаурму Intent?
- 🌽 Как собрать урожай состояние?
- 🚜 Зачем трактору нужен редуктор?
- 🏪 Как открыть магазин с перехватчиками?
- 👷🏼‍♀️ 5 менеджеров и 1 работник

Нарезать сущности в салат

Статья 2: Подробнее про MVVM

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

Серия статей с очередным разбором MV* шаблонов, но с интересными деталями
Даже опытные разработчики смогут найти что-то новое для себя

Это вторая статья из серии,
в которой подробно разбираем MVVM
и является ли класс ViewModel от Google, сущностью ViewModel из шаблона

Статья 2: Подробнее про MVVM
- 🔨 Функции обратного вызова (Callback)
- 🛠 Паттерн Наблюдатель (Observer)
- 📜 MVVM (ViewModel)
- 🔨 Привязка данных (Data Binding)

Найти новое

Синдром тревожного анализатора и разработчика-заложника

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

Мы просто смотрим на экран. Один варнинг. Один, но он красный. Он "орёт". Не получается сразу понять, в чём дело. Условный рефлекс срабатывает, и уже открывается Git. Сейчас пофиксим, а потом подумаем. Даже если предупреждение касается чего-то безобидного, один красный прямоугольник на фоне зелёных строчек может парализовать внимание.

Читать далее

Прочитал «Чистый код», чтобы вам не пришлось

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

Пересказываю культовую книгу Роберта Мартина "Чистый код" с примерами на C#. Узнайте, как создавать код, который читается как проза: от магии имен переменных и идеальных функций до безупречных тестов и архитектуры, которая не рухнет при первом требовании заказчика. Полный гид, ваш код станет предметом гордости, а не источником кошмаров.

Читать далее

В айти не войти или о бедном стажёре замолвите слово…

Уровень сложностиПростой
Время на прочтение9 мин
Охват и читатели74K

Когда-то всё было проще. В достопамятные двухтысячные годы джунов и в самом деле нанимали. Не спрашивали о «релевантном опыте», не требовали ссылки на боевые проекты и не строили сложных лабиринтов из HR-интервью, технических сессий, тестовых заданий и многоступенчатых собеседований. Но прошло 15–20 лет — и всё изменилось до неузнаваемости. Новички (стажёры и джуны) теперь бесправны и даже подозрительны.

Читать далее

Карты, Java, 2 null'а. XMage edition

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

Компьютерная игра на Java — вещь довольно редкая, но всегда интересная. Поэтому мы не упустили возможность проверить статическим анализатором проект XMage и поделиться результатами. Посмотрим, что нашёл PVS-Studio в исходном коде проекта.

Читать далее

Почему мы все еще храним код в текстовых файлах?

Время на прочтение5 мин
Охват и читатели61K

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

Читать далее

Низкий порог входа, высокий риск — как уязвимость в Lovable открыла данные тысяч пользователей

Уровень сложностиСредний
Время на прочтение3 мин
Охват и читатели8.4K

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

Читать далее

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

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

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели4.5K

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

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

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

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

Читать далее

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

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели4.3K

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

Читать далее

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

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

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

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

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

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

Читать далее

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

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

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

Поехали!

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

Уровень сложностиПростой
Время на прочтение10 мин
Охват и читатели8.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 мин
Охват и читатели2.8K

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

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

Читать далее

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

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

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

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

Читать далее