Как потратить меньше времени на отладку? [закрыто]

Следуя правилу Парето, программист тратит только 20% своего времени на действительно полезные вещи.

Я трачу 80% своего времени на отладку, исправление мелких вещей, чтобы все работало.

Есть ли способ тратить меньше времени на отладку?

Код в Agda или Coq . Как только ваш код скомпилируется, он будет работать. Если это слишком хардкор, выберите язык с более слабой системой типов, например, Haskell или F #.

Но, тем не менее, в большинстве случаев вы будете гораздо более продуктивно тратить 20% своего времени на кодирование и 80% на тестирование и отладку. 100% недели - это больше, чем 20% часа. Если отладка - это то, что вам нужно для достижения цели, то отладка не является пустой тратой времени, и вам не следует беспокоиться об «улучшении» этой пропорции.

Модульное тестирование.

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

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

• Модульное тестирование, чтобы вы знали, работает ли ваш код в первую очередь.
• По крайней мере, некоторое количество предварительного дизайна, чтобы вы знали, что вы кодируете.
• Обзоры кода, потому что две головы лучше, чем одна, и четыре глаза лучше, чем две. Не говоря уже о том, что даже попытка объяснить ваш код кому-то еще выявляет много проблем.
• Контроль версий, так что вы можете быстро определить, какие изменения могли вызвать ошибку.
• Рефакторинг, чтобы ваш код не превратился в ужасный непонятный беспорядок.
• Прочтите «Чистый код» Роберта С. Мартина и делайте то, что он вам говорит. Вы будете поражены результатами.

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

Это даст вам большую часть пути, но для 99,999% проектов вам все равно потребуется время для отладки. Лучшее, что я могу сделать здесь, это сделать 4 вещи:

1. везде, где это возможно, используйте неизменяемые типы - если что-то имеет неправильное значение, вы будете точно знать, где искать немедленно (где оно создается).
2. применять инварианты в коде - если вы знаете, что значение определенно не разрешено, проверьте его и сгенерируйте исключение в точках входа для методов и конструкторов. Если вы объедините это с неизменяемыми типами, то вы также можете начать делать определенные предположения о том, что является действительным или нет.
3. убедитесь, что у вас есть адекватная регистрация - получите это рано, и это даст вам много важной информации о том, когда что-то пойдет не так. АОП работает очень хорошо здесь. Ведение журнала в качестве запоздалой мысли, как правило, немного дрянной - начните это как часть настройки проекта.
4. если ваша кодовая база достаточно большая / сложная, избегайте использования примитивов - например, используйте тип с именем Age, а не просто int. Поначалу это будет казаться немного бессмысленным, но возможность мгновенно отследить любое использование чего-либо - огромная победа в отладке.

Мои 80% отлажены. Я исправляю простые ошибки и пытаюсь заставить все работать.

Начните с написания юнит-тестов и постарайтесь получить как можно более высокий охват. Кто-то упомянул TDD, но я бы пошел с BDD .

В конце вы, скорее всего, потратите 80% на устранение сложных ошибок.

Как потратить меньше времени на отладку? Напишите меньше кода.

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

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

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

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

• Знать, как использовать программное обеспечение для контроля версий.

  • Использование веток поможет вам выделить области разработки, и вы сможете увидеть, в какой области разработки есть ошибки, а какие нет.
  • Узнайте, как использовать деление пополам в вашей VCS, в Git это встроено. Если вы используете другую VCS, в которой нет деления пополам, ищите инструмент, который работает как git bisect, но для вашей VCS (я знаю, что это существует для SVN и не должно быть слишком сложным для создания других VCS). Это поможет вам разобраться с изменениями кода, которые привели к ошибке, что поможет узнать, куда направить ваш отладчик. Этот процесс деления на части будет быстрее, если у вас есть тесты на ошибку, и знание того, какой коммит содержит оскорбительное изменение, будет более полезным, если вы практикуете атомарные коммиты.

• Улучшите ваше понимание языка программирования, который вы используете.

  • Читайте книги, блоги и код о языке программирования.
  • Каждый раз, когда вы исправляете ошибку, убедитесь, что вы хорошо понимаете, почему код не работает и почему ваше исправление работает. Со временем вы выучите много ошибок на вашем языке, которые помогут вам избежать их проблем и определить их симптомы, если они появятся снова.

• Будь логичным

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

Добавление к комментариям для модульного тестирования, но это действительно хорошо, если ваш код был отделен для его поддержки (например, MVC). Если вы не можете реализовать MVC (или аналогичный) (устаревший проект), модульные тесты вообще не будут работать для вашего пользовательского интерфейса. Затем я бы добавил автоматическое тестирование пользовательского интерфейса (Microsoft Coded UI Tests, WaitN), так как это уменьшит количество ошибок в этой части вашего кода.

Я также очень рекомендую использовать инструменты статического анализа (например, FxCop / Microsoft Code Analysis, Resharper, JustCode для мира MS). Они могут найти все виды общих проблем кодирования, которые могут уменьшить глупые задачи отладки и сосредоточиться больше на отладке бизнес-логики.

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

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

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

-Имя функционирует интуитивно. Это формально известно как доступность. То есть кнопка позволяет нажиматься, рычаг позволяет переключаться, ручка, которую нужно нажимать, и т. Д.

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

-Используйте абстракцию, где это уместно. Кратковременная память слабая.

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

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

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

Лучший способ уменьшить отладку, IMO, это концентрироваться и замедляться при кодировании. Это заставляет вас видеть ошибки, которые вы, возможно, сделали!

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

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

Иногда быстрая каракули на листе бумаги помогает увидеть большие кусочки головоломки.

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

PS. Я имею в виду 5, может, десять минут, а не часы написания огромной спецификации.

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

Учись на своих ошибках. Не продолжайте делать одни и те же снова и снова.

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

Обратите внимание на требование. Даже если это работает, но не выполняет то, что указано в требовании, это ошибка.

Журналы исключений могут быть реальной помощью, если что-то пойдет не так через шесть месяцев. Будьте в привычке записывать исключения.

Мои две главные мысли: 1) написать лучший код, который потерпит неудачу, когда вы сделаете что-то неожиданное 2) станьте лучше при отладке

Мой код замусорен

if(value!=null) throw new NotImplementedException();
if(obj.v>0) throw new Exception(); //sometimes i dont write NotImplementedException
if(value=="thing") throw ...;

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

Чтобы лучше справляться с отладкой путаницы со стеком вызовов, точками останова (с условиями), непосредственным окном (также известным как окно приглашения или реплики), переменными «наблюдения» и всем остальным.