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

15

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

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

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

uhbif19
источник
9
Я не уверен, что именно так я бы истолковал принцип Парето.
c_maker
6
<meme> Посмотрите на TDD. </ meme>
StuperUser
1
Что вы на самом деле делаете при отладке?
3
вам нужно больше времени уделять вашему вниманию к деталям
1
Можно многое получить, просто просматривая ваш код время от времени. А еще лучше, пишите комментарии, когда вы чувствуете желание, чтобы позже было легче заметить ошибки.
Джои Адамс

Ответы:

5

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

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

SK-логика
источник
1
Просто потому, что что-то работает, не означает, что в нем нет ошибок. Ошибки часто являются результатом неправильного выполнения кода.
HLGEM
3
@HLGEM, прежде чем понизить голосование, вы должны были прочитать больше об Agda и Coq. Если ваш код компилируется, то гарантированно и доказано, что он делает именно то, что написано в его спецификации. Конечно, в спецификации также может быть ошибка, но я бы не назвал исправление такого рода проблем «отладкой».
SK-logic
2
@HLGEM, тогда ваше представление об «отладке» весьма креативно и далеко от мейнстрима. И в любом случае, при таком подходе соотношение между кодированием и «отладкой» будет далеко от 20/80. Поэтому, пожалуйста, не забывайте объяснять свое отрицательное мнение.
SK-logic
1
@HLGEM, это не было в списке требований OP. Ничего не известно о том, сколько там разработчиков, кто за них отвечает и т. Д. Единственный вопрос был: «Как измерить соотношение 20/80», и использование статически проверенного языка, несомненно, является наиболее очевидным ответом на него. Но, как я уже сказал, этот ответ применим только в очень редких случаях, и в целом соблюдение правила 20/80 является гораздо лучшим вариантом.
SK-logic
1
@ uhbif19 Кнут хотел сказать с юмором это. Вы знаете, что он на самом деле имел в виду?
Фил
44

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

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

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

Тео Ленндорф
источник
Я использую юнит-тесты и полностью с вами согласен. Но я не могу проверить все.
uhbif19
5
Что вы можете. Ну, не все , но все, что имеет значение. Используя интерфейсы, внедрение зависимостей, фальшивые и фиктивные классы / методы, вы сможете писать тесты практически для всего вашего кода.
Фредрик
8
@ Фредрик, вы не можете правильно выполнить модульное тестирование даже a + bчасти кода (если ваш тест не охватывает весь диапазон вашего арифметического типа данных).
SK-logic
«После сеанса отладки я просто исправил код». -- В самом деле? Я думаю, что после сеанса отладки я только что представил больше ошибок - я просто не знаю, где они находятся.
B Семь
35
  • Модульное тестирование, чтобы вы знали, работает ли ваш код в первую очередь.
  • По крайней мере, некоторое количество предварительного дизайна, чтобы вы знали, что вы кодируете.
  • Обзоры кода, потому что две головы лучше, чем одна, и четыре глаза лучше, чем две. Не говоря уже о том, что даже попытка объяснить ваш код кому-то еще выявляет много проблем.
  • Контроль версий, так что вы можете быстро определить, какие изменения могли вызвать ошибку.
  • Рефакторинг, чтобы ваш код не превратился в ужасный непонятный беспорядок.
  • Прочтите «Чистый код» Роберта С. Мартина и делайте то, что он вам говорит. Вы будете поражены результатами.
Дима
источник
5
Точно - никакая отдельная практика (например, модульное тестирование) не даст улучшения на порядок, но комбинация практик может. Другими словами ... серебряной пули нет.
Майкл
Я бы добавил TDD (где это возможно).
Том
1
Сначала я бы отсортировал чистый код и рефакторинг. Модульные тесты хороши для раннего обнаружения и исправления ошибок, но они не уменьшат их количество (они немного сократят время, потому что вы будете исправлять ошибки, когда у вас все свежее в памяти, но все же). Написание чистого кода, с другой стороны, уменьшает фактическое количество ошибок.
Ян Худек
1
@JanHudec Рефакторинг + чистый код + тесты = TDD
Том
1
@Tom: Да, но разные его части имеют разные эффекты. Умение писать чистый код поможет вам сократить время отладки без каких-либо тестов. Существуют тесты, чтобы вы могли тестировать модули до того, как их использование будет реализовано, и вы можете проверить, не изменили ли вы поведение при рефакторинге - что необходимо для очистки старого грязного кода.
Ян Худек
8

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

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

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

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

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

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

BЈовић
источник
6

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

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

Даниэль Роузман
источник
4

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

cdkMoose
источник
3

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

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

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

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

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

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

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

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

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

Скотт Уайли
источник
2

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

kibotu
источник
1
Ваше утверждение "Большинство ошибок происходит из ..." звучит хорошо, но есть ли у вас доказательства, подтверждающие это? Я думаю, что это будет звучать одинаково убедительно, если я скажу, что «большинство ошибок происходит из-за плохо определенных требований или отсутствия четкого дизайна». Вы должны добавить ссылку или ссылку на исследование, которое поддерживает ваше утверждение.
Калеб
2

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

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

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

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

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

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

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

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

Цезарь Баутиста
источник
1

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

динамический
источник
1

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

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

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

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

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

SetiSeeker
источник
1

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

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

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

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

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

HLGEM
источник
0

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

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

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

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

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

user2528
источник