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

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

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

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

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

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

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

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

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

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

29 мая 2018 года, 23:42     промышленное программирование     Оставить комментарий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вторая:

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

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

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

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

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

25 марта 2018 года, 19:03     промышленное программирование     Оставить комментарий
Поделиться
Записи