Проблемы будут всегда. И это нормально. Вы можете их избегать или научиться их решать.

Когда я начинал работать программистом ASP.NET была проблема, которую я решал около 3 недель! Почему так долго – потому что не было навыка решения проблем. Сейчас большинство проблем решаются автоматически или организационно (это тоже решение, просто на другом уровне).

Здесь мы рассмотрим подходы или принципы, как решать технические проблемы в проекте. Затем мы рассмотрим конкретные инструменты, которые мы применяем для локализации и устранения ошибок.

Найти и обезвредить

Обработка любой ошибки всегда проходит 2 этапа: сначала надо найти место где эта ошибка возникает и затем исправить.

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

Добейтесь устойчивой ошибки

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

Если же не удается четко установить критерии возникновения ошибки, то вероятнее всего здесь может быть 2 причины:

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

Ищите разницу

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

Чудеса на серверах

Запомните раз и навсегда, что здесь нет места чуду и магии.

Машина работает детерминировано. Это значит, что  у каждого следствия есть своя причина.

Если у вас произошла ошибка, что-то периодически работает неверно или приложение неожиданно выдало 503 ошибку – это следствие каких-то внутренних процессов веб-приложения. И надо копать глубже, а не ссылаться на мифологию.

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

Машина тупит

Очень связано с предыдущим. Запомните: машина никогда не тупит.

Тупить может только программист, которой за ней сидит. Машина в принципе не может ошибаться, т.к. она не создает самостоятельно новую логику. Всю логику ее работы закладываем мы и именно здесь могут быть проблемы.

Большинство возникающих проблем – это не проблема сбоев аппаратной части или операционной системы (ее тестируют 1000 раз в отличие от вашего кода), а проблема кода с ошибками. Первое что вы должны сделать – это проверить свой код, и только потом можно начинать искать ошибки в системном окружении вашего приложения. В первую очередь тестируйте недавно добавленную логику – высока вероятность, что ошибка занесена только что (ведь до этого как-то это работало, верно?).

Копайте вглубь

Чем лучше вы понимаете как работает веб-приложение, тем проще вам найти ошибку и правильно ее устранить.

Узнайте все нюансы работы приложения и изучите самые типовые ошибки на различных участках. Например, у неопытных программистов бывает так, что просто приложение долго не отзывается, а потом выдает ошибку. Что это может быть? Первое, что нужно проверить – это соединение с базой (у которой есть обычно таймаут подключения в секунд 30).

Проработайте основные опорные точки, где могут возникать проблемы, и тогда вам будет гораздо проще и быстрее икать типовые ошибки.

Систематичные ошибки

Если вы по ходу своей работы вы замечаете за собой, что постоянно допускаете примерно одни и те же ошибки – проанализируйте их. Почему они возникают? Как этого избежать? В какой области у вас больше всего ошибок (циклы, верстка, JS, SQL запросы и т.д.)?

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

Даже если не удается совсем избегать их ошибок – научитесь хотя бы быстро решать их и находить.

Большинство ошибок является типовыми, поэтому просто анализируйте свой опыт – это очень хороший источник своего развития в плане мастерства разработки.

Google & Stack Overflow

Это самый простой способ решить ошибку. Просто грамотно на английском напишите описание своей ошибки и скорее всего вы очень быстро найдете ее на этих двух сайтах. При достаточном опыте вам даже не нужно будет читать полностью описание ошибки – просто ищите решение с зеленой галочкой – скорее всего это будет то, что вам нужно.

Еще важный момент – это не злоупотребляйте Google для базовых и дурацких ошибок. У меня довольно часто на собеседовании люди порываются в Google для задачи «Добавить div в body через jquery». При этом пишут, что опыт у них 6 лет по jquery. Для меня это до сих пор непонятный парадокс – как может человек за 6 лет так и не научиться на память писать такие простые базовые вещи.

Если вы будете постоянно обращаться к справочникам – это очень сильно снижает вашу скорость и производительность. Поэтому старайтесь запоминать найденные решения. В будущем при столкновении с этой проблемой вы уже сможете ее решить не прибегая к Google.

Через некоторое время вы будете помнить большинство решений типовых ошибок (а их все таки не так уж и много, думаю не более 500) – ваша производительность в разы возрастет. А теперь представьте, если я дам тому 6-летнему разработчику задачу по разработке JS движка для каталога – скорее всего он еще 6 лет будет это разрабатывать, постоянно сидя в Google.

Обработка ошибок-исключений

При работе мы всегда должны учитывать, что могут возникать ошибки и умело обрабатывать их. Для этого обычно используются блоки try catch. Такой момент – если вы можете обойтись без try cacth (т.е. обработать неверную ситуацию с помощью if, и выдать соответствующее сообщение пользователю) – то лучше так и сделать. Это связано с тем, что try catch  – одна из самых медленных операций на сервере (что в большинстве случае не так критично, т.к. обычно есть более медленные участки – запросы к базе, загрузка данных в браузер  и т.д.).

В нашей практике мы используем специальную функцию для всех блоков try catch – RDL.Debug.LogError – ей передается переменная типа Exception. Что делает эта функция – она записывает в базу информацию по ошибки и данным запроса, а также делает отправку данных на почту. Это довольно удобно в том плане, что вы можете оперативно реагировать на возникающие ошибки в запущенном в эксплуатацию приложении.

Важный момент – вы должны везде ставить блоки try catch и в них обрабатывать эти исключения. Обычно имеет смысл ставить обработку исключений в BLL уровне. Подобной обработки вполне достаточно для отлова и обработки ошибок.

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

Также можно указывать специальный код ошибки, чтобы при ее возникновении пользователь мог его вам сообщить, и вы однозначно могли сразу сказать где произошла ошибка – т.е.  по сути сразу локализовать проблему. В JS вы также можете обрабатывать ошибки.

Для этого надо просто отправлять запросы на сервер, который будет также вызывать RDL.Debug.LogError(ex). В нашем модуле as.sys.js предусмотрена такая функция. Единственный момент – если проблема с сетью, то постоянно при отправке уведомления об ошибке будет вызываться обработка ошибки – т.к. бесконечный цикл. Выход из этого – отправка ошибок через увеличивающийся интервал (1 секунда, 2, 4, 16, и т.д.).

Таким образом, вы не будете грузить браузер при таких проблемах. Подобная практика внедрена в as.sys.js в функции ajaxSend – можете посмотреть и взять на вооружение. Если вы работаете на нашей библиотеке as.js – то используйте try catch и функцию обработки as.sys logError.

Далее рассмотрим отладку и трассировку.