Недавно у нас была встреча разработчиков в моей компании, и мы обсудили качество нашего кода. Кажется, что из-за нашего стремления всегда выталкивать код за дверь, наше качество ухудшалось. Мы говорили о том, чтобы взять на себя ответственность за наш код (что всегда важно), более тщательную проверку кода и более тщательное тестирование. Я вышел из этого и чувствую себя прекрасно, в конце концов, мой код безупречный. Я чувствовал себя хорошо примерно до 5:30, когда обнаружил, что нумерация страниц на нашем мобильном сайте не работает. Поскольку я был в команде, выпустившей последнюю мобильную версию, я был не в восторге.
О чудо, ошибка была от бэк-энда. Я ВСЕ ЕЩЕ БЕЗУПРЕЧНЫ! Все, что нам нужно было сделать, это откатить изменения в серверной части, и мы вернемся к работе! Так было до тех пор, пока я не понял, что откат может нарушить мои изменения. Время исследовать!
Частично изменения в развертывании заключались в добавлении цветовых «образцов» под продукты, которые мы продаем. Сервер отправил данные в интерфейс React, которые затем были проанализированы и отображены. Соответствующий код:
Красиво, правда? Мы берем братьев и сестер, переданных с сервера, и используем map () для прохождения. Если у нас уже есть четыре, мы ничего не делаем, а для первых четырех мы возвращаем JSX с прикрепленными соответствующими классами. Все просто, правда? Проверено. Прошедший. Даже QA подумал, что это шикарно. Но что происходит, когда серверная часть откатывает свои изменения, а братьев и сестер больше не существует?
Оглядываясь назад, я понимаю свою роковую ошибку. Иногда я забываю о важности проверки ошибок. Мой код может работать в идеальном мире, но мир не всегда идеален. Частичный откат сейчас недоступен, потому что выполнение map () с неопределенной переменной вызывает ошибку и приводит к сбою приложения. Несчастный.
Лучшим подходом было бы провести там несколько проверок здравомыслия, чтобы ошибка в другом месте не разрушила весь дом:
Этот оператор if вверху? Это спасет приложение от сбоя. Мы могли бы даже пойти дальше и убедиться, что это массив. Если бы я нашел время, чтобы проверить поступающие данные, мы бы откатили изменения на сервере и пошли веселым путём. Как это есть? Что ж, если честно, все было не так уж и плохо. Они выпустили горячее исправление для исправления разбивки на страницы, поэтому в любом случае отката не потребовалось. Но все же это показало мне уязвимое место в коде. Тот, которого можно было бы легко избежать, если бы я нашел время, чтобы добавить простую проверку ошибок. Итак, на сегодняшний урок я усвоил: не нужно просто писать код, который не сломан, писать код, который нельзя сломать. Удачного кодирования!
