Это хорошая практика для регистрации всех методов для целей отладки (для отслеживания потока программы)? [закрыто]

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

В целом, №

Это, безусловно, не широко признано как хорошая практика ^{1 .}

Вот некоторые плюсы и минусы:

1. Да: если вы реализовали это, информация о трассировке полезна.

2. Да: вы можете отключить запись трассировки.

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

4. Нет: при ведении журнала возникают накладные расходы ... даже если ведение журнала отключено с помощью средства защиты времени выполнения в операторе ведения журнала ^{2 .}

5. Нет: дополнительные операторы журналирования в начале и конце каждого метода являются «беспорядочными», которые затрудняют чтение кода.

6. Нет: при условии, что дополнительные операторы журналирования добавляются вручную, это дополнительные усилия по программированию и дополнительный источник ошибок. (И ошибки могут быть трудно обнаружить в тесте. Собираетесь ли вы писать модульные тесты / что-нибудь еще, чтобы проверить, что трассировка была реализована правильно?)

7. Нет: отладка трассировки может изменить поведение вашего кода, если он многопоточный. Например, включение трассировки может привести к случайной синхронизации в не поточно-ориентированном приложении. Это может привести к изменению поведения неисправного приложения; c.f. Гейзенбаг .

Наконец, отладчик вашей IDE может позволить вам автоматически регистрировать вход и выход методов без каких-либо действий на уровне исходного кода. (Конечно, это не помогает с проблемой Heisenbug; см. Выше.)

---

^{1 - Если бы это было так, вы бы увидели эту практику во многих / большинстве открытых кодовых баз. Я не могу вспомнить, чтобы когда-либо видел его.}

^{2 - Если вы найдете способ отключить его с помощью препроцессора, или путем внедрения кода времени сборки / загрузки, или с помощью конструкций if (compileTimeConstFlag), вы можно снять накладные расходы. Но тогда вы теряете возможность включать и выключать трассировку. И влияние на ваш исходный код больше.}

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

     class Tracer{

    void informCall(Object...callArgs){

      meth=TraceUtils.getPreviousMethod();

      if(noCondition||tracerCodition.trace(Trace.getCallerStackTraceElement())){
       //since trace method can know which thread we are in that is not a necessary argument

       TraceLogger.inform(TraceType.Method,meth.traceString()+"/nargs:/n"+TraceUtils.argsString(callArgs));
       }

     }

    }

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