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

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

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

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

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

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

Политика на улице

Надпись на стенке «За Россию без Путина»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вторая:

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

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

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

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

День выборов

На этих выборах есть три возможных стратегии:

1. Проголосовать за Путина.
2. Проголосовать не за Путина.
3. Не пойти на выборы.

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

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

Понятно, что в ходе голосования будут фальсификации. Понятно, что выборы нечестные. Что выборов нет вообще. Но это слабая причина, или даже отговорка, чтобы не ходить на голосование. Как говорит Белковский, «классический принцип традиционной этики состоит в том, что делай, что должен и будь что будет». Отказываясь от голосования мы точно ни на что не можем повлиять.

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

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

Собираем долги после обедов с коллегами

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

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

Хочется ненавязчивого контроля. Чтобы о возврате денег не приходилось вспоминать самому. Чтобы деньги собирались с минимальными усилиями (записывать куда-то долго, требуются волевые усилия). Со временем я выработал элементарную систему. Она удовлетворяет перечисленным требованиям и ничего не стоит.

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

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

Иногда коллеги забывают вернуть деньги. Я прихожу и говорю:
— Слушай, мы в понедельник были в «желтых дверях», и, похоже, ты не перевел мне деньги. Вот чек. В истории переводов у меня пусто.
— Да? Сейчас посмотрю. А, да, сейчас переведу, извини.

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

Уравнение Максвелла

Центральное место на этой фотографии занимает формула $$\nabla\cdot\vec{B}=0$$ на разрисованной стене.

Это одно из уравнений Максвелла в дифференциальной форме. Вероятно, оно должно вдохновлять играющих на площадке детей.

Здесь нет выхода

Поиграл на рояле

Позавчера летел из Кишинева. Зал вылета был полон. Подошел к бизнес-залу. Он был перекрыт (видно на фото справа). Девушка за стойкой информации сказала, что он на реконструкции.
— А у вас рояль стоит, на нем можно поиграть?
— Да, можно.
— Стоит два евро, — добавил сотрудник аэропорта, стоящий рядом.
— Два евро?
— Да шутка это, — улыбнулся он.

Сыграл несколько композиций с перерывами на голосовые объявления. В конце несколько человек похлопали, одна женщина поблагодарила :)

WSL: Линуксовая подсистема в Windows

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

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

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

Так или иначе, проблема удобной настройки окружения для веб-разработки на PHP была решена только в Windows 10. В ней появилась линуксовая подсистема, или WSL. Она позволяет запускать скомпилированные для линукса бинарники. При этом ядро линукса отсутствует, а системные вызовы к нему на лету транслируются в Win API. В общем, WSL — это Wine наоборот.

Несколько лет после выхода линуксовая подсистема была в состоянии беты, и пользоваться ей было невозможно. Но, начиная с Creators Update, выпущенного в апреле, ситуация изменилась, и nginx вместе с php-fpm нормально заводится и работает.

С практической точки зрения WSL — это командная строка bash, в которой можно устанавливать любой пакет из репозитория Ubuntu 16.04 через apt install. Диски компьютера примонтированы и доступны в файловой системе через /mnt/c, /mnt/d и т. д.

Ребята из Микрософта нацеливались на «интероперабельность»: из bash можно запустить не только линуксовые elf-бинарники, но и обычные exe-файлы. Процессы могут без проблем работать друг с другом. Например, мне было лень делать дамп и переносить базу данных, и я оставил ее в Windows. К ней успешно подключается php-fpm.

Я перевел ежедневную работу на линуксовую подсистему. Обнаружил две проблемы. Первая: не работают unix-сокеты. Решается использованием TCP-сокетов в конфигурации php-fpm и nginx. Вторая: nginx падает при загрузке файлов, из-за того что вызывает нереализованную функцию. Решается запуском встроенного в PHP веб-сервера при тестировании загрузки файлов. Ситуация у меня возникала редко. Может быть ее уже исправили, а я об этом и не знаю.

Еще есть особенность: не работают средства автозапуска программ. Пришлось добавить команды service start nginx в .bashrc.

И еще есть баг. Через некоторое время процесс beam начинает загружать процессор. Приходится останавливать сервис rabbitmq.

Положительные моменты: можно выкинуть MinGW, виртуальные машины и прочие попытки завести bash на Windows, и работать в полноценной линуксовой консоли. Софт в среде разработки идентичен софту на боевом сервере и обновляется одной командой apt upgrade.

Спустя три года я всё-таки перешел на Windows 10, линуксовая подсистема стала в этом решающим фактором.

← сюда туда →