Сайт Романа ПарпалакаБлогКлючевые словаработа программиста

работа программиста

Воскрешение access-токенов

10 ноября 2023 года, 17:15

Недавно Фёдор Борщёв написал о том, что разделение на access-токены и refresh-токены не очень-то и нужно, можно обойтись каким-то одним. На тему токенов я вспомнил об одном приеме для повышения надежности приложений в ситуациях, когда сервис авторизации недоступен.

У нас на работе для единого входа в приложения (SSO) и получения ролей используется Keycloak. В целом он работает нормально, но иногда подтекает по памяти и начинает отвечать ошибками типа 502. В этот момент приложение тоже становится недоступным: когда истекает время жизни access-токена, приложение запрашивает новый токен, получает ответ 502 и по умолчанию падает на неперехваченном исключении. Простой приложения влечет остановку основного бизнес-процесса и прямую потерю денег.

Чтобы уменьшить влияние недоступности сервиса авторизации на работающее приложение и предотвратить потерю денег, мы придумали переиспользовать истекшие токены и назвали этот прием «воскрешением». Время жизни access-токена продлевается на TTL, если сервис авторизации возвращает ошибку с кодом 5xx. В воскрешении важно не переусердствовать, коды ошибок 4xx не должны разрешать пользователю продолжать работу.

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

Разумеется, события воскрешения токенов регистрируются в мониторинге, на них установлены уведомления в рабочие чаты. График в мониторинге во время инцидента может выглядеть примерно так:

На графике красным отображаются воскрешения токенов, желтым — запросы новых access-токенов, зеленым — получение новых токенов после редиректа. Видно, что часть пользователей испытывала проблемы со входом, и для них воскрешались токены. После исправления проблемы события воскрешения токенов прекратились и пользователи массово получили новые токены.

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

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

    Оставить комментарий

Храните состояние долгоживущих процессов в базе данных, а не в памяти

15 апреля 2023 года, 00:47

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

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

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

Какие преимущества получаем от хранения состояния долгоживущих процессов в базе данных?

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

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

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

Наблюдаемость состояния в админке. Когда состояние хранится в базе данных, его легко вывести в админке. Таким образом, вы сделаете работу приложения наблюдаемым. Иначе ваше рабочее время будет уходить на однотипные вопросы коллег, реагирующих на обращения пользователей: «что случилось с заявкой №782354, запрос ушел, но ответа не было?»

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

    Оставить комментарий

Мониторинг производительности приложений в New Relic

26 марта 2023 года, 00:03

New Relic — это набор инструментов для обеспечения «observability» веб-приложений, то есть наблюдения за их внутренним состоянием. Для меня самый полезный инструмент — APM, или мониторинг производительности.

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

Зачем нужен мониторинг производительности

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

Первый полезный экран — список запросов к базе данных. Можно выбрать какой-либо запрос (на скриншоте запросы на чтение к таблице users) и увидеть среднее время выполнения в миллисекундах (query time) и количество запросов в минуту (throughput). Кроме того, есть разбиение по источникам запросов (time consumption by caller), в котором видно, с каких страниц идут выбранные запросы.

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

Третий полезный экран — список «транзакций». Под транзакциями нью-релик понимает действия в веб-приложении. Они делятся на веб-транзакции (обычно запросы и ответы через веб-сервер) и фоновые транзакции (обычно запуски консольных скриптов). По транзакциям также выводится их количество и среднее время выполнения (читай время ответа веб-приложения). Кроме того, доступна детализация, в которой видно, какие запросы или обращения к внешним системам происходят именно в этой транзакции и как долго они выполняются. Например, вот детализация по ответам публичной части моего сайта:

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

Например, на скриншоте выше время ответа веб-сервера составляло целых 4 секунды, а причина тому — запрос к БД. Сам запрос тоже можно открыть:

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

Установка и настройка

Установка нью-релика на сервер состоит из двух несложных частей (уровня apt install). Во-первых, нужно установить демон, который отвечает за отправку данных на серверы нью-релика. Во-вторых, нужно подключить нью-релик к вашему веб-приложению. Для PHP нью-релик устанавливается как расширение (*.so) и начинает работать после того, как вы скопируете в php.ini лицензионный ключ из личного кабинета на сайте. Расширение отправляет данные в процесс демона (очевидно, через сокет), а демон пересылает данные асинхронно. Благодаря такому подходу нет заметной просадки производительности.

Расширение нью-релика автоматически определяет и регистрирует запросы к базам данных, запросы через curl к внешним системам. Оно даже понимает, какой фреймворк используется, и берет названия маршрутов (routing) как названия транзакций. Данные на всех скриншотах выше собраны автоматически, для их сбора я ничего дополнительно не настраивал.

Продвинутое использование через API

Расширение нью-релика предоставляет API. Через него я определял свои транзакции из долгоживущих процессов и регистрировал метрики. Например, в сервисе генерации формул я профилирую некоторые шаги генерации как будто это обращения к некоторым базам данных (за это отвечает функция newrelic_record_datastore_segment(); возможно, тут подошли бы другие функции, но меня и так всё устраивает):

<?php

class Helper
{
    public static function newRelicProfileDataStore(callable $callback, string $product, string $operation, string $collection = 'other')
    {
        if (\extension_loaded('newrelic')) {
            return \newrelic_record_datastore_segment($callback, [
                'product'    => $product,
                'operation'  => $operation,
                'collection' => $collection,
            ]);
        }

        return $callback();
    }
}

// запуск внешнего процесса
Helper::newRelicProfileDataStore(
    static fn() => shell_exec($command),
    'shell',
    Helper::getShortCommandName($command)
);
                
// запрос по http на localhost
$optimizedSvg = Helper::newRelicProfileDataStore(
    fn() => file_get_contents($this->httpSvgoUrl, false, $context),
    'runtime',
    'http-svgo'
);

// "долгая" операция сжатия
$gzEncodedSvg = Helper::newRelicProfileDataStore(
    static fn() => gzencode($optimizedSvg, 9),
    'runtime',
    'gzencode'
);

Результат на скриншоте. Мы видим, что шаг по запуску латеха и генерации dvi-файла занимает примерно столько же, сколько отрабатывает dvisvgm. А на оптимизацию получившегося svg-файла времени тратится немного (к тому же она еще и в фоне происходит).

Выводы

Мониторинг производительности — один из инструментов для обеспечения «наблюдаемости» внутренней работы приложений. Другие инструменты — это мониторинг технических и бизнес-метрик, логи, визуализация внутреннего состояния в административном интерфейсе. Но эти инструменты нужно вручную добавлять в код, они не появляются в момент инцидента. Если вы не залогировали событие, вы не узнаете, произошло ли оно. Если храните состояние в памяти процесса, а не в БД, не сможете сделать sql-запрос и получить это состояние. А на этапе разработки приложения заранее непонятно, что именно окажется полезным в логах, а что нет.

Нью-релик как расширение к языку программирования автоматически встраивается в ваше приложение и начинает собирать информацию о типовых событиях, таких как запросы к базам данных и обращения по HTTP ко внешним сервисам. Таким образом, он работает «на будущее»: во время инцидентов у вас уже будет информация о том, что происходит внутри приложения, были ли изменения и в какой момент, и на основе этой информации вы сможете отсеивать неправдоподобные гипотезы о причинах и фокусироваться на правдоподобных.

Я не знаю, есть ли альтернатива сервису APM нью-релика. Если вдруг знаете — напишите в комментариях. На волне «импортозамещения» мы аналогов не нашли. Но зато я узнал о бесплатной квоте в 100 гигабайт, что вдохновило меня написать эту заметку.

    Оставить комментарий

Алгоритмическая сложность

1 марта 2021 года, 22:31

Одна из тем, которые я обязательно поднимаю на собеседовании, — это сложность алгоритмов. Кандидату на мои вакансии достаточно назвать сложность наилучшей сортировки — O(n·ln n). Еще о структурах данных речь заходит при обсуждении работы индексов БД. Кандидат должен объяснить, за счет чего индексы ускоряют выполнение запросов.

Если кандидат не дает ответа O(n·ln n), это тревожный звоночек. В зависимости от вакансии я могу еще попросить оценить сложность простейшей сортировки, например, пузырьком, чтобы отличить пробел в знаниях от неспособности понимать эту тему.

Почему важно иметь представление об алгоритмической сложности? Что будет, если писать код без этого представления? Недавно нашелся пример: если на рабочем столе создать 1000 файлов, Windows тратит 20 секунд на открытие главного меню. И всё потому, что какой-то криворукий программист написал алгоритм сложности O(n2) там, где можно было обойтись O(n). Подробности читайте на хабре.

    2 комментария

О тестовых заданиях на собеседованиях программистов — В кресле препода №4

14 сентября 2020 года, 22:32

Я провел много собеседований. Несколько десятков, или даже около сотни. К сожалению, с самого начала подсчитывать не догадался. Точное число было бы интересным.

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

Кстати, видео снимал по методу Ильи Бирмана.

    Оставить комментарий

Бэкенд и фронтенд в одном репозитории

9 февраля 2020 года, 23:36

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

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

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

    Оставить комментарий

Не храните бизнес-логику в базе данных

6 августа 2019 года, 11:46

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

Я расскажу, почему в промышленном программировании так делать не надо.

Масштабирование производительности. У приложений и базы данных различные возможности масштабирования при росте нагрузки на систему. Для масштабирования обычных приложений на современных фреймворках достаточно запустить несколько копий на разных серверах. А база остается одна. Чтобы снизить нагрузку на чтение, применяют репликацию master-slave. Снизить нагрузку на запись не так просто. Но, возможно, к этим методам не придется прибегать, если не создавать лишнюю нагрузку на базу данных и держать бизнес-логику в приложении.

Масштабирование разработки. Когда вы разрабатываете систему сами, вы используете любые инструменты на свое усмотрение. Когда вы нанимаете разработчиков, лучше применять стандартные общепринятые инструменты. И баги с боевой системы проще воспроизводить локально, когда бизнес-логика располагается только в коде.

Автоматизация разработки. БД как хранилище данных — стандартная практика. Для упрощения разработки в такой парадигме есть развитые инструменты — библиотеки ORM, которые умеют, в частности, автоматически генерировать скрипты миграции структуры БД. Изменение бизнес-логики в коде облегчается средствами среды разработки: автодополнением, автоматическим рефакторингом. Пользовательские функции в БД придется изменять полностью вручную.

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

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

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

Я помню, как на прошлой работе в CityAds в проекте была одна InnoDB-табличка на несколько сотен записей. Она пополнялась из триггера при изменении записей в другой таблице. Но иногда вставки по непонятным причинам не происходило.

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

Админы подтвердили, что это известная проблема в MySQL 5.6, но быстро перевести production на 5.7 они не могли. Пришлось переключить тип таблицы с InnoDB на MyISAM. Проблема исчезла.

Не храните бизнес-логику в базе данных.

    Оставить комментарий

Работа над задачами в скраме

26 января 2019 года, 18:03

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

Бэклоги продукта и спринта

По скраму задачи на разработку образуют бэклог продукта. Бэклог содержит все требования к продукту и эволюционирует по мере развития бизнеса. За ведение бэклога отвечает владелец продукта, даже если ему в этом помогают другие участники команды. На планировании владелец продукта и команда разработки совместно формируют бэклог спринта, то есть определяют, какие задачи будут взяты в спринт.

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

У доски проходят ежедневные 15-минутные встречи команды — стендапы. Разработчики обязаны присутствовать на этой встрече, они по очереди рассказывают о прогрессе в достижении цели спринта. Остальные участники процесса могут посещать стендапы без права голоса.

Предыдущие версии руководства предписывали каждому разработчику команды ответить на стендапе на 3 вопроса:

  • Что я сделал вчера, что помогло команде разработки приблизиться к цели спринта?
  • Что я сделаю сегодня, чтобы помочь команде разработки достичь цели спринта?
  • Вижу ли я какие-либо препятствия, которые могут помешать мне или команде разработки достичь цели спринта?

В 2017 году в руководство внесли изменение, по которому команда сама определяет формат встречи. Я объясняю это изменение расширением области применения скрама.

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

Критерии готовности к разработке (DoR)

Зрелая команда берет в спринт только проработанные задачи. Команда сама вырабатывает критерии готовности к разработке (definition of ready, DoR) с учетом особенностей проекта и предметной области. Пример:

Критерии готовности

  1. Команда разработки понимает бизнес-ценность задачи.
  2. У задачи понятное описание.
  3. К задаче приложены макеты всех новых экранов.
  4. В описании задачи указаны критерии приемки.

Если на проработке задачи «сэкономили», то на выяснение требований, согласования и переделки потеряется больше времени. Скрам-мастер объясняет постановщикам задач, что критерии готовности — это не капризы разработчиков. Пример:

Почему важно прорабатывать задачи

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

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

Критерии приемки проясняют, какие функции требуются заказчику. Просматривая критерии приемки, программист проверяет, всё ли он сделал. А еще критерии приемки — пошаговая инструкция тестировщику.

Команда оценивает только готовые к разработке задачи. Команда объясняет владельцу продукта или заказчику, почему задача не готова, и что надо уточнить.

Зачем оценивать задачи?

Для быстрой обратной связи владельцу продукта и заказчику о сложности задач. У нас в CityAds был образцовый иллюстрирующий случай.

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

На демонстрации заказчик был недоволен.
— Почему вы не сделали отчет?
— Приоритет формы добавления рекламодателя был выше.
— Мы думали, что вы быстренько сделаете форму и начнете делать отчет. Если бы мы знали, что добавить форму так сложно, отложили бы. Нам нужен отчет.

Оценка задач в часах

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

Оценка задач в стори-поинтах

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

Объем работ больше, если в задаче надо сделать пять экранов, а не два.

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

Риски на неопределенность выше, когда приходится использовать новую технологию или дорабатывать незнакомый код.

Стори-поинты нужны, чтобы сравнивать задачи друг с другом, поэтому абсолютное значение стори-поинта не важно. Для начала использования сопоставьте 1 стори-поинт несложной типовой задаче. Затем группируете выполненные задачи по условной шкале: чем правее задача, тем сложнее.

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

В случае затруднений с оценкой команда ищет на шкале похожую по сложности задачу и определяет будущее место для оцениваемой задачи.

Важно ограничить возможные значения стори-поинтов. Обычно используют числа Фибоначчи (слегка измененные: 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100) или степени двойки: чем больше соседние числа, тем больше интервал между ними. Иногда числа вообще заменяют на обозначения размеров одежды: S, M, L, XL, XXL.

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

Когда оценки расходятся, команда обсуждает причину расхождения. Возможно, кто-то не до конца понял, что нужно сделать. Или кто-то знает более простой способ реализации. Затем карты кидаются заново, пока оценки не совпадут. Некоторые команды договариваются о допустимости расхождения на одну ступень в обе стороны. Например, при раскладе на картинке выше итоговая оценка команды — 5.

Бывают менее однозначные ситуации.

Здесь потребуется дополнительная проработка задачи: уточнение требований у заказчика, разбиение крупной задачи на несколько частей. Когда команда не знает, как делать сложную задачу, она берет в спринт «ресёрч» — задачу на исследование. Как и любая работа в спринте, ресёрч оценивается в стори-поинтах. На выходе ресёрча — готовая к разработке задача (удовлетворяющая DoR).

Как оценивать задачи и планировать спринт?

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

Фокус-фактор — это доля времени, которая уходит на разработку запланированных задач, от общего рабочего времени. Например, фокус-фактор 0,5 означает примерно одинаковую долю условной разработки и поддержки. Хорошим считается значение 0,7.

В начале перехода на скрам в CityAds наша команда начинала с фокус-фактора 0,3. Больше половины рабочего времени уходило на исправления багов и поддержку.

Чтобы исправить ситуацию, всю поддержку пользователей пустили через систему тикетов и первую линию поддержки. Для решения повторяющихся однотипных запросов к разработчикам стали делать автоматические инструменты. Через несколько месяцев фокус-фактор вырос до 0,5.

Если считаете, что разная производительность разработчиков сводит на нет адекватность оценки в часах, выбирайте стори-поинты. Вас не будет вызывать технический директор и спрашивать, почему оценили задачу в 4 часа, когда ее можно сделать за 10 минут.

Планировать спринт в стори-поинтах помогает понятие производительности команды (velocity). Это сумма оценок в стори-поинтах выполненных в спринте задач. Если команда не успела в течение спринта полностью выполнить задачу, стори-поинты задачи потеряны.

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

Мы в CityAds в течение года после внедрения скрама пришли к совмещению двух методов оценки. Оценивали бэклог продукта в стори-поинтах, чтобы владелец продукта и заказчики знали «вес задач» и определяли приоритеты. На планировании разбивали задачи на подзадачи, назначали на исполнителей, исполнители давали оценку в часах. Пример:

Подзадачи
Проектирование — Коля (1 час)
Бэкенд — Коля (2 часа)
Фронтенд — Леша (4 часа)
Ревью — Рома (1 час)
Тестирование — Настя (2 часа)
Документирование — Коля (2 часа)
Выкладка — Рома (1 час)

После этого трекер рисовал диаграмму загруженности каждого участника. Мы понимали, как перераспределить работу, и успеем ли всё сделать:

Диаграмма сгорания, впихинг и скрам

На стендапах полезно визуализировать оставшийся объем работ в спринте на диаграмме сгорания («бёрндаун-чарт»). В идеале объем равномерно уменьшается каждый день. На практике, когда команда успевает выполнить все задачи, в конце спринта объем работы уменьшается быстрее, и график получается примерно таким:

Иногда получается, что график на диаграмме сгорания растет:

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

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

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

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

Мы подробно рассмотрели две обязательных встречи по скраму — планирование и стендапы. В следующий раз поговорим об оставшихся двух — демо и ретроспективе.

    1 комментарий

Введение в скрам

5 января 2019 года, 22:35

— Проверено. Дать гению пять человек в подчинение, поставить четкую задачу и попросить организовать работу. Через неделю гений сам всё про себя поймет.
— Гений не поймет, он объяснит, какой народец некондиционный, читайте всё в блоге гения.

Баш

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

Зачем нужен скрам

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

Команда и спринты

Рабочая единица по скраму — скрам-команда. Она состоит из трех частей:

В команде разработки у всех одинаковая роль — «разработчик». У каждого разный опыт и уровень экспертизы, и это влияет на конкретный вид выполняемой работы. Но ответственность за результат у команды общая.

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

В скраме нет менеджеров. Традиционные обязанности менеджера частично выполняет скрам-мастер, частично — сама команда разработки. Каждый участник достаточно взрослый, чтобы работать без напоминаний со стороны. Команда самостоятельно координирует свою работу.

Рабочий процесс по скраму делится на итерации — спринты. Команда разработки создает и в конце спринта поставляет заказчику некоторую завершенную функциональность — инкремент продукта.

Вот обязательные встречи в течение спринта, без которых у вас не будет скрама:

Планирование

На планировании присутствует команда разработки и владелец продукта. Владелец продукта описывает потребности бизнеса на следующий спринт. Команда разработки определяет, успеет ли выполнить соответствующие задачи, и выбирает способ реализации. Также владелец продукта и команда разработки выбирают цель спринта.

Вот что написано о цели в руководстве:

Цель Спринта — это установленный для Спринта ориентир, который достигается посредством выполнения части Бэклога Продукта. Цель Спринта формулируется во время его Планирования и объясняет Команде Разработки, для чего создается Инкремент.

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

Цель связана с наиболее приоритетной задачей, но не тождественна ей. Польза выбора цели в дополнительной синхронизации ожиданий. Например, на планировании выясняется, что команда разработки скорее всего не может «сделать фичу и выложить в бой», потому что другая команда должна доработать АПИ, админы — запустить новый сервис и т. д. Но по-другому сформулированная цель — «сделать фичу и продемонстрировать на тестовом окружении» — достижима, и на текущий спринт устраивает заказчика, который сам хочет всё посмотреть в действии до выкладки.

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

В следующий раз я расскажу о стендапах и о работе с задачами по скраму.

    Оставить комментарий

Исправляем баги с помощью рефакторинга

29 мая 2018 года, 23:42

Василий Половнёв в советах рассказывает, как исправлять баги:

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

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

Когда причина обнаружена, остаётся устранить баг и порефлексировать: что пошло не так, почему, как сделать так, чтобы в будущем таких багов не было.

Написано верно. Такому алгоритму и нужно следовать, исправляя баги. Но что делать, если баг воспроизвести нельзя? Я расскажу об одном таком баге, с которым пришлось бороться в CityAds.

Симптом

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

Попытка воспроизведения

Баг не повторяется ни на локальной копии сайта, ни на тестовых стендах, ни на российском сервере. Воспроизводится, только если напрямую зайти на бразильский сервер. Вышеприведенный алгоритм бессилен.

Изучение кода

К сожалению, в CityAds было много legacy-кода. Логика обработки смс-кода была размазана по двум местам: генерированию кода перед его отправкой и проверке этого кода при вводе. В реализации присутствовали многие признаки говнокода. Код написан в контроллерах без дополнительных уровней абстрацкии, в императивном стиле. Время отправки, сумма к выводу и id внешнего счета хранились в разделяемой памяти — суперглобальном массиве сессии. Формат хранения — ассоциативный массив:

$_SESSION['sms_codes'][$account_id]['code'] = $code;
$_SESSION['sms_codes'][$account_id]['time'] = time();
$_SESSION['sms_codes'][$account_id]['amount'] = $amount;

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

Говнокод плох тем, что он «одноразовый». Его просто написать, но сложно понимать и изменять.

Логирование

Когда баг нельзя воспроизвести локально, может помочь логирование. Чтобы понять, почему код работает не так, как ожидается, вы добавляете инстуркции для записи значений переменных в лог, например, в файл. Логировать полезно не все действия подряд, а только определенные, например, с вашего ip-адреса. Иначе в логах сложно разобраться.

Я залогировал значения переменных и увидел, что к моменту проверки кода в сессии было пусто, как будто код вообще не генерировался. Тем не менее, другие значения, не связанные с смс-кодами, в сессии присутствовали. Я не смог найти причину очистки. Код на серверах был одинаков. Сравнение конфигурации PHP ничего не дало.

Гипотеза

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

Я решил не искать, кто именно портит данные в сессии, а с нуля переписать обработку смс-кодов и уйти от хранения данных в сессии.

Рефакторинг

К этому времени мы подключили Symfony и писали новый код по принципам SOLID. Я написал сервис, в котором инкапсулировал логику работы с смс-кодами. Сервис принимал тройки значений (code, time, amount) в виде одного объекта (DTO), сохранял их в кеше (у нас был мемкеш) и при необходимости возвращал. Старый код через синглтон обращался к DI-контейнеру и доставал оттуда сервис.

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

Ссылки по теме

    Оставить комментарий

Промышленное программирование и область ответственности разработчика

25 марта 2018 года, 19:03

Промышленное прогаммирование

Хочу поделиться опытом промышленной разработки программного обеспечения. Под словом «промышленная» я понимаю разработку приносящего деньги продукта в коллективе от нескольких десятков человек.

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

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

Аджайл-манифест разработки программного обеспечения

Начнем систематизировать знания о разработке с аджайл-манифеста:

Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Это емкие, многогранные принципы. Мы к ним еще не раз вернемся. А пока посмотрим на одну составляющую первого принципа, а именно на то, как организуют взаимодействие с разработчиком.

Область ответственности разработчика

Недавно на хабре вышла статья про то, как Слак и мессенджеры вообще снижают продуктивность. В комментариях завязалась интересная побочная дискуссия. Первая точка зрения:

Никто никого не должен отвлекать по пустякам, вообще обычный разработчик должен в рабочее время заниматься только выполнением текущих запланированных задач и реагировать только на два типа сообщений:
1. Авария — что-то серьезное на продакшене или ошибка на уровне архитектуры, в первом случае срочно чиним, во втором останавливаемся и обсуждаем т.к. дальнейшая работа может просто оказаться бессмысленной. Если часто проблемы с продом — это чаще всего косяк тестировщиков, если хреново спланирована архитектура или выбраны не те инстументы — косяк архитекторов.
2. Блокировка — т.е. отсутствие реакции на это сообщение реально блокирует работу другого человека. Если есть большой поток блокирующих сообщений, то это либо отсутствие компетенции у других исполнителей — косяк того кто их нанял, либо хреновое планирование и распределение задач между исполнителями — косяк ПМа.

Если же разработчик вынужден по работе напрямую общаться с кем либо кроме ПМа и других разработчиков (например с заказчиками), то ему лучше сменить место работы!

Вторая:

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

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

Это два противоположных подхода к вопросу об области ответственности разработчика. Давайте выделим особенности каждого подхода:

Оператор ЭВМ Инициативный разработчик
Просит четкое техническое задание Просит объяснить бизнес-ценность задачи
Делает по требованиям, даже если они противоречат сделанному ранее Не любит переделывать
При обнаружении противоречий сообщает постановщику задачи
Не дает результат без менеджера и тестировщиков Работает самостоятельно
Знает, что значит «сделать»
Получает меньше денег Получает больше денег

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

Руководитель программистов должен учитывать при подборе и огранизации рабочего процесса особенности каждого способа. Первый свойственен водопадной модели, воторй — аджайлу. Если вы нанимаете инициативных разработчиков — готовьте бюджет. Если нанимаете операторов ЭВМ, нанимайте еще менеджеров и тестировщиков.

    Оставить комментарий

Программирование ≠ информатика

9 августа 2017 года, 00:03

На хабре перевод статьи некоего Коннелла о том, почему нельзя до конца формализовать и алгоритмизировать разработку софта:

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

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

  • Что должна делать эта программа? (требования, юзабилити, безопасность)
  • Как должна выглядеть программа внутри, чтобы её легко было починить и модифицировать? (архитектура, дизайн, масштабируемость, переносимость, расширяемость)
  • Как долго займёт её написание? (оценка)
  • Как мы должны её разрабатывать? (кодирование, тестирование, измерение, конфигурация)
  • Как следует эффективно организовать работу команды? (менеджмент, процесс, документация)

Все эти проблемы вращаются вокруг людей.

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

    Оставить комментарий

Как улучшить legacy-код

25 июня 2017 года, 21:15

Статья на хабре «Как улучшить legacy-код». Многим пригодится, потому что легаси-код есть в большинстве проектов. Особенно рекомендуется тем, кто сразу хочет переписать такую систему с нуля, едва столкнувшись с ней.

    Оставить комментарий

Закомментированный код

7 января 2008 года, 20:22

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

Участки кода в комментариях — удобный прием при отладке. В окончательной версии в комментариях должны оставаться только пояснения.

    Оставить комментарий
Поделиться
Записи