Как наиболее эффективно отлаживать код? [закрыто]

Ошибки, попадающие в код, могут быть сведены к минимуму, но не полностью устранены, как написано - программисты, хотя многие не согласны , только люди.

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

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

Мышление и отношение к отладке, пожалуй, самая важная часть, потому что она определяет, насколько эффективно вы исправите ошибку и что вы узнаете из нее - если что-нибудь.

Классики по разработке программного обеспечения, такие как Pragmatic Programmer и Code Complete, в основном отстаивают один и тот же подход: каждая ошибка - это возможность узнать, почти всегда о себе (потому что сначала компилятор / компьютер обвиняют только новички).

Так что относитесь к нему как к тайне, которую будет интересно взломать. И взломать эту загадку нужно систематически, выражая свои предположения (для себя или для других), а затем проверяя наши предположения, один за другим, если это необходимо, - используя все имеющиеся в нашем распоряжении инструменты, особенно отладчики и автоматизированные тестовые среды. Затем, после того, как тайна разгадана, вы можете сделать еще лучше, просматривая весь ваш код на предмет похожих ошибок, которые вы могли совершить; и напишите автоматизированный тест, чтобы убедиться, что ошибка не возникнет по незнанию.

Последнее замечание - я предпочитаю называть ошибки «ошибками», а не «ошибками» - Дейкстра упрекнул своих коллег за использование последнего термина, потому что это нечестно, поддерживая идею о том, что пагубные и непостоянные феи-ошибочники создавали ошибки в наших программах, пока мы не были вместо того, чтобы быть там из-за нашего собственного (небрежного) мышления: http://www.cs.utexas.edu/users/EWD/transcription/EWD10xx/EWD1036.html

Например, мы могли бы начать с очистки нашего языка, не называя ошибку ошибкой, а называя ее ошибкой. Это намного более честно, потому что это прямо возлагает вину на то, где оно принадлежит, а именно. с программистом, который сделал ошибку. Анимистическая метафора ошибки, которая злонамеренно проникла в то время, когда программист не смотрел, интеллектуально нечестна, поскольку она скрывает, что ошибка - это собственное творение программиста. Хорошая особенность этого простого изменения словарного запаса заключается в том, что он имеет такой глубокий эффект: если до этого программа с одной ошибкой раньше была «почти правильной», то впоследствии программа с ошибкой просто «неправильная» (потому что в ошибка).

1. Пишите тесты. Тестирование не только отлично предотвращает ошибки (по моему опыту, правильно выполненное TDD устраняет почти все тривиальные, глупые ошибки), но также помогает при отладке. Тестирование заставляет ваш дизайн быть достаточно модульным, что значительно упрощает выявление и копирование проблемы. Кроме того, вы контролируете окружающую среду, поэтому сюрпризов будет намного меньше. Более того, как только вы получите неудачный тестовый пример, вы можете быть вполне уверены, что вы прибили реальную причину поведения, которое вас беспокоит.

2. Узнайте, как использовать отладчик. printОператоры могут работать достаточно хорошо на некотором уровне, но отладчик большую часть времени очень полезен (и если вы знаете, как его использовать, это намного удобнее, чем printоператоры).

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

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

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

На эту тему я прочитал отличную книгу под названием « Почему программы не работают» , в которой изложены различные стратегии поиска ошибок - от применения научного метода для выявления и устранения ошибки до дельта-отладки. Другая интересная часть этой книги заключается в том, что в ней отсутствует термин «ошибка». Подход Зеллера заключается в следующем:

(1) Программист создает дефект в коде. (2) Дефект вызывает инфекцию (3) Инфекция распространяется (4) Инфекция вызывает сбой.

Если вы хотите улучшить свои навыки отладки, я настоятельно рекомендую эту книгу.

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

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

Limist упомянул книгу Pragmatic Programmer, в которой есть несколько интересных материалов по исправлению ошибок. Используя пример, который я привел в предыдущем абзаце, я посмотрю на это: Software Entrophy , где используется аналогия сломанной вдовы. Если появятся два разбитых окна, ваша команда может стать безразличной к тому, чтобы починить ее, если вы не займете активную позицию.

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

1. Выясните, каково восприятие проблемы: перевести с «Боба клиента еще не в системе» на «Когда я пытаюсь создать пользовательскую запись для Боба, происходит сбой с исключением из-за дублирования ключа, хотя Боб еще не там
2. Выясните, действительно ли это проблема или просто недоразумение (действительно, Боба там нет, никто не называется Бобом, и вставка должна работать).
3. Попытайтесь получить минимальные надежные шаги, которые вы можете выполнить, чтобы воспроизвести проблему - что-то вроде «Если система с пользовательской записью« Брюс », когда вставляется пользовательская запись« Боб », возникает исключение»
4. Это ваш тест - если возможно, поместите его в автоматизированный тестовый комплект, который вы сможете запускать снова и снова, это будет неоценимо при отладке. Вы также можете включить его в свой набор тестов, чтобы эта проблема не появлялась позже.
5. Вытащите свой отладчик и начните устанавливать точки останова - выясните путь к коду при запуске теста и определите, что не так. Делая это, вы также можете усовершенствовать свой тест, сделав его как можно более узким - в идеале, модульным тестом.
6. Исправьте это - проверьте свои тестовые проходы.
7. Убедитесь, что первоначальная проблема, описанная клиентом, также исправлена ​​(очень важно - возможно, вы только что исправили часть проблемы). Убедитесь, что вы не вводили регрессии в других аспектах программы.

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

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

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

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

1. Определите, есть ли действительно ошибка. Ошибка - ВСЕГДА разница между поведением системы и требованиями; тестер должен уметь формулировать ожидаемое и реальное поведение. Если он не может обеспечить поддержку ожидаемого поведения, нет никаких требований и нет ошибок - только чье-то мнение. Отправь это обратно.

2. Рассмотрим возможность того, что ожидаемое поведение неверно. Это может быть связано с неправильным толкованием требования. Это также может быть связано с дефектом в самом требовании (разница между подробным требованием и бизнес-требованием). Вы также можете отправить их обратно.

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

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

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

6. Если вы определили, что действительно существует дефект, и он действительно находится в коде, которым вы управляете, вы можете дополнительно изолировать проблему, отыскивая последнюю «заведомо исправную» сборку и просматривая журналы управления исходным кодом на наличие изменений, которые могли вызвать проблему. Это может сэкономить много времени.

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

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

1. Напишите модульный тест, который воспроизводит проблему и дает сбой.

2. Не изменяя модульный тест, сделайте его успешным (изменив код приложения).

3. Держите модульный тест в своем наборе тестов, чтобы предотвратить / обнаружить регрессию.

Вот как я это делаю:

1. Используйте один и тот же метод каждый раз, чтобы найти проблему. Это улучшит ваше время реакции на ошибки.
2. Лучший способ, вероятно, чтение кода. Это потому, что вся информация доступна в коде. Вам просто нужны эффективные способы найти правильную позицию и умение понимать все детали.
3. отладка - это очень медленный способ, и он необходим, только если ваши программисты еще не понимают, как компьютер выполняет инструкции asm / не могут понять стеки вызовов и основные вещи
4. Попробуйте разработать проверочные методы, такие как использование прототипов функций, чтобы рассуждать о поведении программы. Это поможет быстрее найти правильную позицию

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

Предполагая, что вы находитесь в производственной среде, вот что вам нужно сделать:

1. Правильно опишите «ошибку» и определите события, которые ее вызывают.

2. Определите, является ли «ошибка» ошибкой кода или ошибкой спецификации. Например, ввод 1-буквенного имени может считаться ошибкой для некоторых систем, но приемлемым поведением для других систем. Иногда пользователь сообщает об ошибке, которая, по его мнению, является проблемой, но ожидания пользователя в отношении поведения системы не являются частью требований.

3. Если вы доказали, что существует ошибка, и ошибка связана с кодом, то вы можете определить, какие части кода необходимо исправить, чтобы предотвратить ошибку. Также изучите влияние поведения на текущие данные и будущие операции системы (анализ влияния на код и данные).

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

5. Проанализируйте причины, послужившие причиной появления этой ошибки (требования, кодирование, тестирование и т. Д.). Обеспечить выполнение процессов, которые предотвратят повторное возникновение состояния.

6. Документируйте эпизод адекватно.

7. Выпустить исправление (или новую версию)