Comments 16
Капитан, капитан, улыбнитесь.
(Тем не менее, спасибо за перевод)
Спасибо за перевод!
Кто-нибудь может поподробнее пояснить раздел «Оснащение и журналирование»? Какие-то статьи на тему, примеры или ключевые слова для запроса в поиск?
Звучит, вроде, логично, но всё ещё не понятно как это работает.
Кто-нибудь может поподробнее пояснить раздел «Оснащение и журналирование»? Какие-то статьи на тему, примеры или ключевые слова для запроса в поиск?
Звучит, вроде, логично, но всё ещё не понятно как это работает.
За такой перевод надо руки вырывать.
В оригинале это звучит как
Instrumentation — имеется в виду сбор метрик.
Logging — сбор и анализ логов приложения
В оригинале это звучит как
Instrumentation and logging
Instrumentation — имеется в виду сбор метрик.
Logging — сбор и анализ логов приложения
Перевод не хорош, но «прорекламировал» статью и я её прочитал в оригинале. За то и спасибо.
Но вопроса это таки не отменяет. В статье пример с открытием/закрытием [десктопного?] приложения.
Так как я этим методом со счётчиками никогда не пользовался, то было бы интересно посмотреть как его используют в веб-разработке на серверных частях.
Примеры типа «давайте напишем юнит-тесты на привет-мир или калькулятор» не помогают пониманию.
Но вопроса это таки не отменяет. В статье пример с открытием/закрытием [десктопного?] приложения.
Так как я этим методом со счётчиками никогда не пользовался, то было бы интересно посмотреть как его используют в веб-разработке на серверных частях.
Примеры типа «давайте напишем юнит-тесты на привет-мир или калькулятор» не помогают пониманию.
Хм, попробую, с вашего позволения.
В вебе:
Всякие яндекс счетчики являются одним из примеров инструментации веб приложения.
Позволяют понимать сколько у нас пользователей вообще, какие страницы смотрят, как много времени проводят на страницах.
Более изощренная инструментация (гуглить real user monitoring) позволит увидеть как быстро открывается страница у пользователя, какие ошибки выскакивают, как часто.
На бек энде:
Сбор метрик, опять же, позволяет видеть какие методы дергаются, а какие нет (и может их можно удалить?). Как долго обрабатывается запрос, какие ошибки выскакивают, в каком количестве.
Метрики можно собирать пассивно, к примеру из аксесс логов или инструментируя код с помощью какой нить библиотеки или активно, подключая агента который автоматически будет собирать и засылать метрики на специально обученный сервер
За десктопные приложения не скажу, но думаю если есть какой нить сервак за ними, то все сказанное вполне можно применить и к ним и так же собирать метрики для анализа и контроля.
Все вместе, позволит понять что, вообще у пользователя творится, ну и в контексте рефакторинга легаси систем — не наломали ли мы чего, после того как чуть чуть потрогали код.
PS: не сочтите за рекламу, поставил линки на тулы которыми пользовался и остался доволен.
В вебе:
Всякие яндекс счетчики являются одним из примеров инструментации веб приложения.
Позволяют понимать сколько у нас пользователей вообще, какие страницы смотрят, как много времени проводят на страницах.
Более изощренная инструментация (гуглить real user monitoring) позволит увидеть как быстро открывается страница у пользователя, какие ошибки выскакивают, как часто.
На бек энде:
Сбор метрик, опять же, позволяет видеть какие методы дергаются, а какие нет (и может их можно удалить?). Как долго обрабатывается запрос, какие ошибки выскакивают, в каком количестве.
Метрики можно собирать пассивно, к примеру из аксесс логов или инструментируя код с помощью какой нить библиотеки или активно, подключая агента который автоматически будет собирать и засылать метрики на специально обученный сервер
За десктопные приложения не скажу, но думаю если есть какой нить сервак за ними, то все сказанное вполне можно применить и к ним и так же собирать метрики для анализа и контроля.
Все вместе, позволит понять что, вообще у пользователя творится, ну и в контексте рефакторинга легаси систем — не наломали ли мы чего, после того как чуть чуть потрогали код.
PS: не сочтите за рекламу, поставил линки на тулы которыми пользовался и остался доволен.
Спасибо за подробный ответ! И за ссылки – пойду искать аналоги для моих платформ (:
Если я правильно понял автора, он предлагает расширить применение метрик до ещё одного слоя тестирования доменной логики и поиска ошибок, которые не найдены тестами. Обычно такие метрики сложнее простого счётчика из одной цифры (Яндекс/Гугл-Метрика на фронте, например) и зависят от кучи параметров многих моделей бизнес-логики одновременно.
Вот об этом было бы интересно почитать, как это организуют более опытные команды ибо я недавно осознал что начал изобретать что-то похожее на DomainEvents с кастомным логированием именно для этих целей.
Если я правильно понял автора, он предлагает расширить применение метрик до ещё одного слоя тестирования доменной логики и поиска ошибок, которые не найдены тестами. Обычно такие метрики сложнее простого счётчика из одной цифры (Яндекс/Гугл-Метрика на фронте, например) и зависят от кучи параметров многих моделей бизнес-логики одновременно.
Вот об этом было бы интересно почитать, как это организуют более опытные команды ибо я недавно осознал что начал изобретать что-то похожее на DomainEvents с кастомным логированием именно для этих целей.
«и в целом вы придёте к заключению, что парни, собравшие старую систему, может быть, не такие идиоты, в конце концов»
именно, поэтому не надо кидать всё перестраивать, сначала надо понять логику разработчика.
именно, поэтому не надо кидать всё перестраивать, сначала надо понять логику разработчика.
Да, заниматься рефакторингом legacy-кода категорически нельзя, если ты внутренне убежден, что написавшие систему — идиоты. Сам грешен и столько раз потом было стыдно, когда через некоторое время понимал, что наворотил более сложную и негибкую систему, чем раньше, или вместе с изменениями угробил красивое решение, которое просто не понял.
UFO just landed and posted this here
Насчёт копирования при начале — копировать надо реально всё, что можно. Например, может оказаться пропатченной библиотека в /usr/share/lib или в /usr/local/bin окажется бинарник, собранный из исходников в хомяке какого-то пользователя.
"Первым порядком битвы станет длинный список багов, накопленных за годы в очереди билетов."
Печаль, печаль....
В целом, что-то в этом есть, хотя имхо можно было бы сократить в несколько раз.
Подход с метриками, логами и мониторинг, это конечно хорошо, но не считает ли уважаемая публика, что без static analysis tool понимание что, где, когда работает, не может быть полным. А если что-то работает раз в полгода, так и не поймаешь. Мне интересно знает ли кто-то об оффлайновых инструментах анализа кода. Я вижу, eugenebb, что то делал. Может, поделитесь, какого рода это было? Я думаю, что мы все работаем с легаси и проблема развития и переделки того, что уже никто не может объяснить как написано, становится все актуальней.
Скоро систему, написанную на Angular и Meteor будут считать легаси, а ей всего три годика от роду… А подумайте банковских системах, которые содержат миллионы строк на КОБОЛЕ?
Скоро систему, написанную на Angular и Meteor будут считать легаси, а ей всего три годика от роду… А подумайте банковских системах, которые содержат миллионы строк на КОБОЛЕ?
Sign up to leave a comment.
Как улучшить legacy-код