Пять простых правил отладки для начинающих программистов



    От переводчика: Джордж Алан Хеймел в своей статье делится собственным опытом и говорит о том, чем должен руководствоваться разработчик в процессе отладки.

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

    Skillbox рекомендует: «Мобильный разработчик PRO».
    Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».

    Правило 1. Всегда есть причина


    Несмотря на утверждения вроде «Это невозможно», «Оно не должно работать так», «Нет причины, чтобы этот код не работал».

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

    Отступите, сделайте глубокий вдох. Затем посмотрите на код снова. Не надейтесь лишь на инструменты. Используйте мозг и логику. Подумайте, как текущий элемент, над которым вы работаете, влияет на все остальное. В большинстве случаев ошибка относится к классу ПМСИС (проблема — между стулом и столом).

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

    Правило 2. RTFM & WTFV


    Большинство разработчиков — умные люди. Иногда даже слишком умные, во вред себе. Все мы думаем, что не нуждаемся в базовых туториалах, можно ведь сразу начать изучение продвинутых вещей.

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

    Поэтому усвойте правило, которое на английском языке звучит, как Read the F***ing Manual or Watch the F***ing Video (отсюда и сокращения в подзаголовке).

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

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

    Правило 3. Пожалуйста, используйте правила 1 и 2




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

    Правило 4. Изучайте изменения


    В процессе работы случается так, что инструменты, которые вы используете, изменяются. Если вы веб-разработчик, это утверждение особенно актуально — JavaScript-фреймворки, библиотеки и инструменты очень часто изменяются и обновляются.

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

    Ищите информацию о своей проблеме или изменениях в инструменте, пока не найдете. Если ничего нет, перечитайте правило № 1.

    Правило 5. Отдохните и начните с самого начала


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

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

    Просто не смотрите на экран. Поговорите с коллегой, посидите в тишине, ведь шум действует негативно. Перекусите, в конце концов. Если время позволяет, просто поспите, забудьтесь крепким и глубоким сном. Иногда мне удавалось найти ответ на мучающий меня вопрос после сна.

    Очистите свою голову от всей мишуры и мусора предыдущих попыток найти ошибку и посмотрите на проблему с неожиданной стороны.

    Ну а затем… да, вы верно угадали. Возвращаемся к правилу № 1.

    Skillbox рекомендует:

    Skillbox

    171,00

    Онлайн-университет профессий будущего

    Поделиться публикацией
    Комментарии 10
      +3
      Правило 5 — самое действенное, я бы передвинул его в начало! =)
        0
        Так вы никогда не найдете ошибку в коде, и будете вечно ее искать.
          +1
          Ну хорошо, не в самое начало.
            +1
            Тогда до последних пунктов вы никогда не дойдете.
              0
              Просто мой личный опыт, когда что-то работает не так как надо, и я решаю передохнуть и еще раз пройтись дебаггером после отдыха, в очень большом проценте случаев, во время отдыха вся картина складывается вдруг в голове и без всяких средств отладки я вдруг понимаю где ошибка.
          0
          Я бы не сказал, что оно действенное само по себе. Можно очень долго дебажить кругами, да так ничего и невыдебажить.

          Я бы дополнил его (лично выстраданным) правилом «разделяй и властвуй». Если причины проблем не ясны и сложны для выявления — имеет смысл идти от обратного, и определять блоки, где проблем точно нет. Ну а дальше — отсёк то, отсёк это, и смотришь уже не на двадцать тыщ строк кода в трех разных технологиях, а на сто и в одной.
          +1
          Информацией о проблемах и наработках они делятся на соответствующих ресурсах вроде Experts Exchange и StackOpen или на профильных форумах.


          Ну ладно, Experts Exchange действительно есть такой сайт (хотя я не знаю, кто им реально бы пользовался, платный сайт QA? Странная штука, которую я никогда до конца не понимал), но что такое StackOpen, я так и не понял. У меня ощущение, что автор имел ввиду сеть сайтов Stack Exchange в общем и Stack Overflow в частности.
            +2
            ошибка относится к классу ПМСИС (проблема — между стулом и столом)
            По-моему, не стоило переводить PEBKAC, RTFM же оставили.
            RTFM & WTFV
            WTFV — нет такого термина, если автор выдумал его пытаясь показаться смешным/умным, то ему это не удалось.

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

            Для меня самым действенным является метод утенка, особенно если он «говорящий», а уж если это коллега, так еще и чему-то новому научишься.

            Все остальные советы либо очевидны до банальности (отдохните или отвлекитесь? спасибо кэп, вот никогда бы не догадался), либо редки или специфичны.
              –1
              WTFV — нет такого термина

              Наверное автор хотел сказать не WTFV, а STFW — Search The Fucking Web. Это обычно советуют, когда кто-нибудь задает тупейший вопрос, который легко гуглится.
                +1
                Как раз хотел написать то же самое.
                Как в такой статье можно не упомянуть метод утенка?! Тащат на Хабр всякие шлак ради ссылочек в конце.

                Кстати, WTFV все же, видимо, есть.

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

              Самое читаемое