TheTalion
@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 строк?
Возможно вы знаете какие-то более оптимальные решения для написания дебага?
  • Вопрос задан
  • 293 просмотра
Пригласить эксперта
Ответы на вопрос 3
skobkin
@skobkin
Гентушник, разработчик на PHP и Symfony.
Обычно в сервисы/классы, где требуется логгирование/дебаг прокидывают логгер и используют уровни логгирования для того чтобы выводить или не выводить разную информацию.
Тогда в случае необходимости отладки при запуске приложения можно в качестве параметра указывать уровень логгирования и получать логи. А по умолчанию, например, использовать уровень типа QUIET/NONE/OFF (в разных логгерах - по разному).

А ещё для дебага используют дебаггер.
Ответ написан
mindtester
@mindtester Куратор тега C#
http://iczin.su/hexagram_48
собственная реализация логгера в каждом классе быстро утомит..
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
Ответ написан
Комментировать
DarkRaven
@DarkRaven
разработка программного обеспечения
Для отладки приложения, обычно, используется комплексный подход и он диктуется ситуацией.
Во-первых, для отладки поведения можно использоваться тем, что называется debugger - ставить точки прерывания и идти по шагам с проверкой, как меняются отслеживаемые данные.

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы