Многие до сих пор воспринимают 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. Сейчас пофиксим, а потом подумаем. Даже если предупреждение касается чего-то безобидного, один красный прямоугольник на фоне зелёных строчек может парализовать внимание.
Пересказываю культовую книгу Роберта Мартина "Чистый код" с примерами на C#. Узнайте, как создавать код, который читается как проза: от магии имен переменных и идеальных функций до безупречных тестов и архитектуры, которая не рухнет при первом требовании заказчика. Полный гид, ваш код станет предметом гордости, а не источником кошмаров.
Когда-то всё было проще. В достопамятные двухтысячные годы джунов и в самом деле нанимали. Не спрашивали о «релевантном опыте», не требовали ссылки на боевые проекты и не строили сложных лабиринтов из HR-интервью, технических сессий, тестовых заданий и многоступенчатых собеседований. Но прошло 15–20 лет — и всё изменилось до неузнаваемости. Новички (стажёры и джуны) теперь бесправны и даже подозрительны.
Компьютерная игра на Java — вещь довольно редкая, но всегда интересная. Поэтому мы не упустили возможность проверить статическим анализатором проект XMage и поделиться результатами. Посмотрим, что нашёл PVS-Studio в исходном коде проекта.
Давным-давно программный код хранился на перфокартах, но эти времена прошли и теперь мы храним код в текстовых файлах, что конечно же лучше. Но, может быть, пора сделать еще один шаг и начать использовать другой формат, более удобный?
Платформа Lovable, позиционируемая как low‑code решение для создания веб-приложений и сайтов, где основное взаимодействие с системой происходит через чат с искусственным интеллектом, столкнулась с критической уязвимостью, связанной с RLS-политиками. Она позволила получать и изменять данные без аутентификации — сотни проектов оказались под угрозой.
