День восемьсот девяносто третий. #Оффтоп #КакСтатьСеньором
Когда Дела Идут не по Плану
Когда что-то идёт не так, а такое рано или поздно обязательно случится, золотое правило - свести к минимуму влияние на клиента.

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

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

Странно, как мои естественные склонности и инстинкты расходятся с оптимальным решением. Думаю, что этот инстинкт также ведёт меня по более долгому пути в исправлении ошибок. Иногда мне кажется, что это не работает, потому что что-то не так с тем, что я написал, и я погружаюсь в исходники, просматривая каждую строку кода. Что-то вроде «поиска в глубину».

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

Теперь мой подход заключается в том, чтобы выполнять «поиск в ширину» перед «поиском в глубину», чтобы избавиться от узлов верхнего уровня. Что я могу проверить на верхнем уровне?
- Машина работает?
- Установлен правильный код?
- Конфигурация на месте?
- Правильно ли задана конфигурация для конкретного кода, например, правильная ли маршрутизация в коде?
- Обновлена ли база данных?
И только потом можно искать ошибку в коде.

«Мы думали, что nginx некорректно установился на машине, но оказалось, что просто в конфигурации было установлено значение false.»

Конечно, не нужно делать так всегда. Иногда достаточно просто сообщения об ошибке, чтобы сузить пространство поиска и сразу лезть в код.

Когда я не могу понять, в чём проблема, я стараюсь свести к минимуму изменения кода, чтобы выяснить, что не так. Чем меньше изменений, тем быстрее я смогу найти реальную проблему.

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

Источник: https://neilkakkar.com/things-I-learnt-from-a-senior-dev.html
Автор оригинала – Neil Kakkar