Фортепиано ★

Позавчера улетел из Кишинева. В зале вылета опять поставили рояль. Не очень хотелось кому попало давать мобильник для съемки ролика. Вместо этого записал игру на своем инструменте. Это хорошо известная композиция:

А это новая композиция. С помарками, но зато сейчас, а не еще через три года:

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

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

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

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

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

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

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

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

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

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

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

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

• планирование,
• ежедневный скрам («стендапы»),
• демонстрация новой функциональности заказчикам и пользователям
• ретроспектива.

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

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

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

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

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

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

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

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

Дизайн новых указателей в московском метро

Представьте, что вы едете с Войковской на Речной вокзал. Это на север, дальше от центра. Спускаетесь по лестнице в потоке других пассажиров. На платформу прибывает поезд. Нужно ли на него поспешить? Или вам в другую сторону?

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

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

Старые указатели не имели таких проблем. Сразу ясно, что в центр — 1 путь, направо.

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

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

Связь с водителем о выходе

Пятиминутка паранойи

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

Пришлось заклеить.

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

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

Популярные песни сегодня и 20 лет назад

Рик Беато сделал два микса из 20 песен, популярных сегодня и в 1998 году.

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

Серебристые облака

Давно мечтал увидеть серебристые облака. Один раз вроде как видел и сфотографировал. Но облака были не очень хорошо видны. И фотоаппарат был так себе. А теперь получилось. Вот они:

Москва, прошлая ночь, после 1:00.

Отменная кнопка

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

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

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

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

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

Написано верно. Такому алгоритму и нужно следовать, исправляя баги. Но что делать, если баг воспроизвести нельзя? Я расскажу об одном таком баге, с которым пришлось бороться в 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-контейнеру и доставал оттуда сервис.

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

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

• Подробности о переходе от императивного кода к объектному, SOLID, DTO, DI в скринкасте по рефакторингу с помощью PHP Storm
• Еще одна байка из CityAds на хабре: PHP, статические переменные внутри методов класса и история одного бага

Небо над Москвой — 2

Традиционное фото на 9 мая:

← сюда туда →