Как вы пишите дебаг? Какие устоявшиеся методики существуют?

Question

[TheTalion]

(Ставлю среднюю сложность, потому что интересует мнение опытных коллег)

Как по вашему оптимально писать включаемый\отключаемый дебаг на случая если фиксики все сломают?

Самая простая мысль:

public class Container {

private List<Cell> Cells = new List<Cell>();

public bool AddCell(Item item)
		{
			Cells.Add (new Cell(item));

			Debug("Add new Cell in {0}, with item id {1}", Cells.Count - 1, item);

			return true;
		}

public bool IsDebugEnabled = false;
private void Debug(string str)
		{
			if(IsDebugEnabled)
				Debug.Print(str);
		}
}

И есть ли по вашему мнению смысл вообще такой дебаг писать, если все функции 2-10 строк?
Возможно вы знаете какие-то более оптимальные решения для написания дебага?

Comments

[nexus478]

А вы часом не путаете дебаг и логгирование?

Answer 1

[Алексей Скобкин]

Обычно в сервисы/классы, где требуется логгирование/дебаг прокидывают логгер и используют уровни логгирования для того чтобы выводить или не выводить разную информацию.
Тогда в случае необходимости отладки при запуске приложения можно в качестве параметра указывать уровень логгирования и получать логи. А по умолчанию, например, использовать уровень типа QUIET/NONE/OFF (в разных логгерах - по разному).

А ещё для дебага используют дебаггер.

Comments

[TheTalion]

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

Уровни логирования просто на цвет влияют, как я понял. Это не существенно для меня.

[Александр Кузнецов]

TheTalion, Уровни логирования влияют на то, попадет ли данное сообщение в точку назначения лока (файловая система, консоль, SQL Server и т.п.) или нет.

[freeExec]

TheTalion, "ивент дебага" всего один - это брекпоинт, а вы пишете о чём то другом.

[Алексей Скобкин]

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

Answer 2

[#]

собственная реализация логгера в каждом классе быстро утомит..
1 - есть https://msdn.microsoft.com/ru-ru/library/system.di... там много готовых инструментов
2 - можно реализовать свой простейший логгер в виде расширения (в утилитарном статическом классе), пример

internal static void log(this string txt) => tbLog.AppendText(txt + Environment.NewLine);

потом очень удобно использовать в любом месте

$"что то прошло не так, параметры первый {x} и второй {y}".log();

3 - еще удобные опции компилятора, для конструкций, которые явно не нужны в продакшене

#if DEBUG
            var sw = new Stopwatch();
            sw.Start();
#endif
            /// что то делаем
#if DEBUG
            sw.Stop();
            var ts = sw.Elapsed;
            $"total time '{name_of_action}':".log();
            $"\t{ts.Hours:00}:{ts.Minutes:00}:{ts.Seconds:00}.{ts.Milliseconds:000}".log();
#endif

Answer 3

[Александр Кузнецов]

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

Во-вторых, для отладки приложения используется логирование по уровням.
Логирование на уровне TRACE: вы пишите все, что считаете нужным, все, что вам поможет потом понять, как шел процесс. На практике, это огромное количество сообщений, полезность которых в обычной ситуации крайне низкая.
Логирование на уровне INFO: вы пишете информационные сообщения, к примеру, об смене состояния процесса.
И так далее, по уровням.
Ваша система логирования отсекает все то, что ниже приемлемого уровня, не фиксируя это.

Кроме вышеперечисленного, для отладки, а точнее, для того, чтобы быть уверенным, что все идет именно так, как должно идти, пишут тесты. Unit-тесты, интеграционные тесты, тесты UI и т.п. И все это, в совокупности (логирование и исполнение тестов), дает относительно полное понимание, что все идет так как надо, а если не идет - вы видите, что в тесте A все сломалось, а в логах - что сломалось именно.