Основные стратегии и принципы для менее напряженной отладки

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

Ошибки. Они неизбежны. Точно так же, как большая часть написанного - это доработка, большинство программ требует отладки. Это означает, что у разработчиков есть множество возможностей противостоять нашему собственному пониманию. Это великолепно. Ладно, не всегда кажется прекрасным. Если мне удастся перенять еще один писательский трюизм от Дороти Паркер, я ненавижу отладку - мне нравится отлаживать. И хотя я иногда пытался спорить или даже торговаться со своим ноутбуком, я никогда не находил это особенно эффективным методом. К счастью, у нас есть много инструментов и стратегий, которые намного эффективнее. Ниже я расскажу о некоторых, которые я нашел особенно полезными для достижения желанного состояния отладки.

Но сначала ... у вас есть время поговорить о модульном тестировании?

Написать тест

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

Прочтите сообщение об ошибке

Теперь предположим, что мы не написали тесты или мы просто люди, кодовая база которых не достигла 100% покрытия. Если мы столкнемся с нашей ошибкой в ​​«дикой природе», мы, скорее всего, столкнемся с полезным сообщением, показывающим нам ошибку нашего пути… более или менее. Сообщения об ошибках могут быть представлены в виде загадочных однострочных строк, компьютерного эквивалента пожатия плечами или устрашающих стен текста с множеством каскадных сбоев. Однако, как минимум, попробуйте посмотреть на самый верх. Первая проблема, с которой столкнулся компьютер, может быть источником проблемы. Даже если он сам по себе не поможет, он, вероятно, предоставит вам номер файла и номер строки; это отличное место для начала.

Поищи в Гугле

Если вы новичок, то шансы, что с нашей проблемой никогда раньше не сталкивались, довольно низки. Стоит положиться на мудрость тех, кто приходил раньше. Добавление ошибки в Google, скорее всего, вернет множество блогов, проблем с GitHub и сообщений о переполнении стека по аналогичным проблемам. Небольшое исследование может иметь большое значение, чтобы указать вам правильное направление.

Проверить на опечатки

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

Сделайте свои собственные утверждения о вводе и выводе

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

Проверьте свой ввод

Достаточно часто ошибки могут быть результатом неверных предположений о форме наших данных. Это особенно верно, если мы получаем эти данные из внешнего API или передаем их через обратные вызовы или реквизиты React. В случае внешних API-интерфейсов, возможно, стоит использовать такой инструмент, как Postman, чтобы ознакомиться с тем, как данные структурируются по мере их поступления. Если наш ввод находится внутри компании, мы всегда можем вернуться к print / console.log внутри нашей функции. Или мы можем двигаться дальше с помощью инструмента, специально созданного для этой работы…

Отладка с помощью отладчика

Что это в имени? В данном случае это неплохой намек. Если наши входные данные соответствуют нашим ожиданиям, но мы все еще не получаем желаемого результата, возможно, пришло время притормозить. Будь то временная ошибка для Ruby, pdb для Python или просто старый отладчик для JavaScript, у нас должна быть какая-то утилита для установки точек останова в нашем коде. Это позволяет нам заморозить наш код в определенной точке и взглянуть на внутреннюю работу нашей функции, чтобы увидеть, как наши переменные выглядят в любой момент времени. Помните имя файла и номер строки из сообщения об ошибке? Строка перед этим может быть хорошим местом для начала.

Проверьте свою логику

Если мы зашли так далеко, наши данные выглядят нормально, а наши переменные складываются, пора рассмотреть возможность того, что мы действительно ошибаемся. На этом этапе есть несколько вариантов, которые сводятся к более четкой формулировке ожиданий. Иногда все, что нам нужно, чтобы увидеть проблему в нашей логике, - это услышать ее объяснение. Мы можем начать с резинового утки - просто обсудите свой мыслительный процесс с любым старым неодушевленным предметом. Я лично использую стресс-медведь:

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

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