Факап в студию! Кажется, на канале появляется новая рубрика: любимая для меня, интересная и полезная всем, кто делает проекты — реальные факапы и выводы из них. Я пришел к тому, что мне познавательно и увлекательно читать разборы ошибок и сложных ситуаций в проектах других компаний (не обязательно из сферы разработки) и смотреть, какие решения они находили. Во-первых, на чужих ошибках действительно полезно учиться — свои, как правило, обходятся значительно дороже. Во-вторых, сама ошибка не всегда сразу подсказывает решение, поэтому особенно ценен опыт тех, кто уже через это проходил. Решил, что не менее важно делиться и своим опытом. Поэтому буду периодически публиковать такие истории здесь. Ниже — несколько кейсов из нашей практики. Все персонажи не вымышлены, все совпадения с реальными проектами не случайны. Факап №1. а голову вы дома не забыли или...Да, мы забыли про нагрузочные тесты на проекте Ты проверил. Тестировщик проверил. Заказчик проверил. Жена заказчика проверила. Все довольны, всё работает. Выкатываем на прод. Приходят реальные пользователи — и всё ложится. Потому что одно дело, когда по сайту ходят три человека и нажимают кнопки по очереди. И совсем другое — когда пятьсот пользователей одновременно отправляют запросы к базе, загружают файлы и дёргают API. Ирония в том, что нагрузочное тестирование — это не какая-то сложная космическая технология. Часто достаточно пары скриптов, которые можно прогнать перед релизом и понять, где система может спотыкаться, но в запаре его почему-то всегда откладывают на потом. Но в реальности это почти всегда откладывается «на потом». А «потом» — это уже продакшн и реальные пользователи, которые вместо интерфейса видят 502 Bad Gateway. Нагрузочное тестирование обязательно должно быть в чек-листе запуска проекта наравне с бэкапами, проверкой SSL и другими базовыми вещами, если ожидаете поток пользователей. Факап №2. один в поле воин кодит или...Один разработчик замыкает на себе на весь проект Ключевой разработчик практически в одиночку вел весь проект: серверную часть, бизнес-логику и интеграции. Документации, конечно, не было — «да всё понятно, потом разберёмся». А теперь представим ситуацию: разработчик заболел, ушёл в отпуск, отлучился по личным делам — в общем, произошло что-то из категории жизнь, оставшаяся команда оказалась перед чужой кодовой базой и с дедлайном через две недели. Разбирались долго и болезненно, проект сдали с серьёзным опозданием, клиент — ожидаемо — остался недоволен. Вывод довольно простой: всегда должен быть второй человек, который понимает архитектуру проекта и может подхватить работу. Код-ревью, парное программирование, хотя бы минимальная документация ключевых решений — это не бюрократия. Это страховка от ситуации, когда весь контекст проекта находится в голове одного разработчика. Факап №3. назад в прошлое или...Миграция данных из старой системы Каждый раз, когда в проекте есть этап «перенести данные из старой системы», мы знаем, что будет больно, но каждый раз недооцениваем, насколько. Данные в старых системах живут своей жизнью. Даты могут быть в трёх разных форматах, телефоны записаны как попало, а в одном поле спокойно уживаются email и текст вроде «перезвонить Наташе». Плюс кодировки могут меняться от таблицы к таблице. Ситуация: пишешь скрипт миграции, он отрабатывает, данные переносятся, всё выглядит нормально. А через неделю выясняется, что часть записей тихо потерялась, потому что в каком-нибудь поле встретился спецсимвол, который сломал парсинг. После нескольких таких историй мы начали относиться к миграции как к отдельному подпроекту. Считаем количество записей до и после переноса, сверяем контрольные суммы, делаем пробную миграцию на копии данных и обязательно даём заказчику время на проверку, прежде чем отключать старую систему. Потому что миграция данных — это почти всегда отдельное расследование!