Освобождение
Решение проблем является неотъемлемой частью разработки программного обеспечения. Ошибки неизбежны, и постоянная возможность решать головоломки - одна из причин, по которой я люблю эту работу. Однако иногда мы зацикливаемся на особенно сложной проблеме, и это может расстраивать и разочаровывать. Ниже приведены некоторые методы, к которым я обращаюсь, когда это происходит со мной.
Подвергайте сомнению все, что вы " знаете”
Самые загадочные проблемы почти определенно имеют одну общую черту: то, что мы думаем, что знаем, неверно. С самого начала нет никакого способа узнать, что мы упустили, так что будьте хорошим детективом и считайте все подозрительным. Это включает в себя фрагменты кода, которые кажутся тривиальными или очевидными, а также все ваши инструменты (включая браузер!). Иногда решения самых загадочных проблем прячутся на виду.
Однажды я часами пытался понять, почему я не вижу обновлений на странице профиля пользователя, только чтобы со временем понять, что я вошел как другой пользователь. В другой раз я боролся до поздней ночи, пытаясь понять, почему новые записи не сохраняются в базе данных. Оказалось, я искал не в той базе данных. У меня таких примеров больше, чем я готов признать!
Это давняя традиция разработчика начинать с печати ваших переменных. Во многих случаях это сразу же раскрывает проблему. Но когда вы не находите то, что ищете, или то, что вы находите, не имеет смысла, возьмите подход выжженной земли к лесозаготовкам. Регистрируйте все, а потом еще немного. Начните с неожиданного результата и пройдите свой путь назад, записывая все, что вы можете, включая ценности, которые вы уверены, что знаете.
Если я прослежу проблему как можно глубже, а вещи по-прежнему не имеют смысла, то пришло время для некоторых проверок здравомыслия высокого уровня. Мой модульный тест на самом деле вызывает код, который я проверяю? Мой браузер действительно указывает на правильный экземпляр сайта? По моему опыту, иногда самые расстраивающие ошибки имеют самые простые (пропущенные) решения.
Очистить проблему
Иногда множественные факторы объединяются, как слои лука, чтобы создать ощущение единственной неразрешимой проблемы. В подобных ситуациях иногда полезно временно отвлечь внимание от заметной проблемы и вместо этого сосредоточиться на промежуточных факторах, мешающих работе. Например, если ошибка возникает только в удаленной среде, возможно, поиск файлов журнала является первым уровнем проблемы, которую необходимо решить.
Представьте себе сайт электронной коммерции с формой оформления заказа, которая выдает ошибку. Мой первый инстинкт обычно состоит в том, чтобы работать непосредственно к желаемому конечному состоянию. В этом примере это сосредоточит мое внимание на предотвращении ошибки. Но это может быть крайне неэффективно, если у меня нет простого способа отправить форму без фактической покупки. Иногда самый быстрый путь к решению выглядит косвенным и может даже включать временное «разрушение» вещей. Самый быстрый способ устранить ошибку оформления заказа - это сначала отключить платежный шлюз, чтобы я мог повторно отправить форму (не разорившись). Это может показаться регрессивным, потому что теперь две вещи «сломаны», но это значительный прогресс, если он приблизит меня к решению основной проблемы.
Когда я ловлю себя на том, что ворчу «если бы я только что…», я стараюсь остановиться и задуматься о том, что нужно для удовлетворения этой потребности. Есть ли доступный инструмент, который бы разблокировал меня? Есть ли пробел в моих знаниях, который заставляет меня догадываться о чем-то узнаваемом? Проще говоря: не позволяйте проблеме отвлекать от решения.
Подумайте о негативных фактах
Сообщения об ошибках и неправильные схемы размещения привлекают наше внимание. Но иногда мы можем извлечь важные уроки, даже если проблема не возникает. Термин « негативные факты» немного спорен в философских кругах, но для наших целей он просто относится к случаям, когда проблема не возникает .
Недавно я исследовал сайт, который загружался крайне медленно. Проблема была противоречивой, затрагивая небольшую, но устойчивую часть загрузки страниц, и мы изо всех сил пытались найти объяснение. Мы тщательно изучили все, что могли придумать, чтобы объяснить медленные ответы, но изучение «нормальных» ответов оказалось более плодотворным. В конце концов было обнаружено, что все эти запросы содержат заголовок, указывающий, что они попадают в кэш CDN. Эта подсказка помогла нам определить, что узкое место в производительности постоянно присутствовало на исходном сервере, но часто скрывалось уровнем кэширования. Это создавало иллюзию таинственных задержек, когда в действительности мы замечали отсутствие кеширования.
Если один и тот же компонент выдает ошибку на одной странице, но не на другой, возможно, на этой странице есть что-то особенное, что вызывает ошибку. Или, может быть, есть что-то особенное на другой странице, которое предотвращает ошибку. Если только некоторые пользователи сталкиваются с ошибкой, естественно сначала задаться вопросом, что у них общего? Но если вы не можете найти шаблон, не забудьте найти шаблон у всех пользователей, которые не сообщают о проблеме.
Простое упражнение, которое помогает мне мыслить таким образом, начинается с вопроса: «Если то, что я считаю правдой, то что еще мне следует ожидать?» Оспаривание моей рабочей гипотезы таким образом помогает мне избежать догадок, сравнивая мою теорию с доказательствами. Это также помогает мне заметить недостающие доказательства, и это отсутствие может быть столь же значительным.
Напиши вопрос
Форумы поддержки сообщества и сайты вопросов и ответов, такие как StackOverflow, являются невероятно мощными ресурсами в разных отношениях. Очевидно, на ваш вопрос может ответить полезный незнакомец, и это прекрасно. Но я делаю это даже для крайне непонятных проблем, на которые сообщество вряд ли ответит. Очень часто, когда я пишу свой вопрос, я рассматриваю проблему по-другому, чтобы я мог понять ее сам.
Раньше я считал это последним средством, к которому я обращался, только когда все остальное не работало. Но теперь я делаю это намного раньше в моей последовательности. Остановка для написания вопроса может показаться, что отладка проблемы занимает некоторое время. Но сам процесс написания вопроса является частью отладки проблемы, потому что хороший вопрос требует, чтобы вы переформулировали факты, суммировали то, что вы уже пробовали, и определяли точную информацию, которую вы ищете. Даже если сам процесс написания вопроса окажется бесполезным, чем раньше вопрос будет опубликован, тем скорее у сообщества появится возможность увидеть его и потенциально ответить на него. Это инвестиция. Сделай это раньше.
Вы также можете сделать устную версию этой техники. Я нахожу это особенно полезным, когда я работаю параллельно с другими членами команды. Каждый работает над одной и той же конечной целью решения проблемы, но части, которые они уже понимают, способы мышления о проблеме и решения, которые они изучают, часто бывают разными. Напомните себе говорить вслух, что, по вашему мнению, может происходить, почему вы так думаете и что вам нужно выяснить, чтобы это проверить.
Прогуляться
Большинство из нас хотят закончить рабочую сессию на высокой ноте. Неудовлетворительно отойти от чего-то нерешенного или сломанного. Но по иронии судьбы это иногда самый быстрый способ исправить это. Если я продолжаю фокусироваться на одной и той же проблеме в течение длительного времени, становится трудно сохранять перспективу и объективность. Это также заставляет меня устать, что, как правило, способствует догадкам и разгильдяйству.. Часто короткий перерыв - это все, что мне нужно, прежде чем вернуться к проблеме с ясными глазами и более четким мышлением. Эта простая тактика - самая эффективная техника отладки в моем наборе инструментов.
Я научился сопротивляться страху, что мое текущее свободное пространство необходимо, и я никогда не смогу восстановить его, когда вернусь. Я буду. Я также сопротивляюсь заблуждению, что, если я буду спать всю ночь, я в конце концов пойму это. Я, вероятно, не буду. Бесчисленное количество раз я совершал эту ошибку: упорно работал допоздна над чем-то разочаровывающим, прежде чем окончательно сдаться, только чтобы вернуться на следующее утро и сразу же заметить пропущенную точку с запятой или опечатку в имени переменной.. Это требует практики, но я научился распознавать ранние признаки застревания или разочарования. Когда я чувствую, что это происходит, я отхожу или устанавливаю строгий лимит времени на то, как долго я буду позволять себе бороться, прежде чем сделать перерыв. Опыт научил меня, что чем раньше я возьму этот перерыв, тем скорее я действительно решу свою проблему.
Последний совет
Не забывайте наслаждаться моментом, когда вы наконец решите свою трудную проблему. Сделайте танец победы. Пейте вкусный напиток. Проблемы, как правило, требуют нашего внимания, но успехи могут ускользнуть, если мы позволим им. Вы много работали и выполнили что-то сложное. Завтра всегда будет больше проблем.
