День 1764. #ЗаметкиНаПолях #Debugging
Правила отладки: Меняйте За Раз Что-то Одно
Изменение нескольких элементов создаёт ряд проблем. Возникает вероятность мелких ошибок, очень похожих на первоначальную проблему. Т.е. вы не уверены, была ли исправлена проблема или не привело ли исправление случайно к аналогичной проблеме. Чтобы справиться с этой сложностью, вносите только одно изменение за раз.

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

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

Изолируйте ключевой фактор
Суть эффективной отладки в выявлении критического фактора путем сужения фокуса до определённого раздела кода, в котором может возникнуть потенциальная проблема. Так процесс отладки становится более точным и эффективным. Чтобы сделать это систематически исключайте части программы и наблюдайте, сохраняется ли ошибка. Нет ли при этом знакомой закономерности? Признание того, что «я это видел раньше», часто означает начало понимания, если не полное решение.

Меняйте один тест за раз
Иногда изменение нескольких тестов или корректировка нескольких параметров может привести к тому, что проблема будет проявляться более последовательно, обеспечивая более чёткое представление о сбое. Однако крайне важно придерживаться принципа изменения только одного элемента за раз. Это обеспечивает точную идентификацию параметра, ответственного за наблюдаемый эффект. Если изменение не влияет на ошибку, верните всё в исходное состояние.

Сравните плохое с хорошим
Изучая два сценария сбоя и успеха, сравните различные аспекты: трассировки, выходные данные отладки и окна состояния и т.п. Если между двумя тестами произошло множество изменений кода или созданы разные сценарии работы, их сравнение может стать затруднительным. Чтобы изолировать ошибку, важно свести к минимуму различия между ними. Если в неудачном тесте есть что-то, чего нет в удачном, вы на пути к обнаружению проблемы.

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

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

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

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

Источник: https://dev.to/rajasegar/debugging-rules-change-one-thing-at-a-time-3kc6