Всем привет. Меня зовут Аня (SavAnna) я работаю AppSec и как хобби занимаюсь багбаунти. Хочу рассказать историю, когда сочетание простых багов, которые может найти каждый приводило к высокому импакту.
В одном сервисе, где можно было создавать и оплачивать заказы были найдены IDOR CRUD счета на оплату (далее инвойс) и особенности связи инвойса с созданным заказом.
"Запахи" в тестах — это полезные сигналы, которые важно уметь распознавать, чтобы писать удобные и легко поддерживаемые тесты. Мы уже писали про "запахи" в E2E-тестах; сейчас же рассмотрим распространённые ошибки, которые возникают при написании модульных тестов.
Хоть написание модульных тестов и является обычной практикой для программистов, тестовый код по-прежнему часто рассматриваются как код второго сорта. Между тем здесь, как и в любой области программирования, стоит знать паттерны и антипаттерны.
В книге Джерарда Месароша о паттернах в xUnit есть полезные главы о «запахах тестов», и в интернете можно найти много других полезных материалов по этой теме. Нам же показалось интересным подойти к этой проблеме не со стороны теории, а со стороны практики: какие частые ошибки можно встретить в тестах, как их исправлять, и почему именно тесты нужно писать так, а не иначе?
Мы разберём всё это на примере: напишем один модульный тест на JUnit, и по ходу дела будем исправлять возникающие ошибки. Код примера доступен на GitHub.
Хватит спорить — пора запускать и сравнивать.
Тестируем реальные сценарии, измеряем RPS, смотрим на потребление памяти и разбираемся, когда самая разумная стратегия — это просто подождать и обновить Python на free-threading версию.
Привет, Хабр! Меня зовут Игорь Анохин, я — руководитель платформенной разработки в K2 Cloud и более 8 лет программирую на Python.
Паттерн Command — широко известный и мощный инструмент построения гибких систем, позволяющий целиком вынести логику каждого метода в отдельный класс.
В статье показано как совмещение Command с Dependency Injection (DI) даёт дополнительные преимущества в архитектуре приложений.
Статья будет полезна разработчикам всех уровней, а также архитекторам приложений.
Технический вкус — это не то же самое, что технический навык. Вы можете быть технически подкованы, но иметь плохой технический вкус и наоборот. Как и любой вкус в принципе, технический вкус зачастую не зависит от наличия фактического навыка. Вы же можете отличить хорошую еду от плохой, не умея готовить? То же самое с ПО — вы вполне способны понять, нравится ли оно вам, не имея возможности его создать. И если технические навыки можно наработать через усердное изучение и повторение, то хороший вкус вырабатывается менее очевидным путём.
C# — гибкий язык. На нём можно писать мобильные и десктопные приложения, игры, веб-сайты, сервисы и API. Можно писать на нём, как на Java, со всеми абстракциями и AbstractionFactoryClassProvider. Но, в отличие от Java, на нём также можно писать низкоуровневый и небезопасный код. И когда я говорю о низкоуровневом, то имею в виду отсутствие сборщика мусора и сырые указатели.
Низкоуровневый код обычно требуется для высокой производительности или взаимодействия с библиотеками C/операционной системой. Низкоуровневый код помогает повысить производительность благодаря тому, что с его помощью можно избавиться от проверок доступа к памяти в среде исполнения.
Для безопасности доступ к элементам массивов выполняется в C# с проверкой границ. Но из-за этого страдает производительность, если только, конечно, компилятор не сможет избавиться от операции проверки границ. Логика устранения проверок границ должна гарантировать, что проверка границ индекса массива уже выполнялась раньше или что во время компиляции индекс точно будет находиться в границах. Для примера возьмём простую функцию:
Продолжаем изучать использование PVS-Studio на практике для бесплатных (и не только) проектов. В этой статье мы рассмотрим основной этап взаимодействия с инструментом — работу с отчётом! Подробно рассмотрим первый опыт разбора срабатываний, изучим интерфейс и посмотрим на ошибки в проекте osu!
Попробую на маленьком примере показать откуда берётся запутанный код.
Получаем задание от менеджера, для простоты это будет просто логическая функция. И пытаемся написать лучший код.
Для упрощения написания маленькая буква будет означать что условие ложно, а большая — что истинно.
Представляем функцию в виде карты Карно, чтобы оптимизировать всё что можно:
В области автоматического тестирования я работаю уже 15 лет. За это время я работал как в крупных компаниях, так и в небольших стартапах. Использовал различные языки программирования и технологии. Был частью разных команд — от специализированных групп разработчиков автоматического тестирования до смешанных команд, где вместе работали и разработчики, и тестировщики. За время карьеры занимал различные позиции и дорос до Senior Automation Engineer.
Оглядываясь на свой путь, хочу поделиться накопленными навыками и наблюдениями. Возможно, это поможет другим избежать подводных камней на карьерном пути и понять, к чему стремиться.
Разработка на Laravel становится максимально эффективной, если использовать автоматизацию на каждом этапе: от настройки окружения до проверки кода и тестирования. В этой статье я покажу, как построить процесс разработки, который снижает количество ручной работы, повышает качество кода и ускоряет выпуск функционала.
Материал рассчитан на разработчиков с опытом работы с Laravel, которые хотят внедрить автоматические проверки, статический анализ, единый стиль кода и готовую сборку Docker Compose для быстрого старта проектов. Я поделюсь своим опытом, конкретными инструментами и практическими примерами.
Да, это очередная статья по чистому коду. Но по разным источникам, соотношение времени, затрачиваемого на чтение и написание кода, может достигать 7 к 1 и даже больше. Когда вы исправляете ошибку, добавляете новую функциональность или проводите рефакторинг, вы сначала погружаетесь в логику, написанную другими людьми (или вами же, но несколько месяцев назад). Именно поэтому читаемость кода становится более важным фактором, чем скорость его первоначального написания. Нечитаемый код — это технический долг, который замедляет всю команду и увеличивает стоимость разработки в долгосрочной перспективе.
Здравствуйте!
В большинстве своём мы не думаем о том, как Go размещает поля структуры в памяти. И правильно делаем, пока наши структуры не используются в миллионах экземпляров, не передаются в каналах или не сериализуются каждую миллисекунду.
Также неправильное выравнивание может негативно сказаться на кеш-памяти процессора и скорости доступа к данным. На 32-битных платформах некорректное выравнивание 64-битных атомарных переменных (например, int64 для sync/atomic) вообще способно привести к панике.
В этой статье разберём выравнивание структур в Go, посмотрим на примерах влияние порядка полей и подумаем над тем, когда такие оптимизации действительно нужны.
В недавней публикации мы представили Tau² — инструмент для оценки больших языковых моделей. Сегодня же хотим поделиться неожиданным открытием: простое переписывание промпта увеличило успешность небольшой модели более чем на 20%. Ниже — подробный разбор того, как мы нашли и устранили узкое место в её работе, внеся всего несколько тонких изменений в политику агентов.
Здравствуйте! Антон Боев, исполнительный директор веб-интегратора DD Planet. В текущей статье поговорим о том, что внутри моей команды вызывает горячие дискуссии практически каждый день. Итак, речь пойдет об ИНТЕГРАЦИЯХ.
В нашей команде каждый день звучат одни и те же вопросы: «Как подключиться быстрее?», «Какую архитектуру использовать?», «Где взять устойчивое решение для этого сервиса?» Ответы на них не просто технические решения. Это опыт, который накапливается годами. И я хочу предложить вам посмотреть на него под неожиданным углом - как на криптовалюту веб-интегратора.
В этой статье я расскажу о том, как изменился процесс интеграции за десятилетие, почему одной API-документации уже недостаточно, и как мы превратили хаос интеграций в систему, которая работает надежно, прозрачно и масштабируемо.
Итак, начнем с анализа изменений в подходах и способах создания интеграций за последнее десятилетие.
Способы интеграций, есть ли изменения?
Организовать взаимодействие двух сервисов можно разными способами:
Статический анализ — это не только запуск проверки. Как обрабатывать отчёты, рассылать предупреждения разработчикам и визуализировать результаты? Рассказываем, как с помощью утилит и интеграций PVS-Studio превратить сырые данные анализатора в эффективный процесс улучшения кода.
Продолжаем изучать использование PVS-Studio для бесплатных (и не только) проектов. В этой статье мы разберём основные настройки анализатора и их важность, а также с чего стоит начать знакомство при первом запуске анализа на новом проекте.
Код-ревью убивает вашу команду. И вот доказательства.
Мы измерили. Один пулл-реквест крадет у компании 2.5 рабочих дня и 1.5 часа времени senior-разработчика. 70% комментариев в ревью — бесполезные споры о пробелах и запятых. Хватит это терпеть. Читайте мой разбор, почему код-ревью в Nomium стало главным тормозом разработки и что с этим делать.
Так или иначе, вайб-кодинг становится, — а где-то уже стал, — частью процесса разработки программного кода. Команда PVS-Studio видит в этом новые задачи для статических анализаторов по поиску ошибок в коде, возникающих при использовании ИИ-ассистентов и т.п. Первый шаг — собрать примеры реальных дефектов для изучения.
Отношение к вайб-кодингу и его вариациям неоднозначное. Я разделяю мнение, что использование сгенерированного кода, особенно без полного его понимания программистом, плохо скажется на надёжности и безопасности приложений. Так что работы у статических анализаторов только прибавляется :)
AI-сгенерированный код, возможно, будет содержать новые непривычные виды ошибок. Соответственно, чтобы их изучить и научиться выявлять, необходимо сначала собрать их коллекцию.
В сентябре 1985 года Джон Бентли опубликовал книгу Programming Pearls — сборник афоризмов об истинах в программной отрасли.
Прошло сорок лет. Наверняка спустя множество революций в нашей отрасли они потеряли актуальность? Эти советы относятся к той же категории, что и «всегда держи при себе пучок сена для лошадей» или «карманный калькулятор не всегда будет под рукой».
Ох, какая наивность! Ничто не ново под луной. Почти все приведённые афоризмы болезненно актуальны.
🚀 Как перестать бояться релизов и начать жить: практический гайд для тимлидов
Сбор практик для тех, кто хочет сделать доставку кода не болью, а удовольствием
Знакомая ситуация? Ваши релизы похожи на прыжок с парашютом без парашюта? Команда нервничает при каждом деплое, а бизнес теряет деньги из-за медленной доставки фич? Эта статья для вас.
Актуальность статьи: в современном мире скорость доставки фич — это не просто модный тренд, а вопрос выживания на рынке. Компании с быстрой доставкой обгоняют конкурентов по доходам на 20–40%.
Цель исследования — показать, как технические и управленческие практики влияют на ключевые бизнес-метрики и уровень счастья команды. Мы делимся реальным опытом из агротех-разработки.
Методология основана на практическом применении DevOps-практик и измерении результатов через метрики DORA. Мы покажем, как:
Trunk-Based Development сокращает время доставки на 30%
Feature Toggles делают релизы безопасными
Left-shifting тестирование снижает время восстановления с 15–20 часов до 1 часа
Kanban превращает хаос в прозрачную систему
Основные результаты демонстрируют, что быстрые релизы = быстрые проверки гипотез, маленькие партии изменений = дешёвые ошибки, частые деплои = счастливая команда.
P.S. Если вы всё ещё релизите раз в квартал — эта статья поможет вам пересмотреть свои подходы к разработке. 🎯
