Код к регистрирующемуся отношению? [закрытый]

Поскольку методы класса ES6 не перечислимы, у вас нет другого варианта, кроме как использовать Object.getOwnPropertyNames () , чтобы получить массив всех его свойств.

После для этого существует несколько способов использования методов извлечения, наиболее простым из которых может быть использование Array.prototype.forEach () .

Проверьте следующий фрагмент:

Object.getOwnPropertyNames(Animal.prototype).forEach((value) => {
    console.log(value);
})

47
задан David Precious 30 September 2008 в 15:22
поделиться

14 ответов

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

я соглашаюсь, что то, что Вы говорите, немного чрезмерно для входа.

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

13
ответ дан Peter Mortensen 7 November 2019 в 23:08
поделиться

Также в эти дни мощных IDE и удаленной отладки, которая очень регистрируется действительно nescisary?

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

  • Для исследования проблем в коде в реальном времени, где приостановка с отладчиком произвела бы результат вычисления (предоставленный, вход окажет небольшое влияние на синхронизацию в процессе в реальном времени как это, но сколько зависит значительно от программного обеспечения)
  • Для сборок, отправленных бета-тестерам или другим коллегам, у которых не может быть доступа к отладчику
  • Для дампа данных к диску, который не может быть легко просмотреть в отладчике. Например, определенный IDE, который не может правильно проанализировать структуры STL.
  • Для получения "ощущение" нормального потока Вашей программы
  • Для того, чтобы сделать код [еще 113] читаемый в дополнение к комментарию, как так:
// Now open the data file
fp = fopen("data.bin", "rb");

вышеупомянутый комментарий мог так же, как легко быть помещен в регистрирующийся вызов:

const char *kDataFile = "data.bin";
log("Now opening the data file %s", kDataFile);
fp = fopen(kDataFile, "rb");

Однако Вы до некоторой степени корректны. Используя регистрирующийся механизм, поскольку прославленный регистратор отслеживания стека генерирует файлы журнала очень низкого качества, поскольку это не предоставляет достаточно полезное место ошибки разработчику для исследования. Таким образом, ключ здесь является, очевидно, корректным и благоразумным использованием входа вызовов, которые я думаю, сводится к усмотрению разработчика. Необходимо полагать важное создание файлов журнала для [1 114] сами ; Ваши пользователи не заботятся о них и будут обычно чрезвычайно неправильно истолковывать свое содержание так или иначе, но можно использовать их, чтобы, по крайней мере, определить, почему программа неправильно себя вела.

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

14
ответ дан Nik Reiman 7 November 2019 в 23:08
поделиться

Полные файлы журнала удивительно полезны. Рассмотрите ситуацию, где Ваше приложение развертывается где-нибудь как банк. Вы не можете пойти туда и отладить его вручную, и они уверенный не собираются отправлять Вам свои данные. То, что можно получить, является полным журналом, который может указать на Вас туда, где проблема произошла. Наличие многих уровней журнала очень полезно. Обычно приложение работало бы в режиме, таким образом, что оно только сообщает относительно фатальных ошибок или серьезных ошибок. Когда необходимо отладить его, пользователь может включить отладку или проследить вывод и получить намного больше информации.

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

14
ответ дан stimms 7 November 2019 в 23:08
поделиться

Так как log4net делает отличную работу при не засорении ресурсов, я склонен быть немного подробным при входе потому что, когда необходимо измениться на режим отладки, чем больше информации Вы имеете, тем лучше. Вот то, что я обычно регистрирую:

УРОВЕНЬ ОТЛАДКИ

  • Любые параметры передали в метод
  • Любые количества строки от наборов результатов, которые я получаю
  • Любой datarows, который может содержать подозрительные данные, будучи переданным к методу
  • Любые "сгенерированные" пути к файлам, строки подключения или другие значения, которые могли разбудить mungled, будучи "соединенным" средой.

ИНФОРМАЦИОННЫЙ Уровень

  • запуск и конец метода
  • запуск и конец любых главных циклов
  • запуск любого особо важного дела / операторы переключения

ОШИБОЧНЫЙ Уровень

  • Обработанные исключения
  • Недопустимые попытки входа в систему (если безопасность является проблемой)
  • Неправильные данные, что я прервал forreporting

ФАТАЛЬНЫЕ Необработанные исключения Уровня

  • .

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

41
ответ дан Mikhail 7 November 2019 в 23:08
поделиться

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

4
ответ дан dr. evil 7 November 2019 в 23:08
поделиться

Я думаю, что "журналы для кодирования отношения" являются неверным толкованием проблемы.

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

Тогда ВСЕ Вы имеете в наличии для Вас для исправления ошибки, информация, Вы сами вставили файлы журнала. Никакие сеансы отладки (который запрещается в продуктивных средах так или иначе) - никакой ввод по абсолютному адресу во входных данных - ничто!

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

Точно, КАКОЙ материал зависит от сценария, но в основном достаточно гарантировать, что Вы никогда не вызываете сомнение, что происходит где:)

Естественно это означает, что БОЛЬШОЙ вход произойдет. Вы тогда создадите два журнала - один со всем, что только имеется в наличии довольно долго, чтобы гарантировать, что Вам не будет нужен он, и другой с нетривиальной информацией, которая может храниться для намного дольше.

Отклонение, регистрирующееся как чрезмерный, обычно делается теми, кто не должен был исправлять ошибку ни с чем иным, чтобы пройти:)

5
ответ дан Thorbjørn Ravn Andersen 7 November 2019 в 23:08
поделиться

Когда у Вас есть потребительский сценарий (т.е. кто-то, машина которого Вы не получаете физический доступ к), единственные вещи, которые "очень регистрируются", перекрашивают функции и почти что-либо позвонившее ими (который должен быть почти ничем). Или другие функции, которые вызваны 100's времен в секунду во время операции (запуск программы в порядке, тем не менее, для имения 100's вызовов, чтобы зарегистрировать стандартные программы, потому что по моему опыту, это - то, где большинство проблем происходит).

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

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

3
ответ дан Tanktalus 7 November 2019 в 23:08
поделиться

Я нахожу, что вход намного менее необходим, так как я начал использовать TDD. Это делает намного легче определить, где ошибки лежат. Однако я нахожу, что вход операторов может помочь понять то, что продолжается в коде. Несомненно, отладчики помогают дать Вам идею низкого уровня того, что происходит. Но я нахожу его легче, когда я могу соответствовать строке вывода к строке кода, если я хочу получить представление высокого уровня того, что происходит..

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

2
ответ дан Jason Baker 7 November 2019 в 23:08
поделиться

Сколько из тех строк регистрируется по умолчанию? Я работал над системой очень как то, что Вы описываете - просто начальная загрузка, она заставила бы более чем 20 МБ журналов быть записанными, если бы вход был проворачиваемым путем, но даже отладка мы не поворачивали все это путь ко всем модулям. По умолчанию это зарегистрировалось бы, когда модуль кода вводился, и главные системные события. Это было большим для отладки, так как QA мог просто присоединить журнал к билету, и даже если это не было восстанавливаемо, Вы видели то, что продолжалось, когда проблема произошла. Если у Вас есть серьезная многопоточность, идущая на тогда вход, еще лучше, чем какой-либо IDE или отладчик, с которым я работал.

2
ответ дан tloach 7 November 2019 в 23:08
поделиться

Я лично полагаю, что, в первую очередь, нет никакого жесткого правила. У меня есть некоторые приложения, которые регистрируются МНОГО, в и из методов и обновлений статуса в течение середины. Эти приложения, хотя планируются процессы, работают руки прочь, и журналы анализируются другим приложением, которое хранит успех/отказ.

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

Однако это действительно зависит от проекта.

2
ответ дан Peter Mortensen 7 November 2019 в 23:08
поделиться

Я думаю, что другим фактором является используемый комплект инструментальных средств/платформа и соглашения, которые идут с ним. Например, вход, кажется, довольно распространяется в J (2) мир EE, тогда как я не могу помнить когда-либо писать оператор журнала в приложении Ruby on Rails.

0
ответ дан John Topley 7 November 2019 в 23:08
поделиться

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

Однако я действительно полагаю, что краткий стиль входа является лучшим подходом. Сообщения журнала имеют тенденцию быть ограниченными бизнес-логикой приложения, такого как "полученное сообщение из учетной записи xxx", чем "вводимая функция yyy". Мы действительно регистрируем исключения, поток запускается, повторение параметров среды и синхронизации. Кроме того, мы обращаемся к отладчику для идентификации логических ошибок в фазах QA и разработке.

2
ответ дан Peter Mortensen 7 November 2019 в 23:08
поделиться

Я должен признаться, что, запущено программируя более или менее зарегистрировал все детали, как описано "Dillie-O".

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

, Как только система становится стабильной, я медленно начинал удалять записи в журнале, как их значение добавляет, начал уменьшаться. (Никакой Log4j в тех момент времени.)

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

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

, Но если программисты не используют его соответственно, такой как тогда, когда использовать, если не для использования ИНФОРМАЦИИ, ОТЛАДКИ, ОШИБКИ и т.д., а также деталей в сообщениях журнала (я видел, что журнал обменивается сообщениями как, "Привет X, Привет XX, Привет XXX, и т.д.", который только может понять программист) отношение продолжит быть высоким с меньше ROI.

1
ответ дан Peter Mortensen 7 November 2019 в 23:08
поделиться

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

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

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

8
ответ дан Max Schmeling 7 November 2019 в 23:08
поделиться
Другие вопросы по тегам:

Похожие вопросы: