Как улучшить legacy-код

[@maxru]

Капитан, капитан, улыбнитесь.

(Тем не менее, спасибо за перевод)

[@TrogWarZ]

Спасибо за перевод!
Кто-нибудь может поподробнее пояснить раздел «Оснащение и журналирование»? Какие-то статьи на тему, примеры или ключевые слова для запроса в поиск?
Звучит, вроде, логично, но всё ещё не понятно как это работает.

[@osigida]

За такой перевод надо руки вырывать.
В оригинале это звучит как

Instrumentation and logging

Instrumentation — имеется в виду сбор метрик.
Logging — сбор и анализ логов приложения

[@TrogWarZ]

Перевод не хорош, но «прорекламировал» статью и я её прочитал в оригинале. За то и спасибо.

Но вопроса это таки не отменяет. В статье пример с открытием/закрытием [десктопного?] приложения.
Так как я этим методом со счётчиками никогда не пользовался, то было бы интересно посмотреть как его используют в веб-разработке на серверных частях.
Примеры типа «давайте напишем юнит-тесты на привет-мир или калькулятор» не помогают пониманию.

[@osigida]

Хм, попробую, с вашего позволения.

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

Более изощренная инструментация (гуглить real user monitoring) позволит увидеть как быстро открывается страница у пользователя, какие ошибки выскакивают, как часто.

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

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

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

Все вместе, позволит понять что, вообще у пользователя творится, ну и в контексте рефакторинга легаси систем — не наломали ли мы чего, после того как чуть чуть потрогали код.

PS: не сочтите за рекламу, поставил линки на тулы которыми пользовался и остался доволен.

[@TrogWarZ]

Спасибо за подробный ответ! И за ссылки – пойду искать аналоги для моих платформ (:

Если я правильно понял автора, он предлагает расширить применение метрик до ещё одного слоя тестирования доменной логики и поиска ошибок, которые не найдены тестами. Обычно такие метрики сложнее простого счётчика из одной цифры (Яндекс/Гугл-Метрика на фронте, например) и зависят от кучи параметров многих моделей бизнес-логики одновременно.
Вот об этом было бы интересно почитать, как это организуют более опытные команды ибо я недавно осознал что начал изобретать что-то похожее на DomainEvents с кастомным логированием именно для этих целей.

[@SbWereWolf]

«и в целом вы придёте к заключению, что парни, собравшие старую систему, может быть, не такие идиоты, в конце концов»

именно, поэтому не надо кидать всё перестраивать, сначала надо понять логику разработчика.

[@Steed]

Да, заниматься рефакторингом legacy-кода категорически нельзя, если ты внутренне убежден, что написавшие систему — идиоты. Сам грешен и столько раз потом было стыдно, когда через некоторое время понимал, что наворотил более сложную и негибкую систему, чем раньше, или вместе с изменениями угробил красивое решение, которое просто не понял.

[@VolCh]

Насчёт копирования при начале — копировать надо реально всё, что можно. Например, может оказаться пропатченной библиотека в /usr/share/lib или в /usr/local/bin окажется бинарник, собранный из исходников в хомяке какого-то пользователя.

[@RomanArzumanyan]

А неплохо создать несколько виртуальных машин для повторяемости результатов разработки и тестирования (а-ля windows xp + visual studio 2005).

Один раз настроил весь этот зоопарк — и разослал коллегам. По достижению удовлетворительного результата — сохранил снапшот виртуалки.

[@crocodile2u]

"Первым порядком битвы станет длинный список багов, накопленных за годы в очереди билетов."

Печаль, печаль....

В целом, что-то в этом есть, хотя имхо можно было бы сократить в несколько раз.

[@jvs]

Подход с метриками, логами и мониторинг, это конечно хорошо, но не считает ли уважаемая публика, что без static analysis tool понимание что, где, когда работает, не может быть полным. А если что-то работает раз в полгода, так и не поймаешь. Мне интересно знает ли кто-то об оффлайновых инструментах анализа кода. Я вижу, eugenebb, что то делал. Может, поделитесь, какого рода это было? Я думаю, что мы все работаем с легаси и проблема развития и переделки того, что уже никто не может объяснить как написано, становится все актуальней.
Скоро систему, написанную на Angular и Meteor будут считать легаси, а ей всего три годика от роду… А подумайте банковских системах, которые содержат миллионы строк на КОБОЛЕ?

[@Oxoron]

eugenebb