2016-09-15 5 views
2

Вот сценарий: Я стараюсь, чтобы люди и сотрудники не теряли время на исправление ошибок в функциях, которые никогда не используются пользователями. Я работаю над приложением, которое существует уже 10 лет и имеет множество функций, которые никогда не могут использоваться клиентами, хотя в какой-то момент они были. Я нахожу, что иду вниз по кроличьим отверстиям, устраняя проблемы, о которых никогда не сообщали, потому что QA и клиенты никогда не сталкивались с ними. Я не хочу уходить из кода, который имеет серьезные проблемы, но я также не могу просто удалить его, потому что, возможно, части этого класса используются в другом месте.Функции регистрации/функции, используемые в приложении

Я предложил какую-то архитектуру регистрации, которая отслеживает каждый вызов функции или создание объекта в приложении, когда пользователь использует приложение. Таким образом, мы можем запросить клиентов для файла журнала, хранящегося где-то в папке, которую мы создаем. Как только мы получим все журналы от всех наших пользователей через определенное время (1-2 месяца или около того), мы можем анализировать журналы и видеть, какие именно функции и функции используются. Я считаю, что эти данные будут очень полезны при обнаружении того, как наши клиенты используют наше приложение. Он также может указывать на функции в нашем приложении, которые просто никогда не используются и какие функции используются больше всего.

Что было бы хорошим решением/архитектурой, шаблоном проектирования для реализации этой функции ведения журнала в существующую большую базу кода? Или это просто плохая идея?

Моя первоначальная мысль была бы чем-то вроде этого, но с чрезвычайно большим применением это займет некоторое время. Плюс это не выглядит здорово, когда что-то подобное в каждом отдельном методе, но, возможно, это единственный способ?

private void createData() 
{ 
    write.toLog("ClassName.createData"); 
    //the magic of the createData function 
} 
+1

И что, если функция вызывается только в високосные дни в високосные годы? Удаление этого может быть «плохой идеей все вместе». –

+0

Да, это возможность ... и, возможно, журналы просто помогут расставить приоритеты ошибок функций? @ElliottFrisch –

ответ

2

Аспектно-ориентированное программирование - это способ реализации идеи.

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

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

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

+0

Мне очень нравится идея Aspect Oriented Programming, тем более, что Java имеет встроенный AspectJ, который сделает мою жизнь довольно легкой! –

0

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

Каждый раз, когда я видел, что каждый вызов метода регистрировался в большой системе, регистрация была на уровне DEBUG или более тонкой и может быть выборочно включена, если потребуется (и редко когда-либо была).

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

Смежные вопросы