Работа в заказной разработке часто связана с факапами, но признаваться в них почему-то считается моветоном. Мы в Mad Brains решили перешагнуть через этот стереотип и выложить карты на стол. Готовы поделиться, в какие переделки попадали и как исправляли баги. Аналитикам и разработчикам будет полезно.
Для начала немного вводных: а на каких этапах могут всплывать ошибки?
Интервью
Если после встречи с заказчиком становится ясно, что в логике приложения есть несоответствия или мы собрали недостаточно данных, надо вернуться к клиенту за уточнениями. Иногда его триггерит, но по факту — это самые безобидные потери. Факап во время проектирования ТЗ или разработки — намного хуже.
Проектирование/разработка
Допустим, это случилось. Если ошибка была обнаружена разработчиком, то переработка одного или нескольких связанных блоков займут время, иногда много времени. Это может сказаться и на бюджете исполнителя в целом.
Тестирование
Не так страшно для заказчика, как для айтишников. Приходится тратить дополнительное время на фиксы багов. Если ошибка серьезная, в зону риска опять же попадают сроки и бюджет проекта.
Ошибки после релиза
Самый худший сценарий: если проблема найдена после того, как проект выкатили в прод, значит аналитики сработали плохо. Ошибки исправляются за счет исполнителя.
Баги на практике, реальные кейсы Mad Brains
Кейс 1. E-commerce-проект
Дано: еком-проект, у которого есть сайт и мобильное приложение. Оба работают на одной базе данных, что и логично.
Задача: клиент попросил срочно поменять данные на сайте.
Решение: быстро переделали структуру базы данных под новый контент.
Баг: структура стала подходить только под одну площадку, а мобильное приложение сломалось, потому что ему изменения не требовались.
Как исправляли: пришлось перерабатывать решение, потратили лишнее время и деньги. Да и пользователи 5 звездочек приложению не поставили.
После ситуации стало очевидно, что «хотелка» заказчика — это, конечно, святое, но сначала надо проверять, как она может отразиться на проекте в целом.
Кейс 2. Мобильное приложение для бронирования отелей
Дано: заказчик, который хотел приложение для ведения гостиничного бизнеса.
Решение: приложение было создано, успешно протестировано, отправлено в прод.
Баг: не учтен запрет на букинг номера через мобильное приложение. То есть пользователь бронирует номер, но на деле он уже забронирован другим человеком.
Как исправляли: добавили блокировку кнопки «Забронировать» при созданной заявке на фронте. Если номер забронирован, на бэке больше заявок создано быть не может.
На будущее:
— добавили груминг. Созвон с командой помогает быстро получить обратную связь от разных специалистов. Бэк может предложить лучшее решение, разработчики — сказать, как именно будут реализовывать фичу;
— начали подключать тестировщиков на вычитку спеки. Они круто отлавливают баги еще на этапе прочтения документов.
Кейс 3. Изменение API метода авторизации в мобильном приложении
Дано: мобильное приложение, вход в которое осуществляется по номеру телефона и паролю.
Задача: добавить вход по коду.
Решение: задачу выполнили, выпустили релиз, поменяли метод. Обновленное приложение работало, НО пользователи старых версий мобильного приложения «отвалились».
Баг: не указали требования к обратной совместимости, не учли, что прежние пользователи остались со старой авторизацией.
Как исправляли: добавили версионность методов и вернули поддержку предыдущего. Финансовые потери небольшие, но негативных отзывов от пользователей отхватили.
В качестве работы над ошибками:
— завели чек-лист компонентов системы, в котором отмечали, на что могут влиять изменения;
— добавили схему архитектуры;
— внедрили практику синхронизации между командами в виде звонков и ревью. Теперь в обсуждении предстоящих изменений участвуют представители разных команд.
Кейс 4. Проект в сфере инвестиций
Дано: проект, связанный с безопасностью системы.
Задача 1: добавить интеграцию между двумя сервисами для последующей агрегации данных.
Её решение: добавили метод для одного из сервисов, откуда требовалось «забирать» операции.
Баг: после реализации заказчик обнаружил, что данные перебрасываются по эндпоинту без токена авторизации. Оказалось, что это не было описано в требованиях, а человек, знающий или подобравший метод, может легко забрать все операции из сервиса (например, через постман).
Проблему решили, финансовых последствий удалось избежать, но были рядом.
Задача 2: на том же проекте должен был появиться личный кабинет с данными по операциям в портфеле клиента и возможностью их отображения в виде графика. Ранее они хранились на другом сервисе и в другом формате. Нам предстояло «забрать» оттуда исторические данные в определенном формате.
Её решение: мы договорились передавать данные сообщениями в очередь, чтобы распределить нагрузку на систему. Очередь спроектировали в rabbit и проверили на тестовых данных.
Баг: пришло время подключать на прод, но появились безопасники со стороны старого сервиса, которые сказали буквально следующее: данные у нас есть, но мы вам их не отдадим, так как в сообщении присутствуют чувствительные данные.
Как исправляли: данные готовились вручную и передавались в архиве с письмом от руководителя. Очередь пришлось «выпилить», а данные маппились руками. Получили финансовые потери на реализацию фичи и её «выпиливание».
Кейс 5. Электронная площадка для проведения аукционов
Дано: электронная площадка для проведения аукционов, монолит, Git на проекте отсутствовал.
Задача: аналитик попросил разработчика сделать бэкап системы перед публикацией очередного набора функций.
Решение: аналитик сделал архив всей площадки и оставил ее в корневой папке.
Баг: папка, увы, оказалась доступна без авторизации. К вечеру следующего дня кодовая база всего проекта была обнаружена в неком телеграм-канале. Пришлось выплатить штраф, сопоставимый с бюджетом проекта.
Как показывает наш опыт, проблема может возникнуть там, где ты ее не ожидал. Пусть этот честный рассказ поможет вам быть начеку и во всеоружии!