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

Поговорим о том, как механизм baseline может упростить внедрение статического анализатора в проект, а также о том, как бороться с ложноположительными срабатываниями.

Салют, Хабр! Меня зовут Всеволод, и я занимаюсь анализом защищенности веб-приложений в Positive Technologies.

С API веб-приложений я успел познакомиться со всех сторон: как разработчик, инженер в AppSec и пентестер. В большой корпорации мне пришлось столкнуться с колоссальными объемами API. Я быстро осознал, что в таких количествах их просто невозможно проверить вручную, и начал искать способы автоматизации. В результате уже больше двух лет я занимаюсь динамическим тестированием (DAST), в частности фаззингом.

В этой статье я расскажу, почему считаю DAST не менее важным, чем статический анализ кода (SAST), как новичку начать фаззить, а опытному специалисту научиться находить еще больше уязвимостей.

Данная статья будет полезна начинающим разработчикам игр, да и вообще, любым людям, кто хочет связать свою жизнь с программированием. Я постарался сделать статью интересной и полезной тем, кто не знает программирование, но знание хотя бы основ С++ увеличит удовольствие от статьи.

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

Друзья, привет! Давайте поговорим о том, как мы сами иногда мешаем своей карьере в разработке. Я замечал это и на себе, и на других — есть пять типичных ошибок, которые тормозят рост.

Многие до сих пор воспринимают IT-индустрию как пространство для молодых: стартапы, хакатоны, agile-команды и шумные open space. В голове автоматически возникает образ 20–30-летнего разработчика в худи. А если добавить, что речь о программировании на 1С, — так вообще большинство подумает о крепком мужчине предпенсионного возраста с двадцатью годами стажа в одной системе.

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

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

Разберемся вместе.

Хотите, чтобы статический анализ работал не только на ваших локальных машинах, но и прямо в Pull Request'ах? Чтобы баги ловились до попадания в главную ветку, а не после? В этой статье покажем, как это сделать на конкретном примере пайплайна в GitHub Actions.

Привет, Хабр!

Сегодня мы рассмотрим nullable-аннотации в C#: как с помощью [MaybeNull] и [NotNullWhen] (плюс родственных атрибутов вроде [MaybeNullWhen], [NotNullIfNotNull], [DoesNotReturn]) формально описывать те самые «ну тут иногда null, а тут точно нет».

На сцене Conversations в этот раз собрались эксперты из SberAI, Авито, Т-Банка и Raft, чтобы вместе с Just AI обсудить автономных агентов с суперпамятью, вызовы vibe-coding и новую эру кибербезопасности. Вашему вниманию — расшифровка интереснейшей дискуссии!

О скорости изменений в индустрии и методах отслеживания важных технологических релизов, перспективах вычислительной революции, альтернативах NVIDIA и безопасности LLM, подходах к вайбкодингу в разработке и кейсах применения AI-ассистентов и многом другом.

Какими инструментами для линтинга и форматирования Python-кода вы пользуетесь? Black, Isort, Flake? Их существует множество, каждый следует своей цели, некоторые могут пересекаться по функциональности. Одни могут нравиться за автономность, другие — за возможности конфигурирования. И наверняка вы слышали о Ruff, который обещается заменить собой все.

Привет, Хабр! Я Гена, Python-разработчик в Selectel. В этой статье я опишу свой опыт перевода проекта на Ruff: что понравилось, что — не очень, к чему готовиться и, если все же решитесь, то как это сделать. Добро пожаловать под кат.

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

Итак, без долгих предисловий:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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