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

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

Москва, прошлая ночь, после 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 мая:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вторая:

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

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

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

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

День выборов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

← сюда туда →