Самые сложные ошибки - это самые глупые ошибки. В такие моменты, кажется что все пошло не так. Но чуть немного спокойствия, дебага и ошибка легко решается. Поэтому мне кажется полезной статья It's Always Something Stupid и я привожу ее свободный перевод.

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

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

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

Я уверен, вы догадываетесь, что в бэкенд половине были разработчики, которые предпочитают другой фреймворк (чтобы не вступать в холивары, я не буду называть какой). По мере того как дедлайн приближался, команда все сильнее ощущала давление: так всегда происходит независимо от того насколько готов проект. В один день, кто-то открыл проект и начал тестировать его в Safari. До этого я не тестировал особенно работу в Safari, но я знал, что наше приложение работает в Safari без каких-либо серьезных проблем.

Когда кто-то обнаружил, что у нас есть серьезная проблема с производительностью в Safari, я сразу понял, что что-то изменилось: или произошло какое-то обновление в Safari, и мы словили его эффект, или что-то поменялось в нашем коде. В этот момент, даже я впал в ступор. Хотя такая ситуация случается настолько часто, что можно было бы уже научиться обходить их. Можно было бы уже научиться переводить "Все пошло не так и у нас нет идей как это исправить" в "что еще мы можем попробовать, чтобы уточнить в чем проблема". Вместо этого, я вижу что обычно разработчики впадают в депресию и начинают воображать самое худшее, что могло случиться.

Конкретно в этом случае, нам понадобилось несколько сообщений, чтобы дойти до того, что во всем виноват AngularJS. Кроме, того не успокаивали высказывания типа "нам понадобится переписать все приложение с нуля". Обычно, в такие моменты я просто молчу, но в тот раз я не выдержал и обозвал всех паникерами. У меня не было даже предположения, что это может быть, но я знал , что это что-то очень глупое. Я проработал на два часа больше обычного, чтобы заставить как можно скорее стихнуть эти истеричные вопли.

Несмотря на то, что тысячи проектов на AngularJS прекрасно работают в Safari, я просто чувствовал необходмость доказать, что возможно решить Эту-ужасную-фундаментальную-ошибку-использования-AngularJS-который-самый-худший-выбор-из-всех. Конечно, когда я нашел то, что вызывает проблемы в при работе в Safari, это была просто глупая ошибка.

http://codepen.io/Chevex/pen/PqXoGb

Если вы откроете пример в последнем Safari, то браузер зависнет у вас. Если вы подождете достаточно долго, то все начнет работать, но будет виден большой лаг. Даже в последнем Chrome, есть большой лаг.

Проблема заключается в применении комбинации CSS3 text-shadow и 500px ширины к элементу, который скашивается. Как только я убрал text-shadow, то все стало работать прекрасно.

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

Такое поведение не является чем-то уникальным. Я видел его снова и снова, на каждом корпоративном проекта. Я и сам демонстрировал его несколько раз, хотя я надеюсь, что я повзрослел с последнего раза.

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

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