Один раз отмерь, семь раз отрежь: как ошибаются крутые IT-специалисты

Не учёл обратную совместимость и слишком рано выложил на прод

Сейчас мы работаем над системой обработки платёжных транзакций. В одном из тикетов надо было поменять способ хранения суммы транзакции — сколько денег ушло и в какой валюте. Я создал новый тип Amount и добавил его везде, где требовалось. So far, so good.

Плюс я добавил новый тип и удалил старые поля в одном из объектов, которые использовались для передачи данных между нашими модулями. В итоге мы успешно прошли тесты: правда, в лабораторных условиях все модули устанавливались одновременно и только после этого тестировались. А на проде всё посыпалось.

Следите за руками: обновлённые клиенты отправляют объект в новом формате, с новым полем amount (и без старых полей); обрабатывали же этот запрос ещё не обновлённые сервисы, которые про новое поле не знали и поэтому не могли десериализовать полученные объекты. Пока мы откатывали обновление, на этом сервисе потерялось несколько сотен транзакций.

Закончился кофе — и проглядел старый код

Первый комментарий героя. Это клиника.

Второй комментарий героя. А если серьёзно, то это банальная невнимательность. Закидывая впопыхах новый код, проглядел, что остался мелкий кусок старого.

В итоге получилось что получилось: когда формировался объект конфигурации для запуска браузера, добавлялись шрифты. Правда, сразу же после этого шрифты удалялись :) Такое иногда происходит даже с опытными программистами. Просто косяки случаются на более сложных тасках и в более напряжённых условиях — например, когда горят сроки или начинается завал с другими задачами. Ошибка получилась настолько нелепой, что мозг просто отказывался верить в её существование. Поэтому поначалу я ещё и всем яростно доказывал, что всё ок.

Забыл, что строки сравниваются между собой лексикографически

Как-то раз меня подловили на очень глупой ошибке вопросом: «А как ты ограничил версию в этом отчёте?» Я понял, что в процессе обработки, когда нужно было оставить данные с определённой версии (например, с версии 12.0 и выше), я использовал просто условие version >= "12.0". Но строки сравниваются между собой лексикографически, и поэтому, например, 2.0 будет выше, чем 12.0! При этом даты в формате ISO 8601 очень даже можно сравнивать и лексикографически — всё проходит корректно.

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

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

Написал не самый лучший код

В первом варианте у меня появилась квадратичная сложность из-за spread-оператора (многоточие). По сути, reduce уже и так перебирает массив, а spread-оператор в этом случае просто копирует его. Он проходит по очереди по исходному массиву и добавляет в текущий каждый элемент исходного. То есть его сложность О(n).

Reduce тоже проходит по исходному по очереди. И его сложность тоже O(n). Когда здесь используется spread, то заново перебирается массив. Из-за этого на каждую итерацию перебора массива на верхнем уровне совершается полный цикл перебора массива на нижнем уровне.

То есть по массиву длиной в 10 элементов первый вариант кода пройдёт 100 раз. Кажется, что это не слишком много, но, когда массив состоит из 1000 элементов, итераций будет уже 1 млн. А это серьёзная нагрузка.

Второй вариант кода мало кто написал бы с ходу — сейчас не так сильно пекутся о скорости работы приложения. И я бы даже не назвал это ошибкой, поэтому и обозначил просто как плохой и хороший код. Почему сразу не написал хорошо? Да просто не знал, что можно сделать лучше.

Стоит ли бояться ошибок?

Опытные программисты легко говорят о своих ошибках — не стыдятся этого, охотно делятся опытом и советами. Поэтому, если хотите быть такими же крутыми, как герои этой подборки, — не закрывайте глаза на собственные фейлы, учитесь работать с ними и извлекать из них пользу.