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

Когда тест проходит с первого раза — это пугает. Стоицизм в TDD — не методология, а форма выживания.

Статья Парнаса «О критериях...» давно стала классикой, на которую постоянно ссылаются, но мало кто ее реально читает. Высказанные в ней идеи о «сокрытии информации» как основе модульности упоминаются повсеместно, однако оригинальный текст с его тщательной аргументацией и яркими примерами остается для многих терра инкогнита. Данный перевод призван восполнить этот пробел.

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

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

Всем привет! Меня зовут Михаил, я веду Telegram-канал «Python Шпильки», где делюсь изящными приемами программирования. Сегодня я хочу рассказать об универсальном декораторе, который может принимать аргументы, а также вызываться без их приема. Для тех кто хорошо знает тему декораторов - ничего нового они тут не увидят! Этот пост для тех, кто, возможно, хочет более подробно понять тему декоратора. Итак, поехали.

Для начала приведу пример конструкции универсального декоратора:

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

Как и любой инструмент, её можно использовать правильно или неправильно. Чаще всего дефолтная подсветка выглядит как новогодняя елка, что делает текст трудночитаемым. Давайте посмотрим, как изменить это.

Думаю, вам начинают надоедать тексты про вайб-кодинг. Но не волнуйтесь, мой интерес не в том, чтобы рассказывать о новых невероятных достижениях, меняющих мир, и бла-бла-бла... Интереснее поискать места, в которых начинается сбой при генерации кода. Это позволит адаптировать работу статических анализаторов для новых задач контроля кода, который создаётся с помощью таких систем.

Блог Михаила | Python | Разработка | Best Practices

"Всем привет! Меня зовут Михаил, я веду Telegram-канал «Python Шпильки», где делюсь изящными приемами программирования. Сегодня хочу показать один из самых полезных паттернов..."

Писать код с LLM — очень легко, просто и весело. Не нужно мучаться с документацией, не нужно фиксить баги. Вообще ничего не нужно. Только инструкцию в чат написать. Раз-два — и всё готово. Заманчиво? Да. Но у всего есть цена — и про неё важно помнить.

Сейчас разберём, как именно AI-агенты могут сломать твой прод и что можно сделать, чтобы очередной вайб-кодинг не превратился в катастрофу. В конце — чеклист, который поможет не упустить ничего важного.

Всем привет. Меня зовут Аня (SavAnna) я работаю AppSec и как хобби занимаюсь багбаунти. Багбаунти - отличный способ отдохнуть от своих сервисов и сменить фокус с "защиты" на "нападение". Не всегда баги ищутся целенаправленно - иногда это происходит случайно. Хочу показать, что много странных и простых багов может найти каждый.

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

Если коротко, процесс выглядит примерно так: сначала думаем — потом пишем. Но с приходом ИИ-кодинга всё изменилось.

Привет, Хабр! На связи Галина Чупрова, главный инженер по тестированию в Рунити. Сегодня расскажу, как мы в компании пришли к тестированию документации — и почему этот шаг повысил эффективность тестирования и сэкономил команде нервы.

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

Вы только приступили к изучению структур данных? Хотите освежить знания, полученные в ходе обучения? В этой книге нет заумной математики, скучных доказательств и абстрактной теории. Вместо этого — понятные объяснения, рабочие примеры и реальные кейсы, с которыми ежедневно сталкиваются разработчики. Вы узнаете, как с помощью правильных структур данных ускорить поиск, эффективнее управлять очередями задач или, например, оптимизировать хранение данных.

Книга построена по принципу «от простого к сложному»: начинается с базовых структур, таких как массивы и связанные списки, и постепенно переходит к более сложным — стекам, очередям, деревьям, хеш-таблицам и графам. Каждая глава содержит практические примеры, упражнения и наглядные иллюстрации, которые помогают закрепить материал. Вся теория подкреплена примерами на Python — одном из главных языков современной разработки.

Если вы хотите не просто использовать структуры данных, а понимать их и применять осознанно — эта книга для вас.

В предыдущей статье "Адаптированный паттерн Command с использованием Dependency Injection", я описывал как инкапсуляция логики приложений в отдельные объекты-функции позволяет получить преимущества в архитектуре приложений.

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

Эта статья пытается исправиль допущенную автором ошибку.

Статья является дополнением к предыдущей.

Всем привет. Меня зовут Аня (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!