Отказ от устаревшей функциональности

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

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

Хороший план? Отличный. Проблема только в том, как определить ту самую редко используемую часть кода. Бывает и так, что та самая «ненужная» функциональность известна. В таком случае проблема состоит в том, чтобы доказать что она действительно не используется.

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

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

1. Как получить наиболее близкую к реальности статистику?

Фактически, есть только два варианта:

* собрать статистику, прогнав более или менее синтетические тесты, либо…

* выпустить специальную версию библиотеки, собирающую нужные данные в «боевых» условиях. 

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

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

2. В каком виде собирать статистику?

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

3. Насколько подробной должна быть собираемая информация?

К сожалению, ответ в стиле «чем подробнее – тем лучше» здесь не годиться. Подробности зачастую выливаются в гигабайты данных помноженных на сотни машин, что, в общем-то, не облегчает ни пересылку, ни обработку. В этом случае работает эмпирическое правило – данных должно быть ровно столько, чтобы ответить на поставленный вопрос плюс ещё чуть-чуть. Это «ещё чуть-чуть» поможет, при случае, ответить на дополнительные вопросы, которые возникнут уже после того, как статистика будет собрана.

4. Как пересылать собранные данные для анализа?

Здесь будет работать любой способ, полностью исключающий участие человека. Стоит только положиться на пользователя, чтобы, к примеру, послать письмо с подготовленным отчетом, - данные будет потеряны, отчет прислан слишком поздно и т.д. и т.п. Единственное что стоит разрешить пользователям – решать, согласны ли они на сбор статистики или нет.

5. Как анализировать собранные данные?

Perl, SQL и т.д. Всё что душе угодно, на самом деле. Замечу, что средства изначально направленные на анализ данных (SQL) позволяют получать гораздо более точные результаты, по сравнению с самописными анализаторами. С другой стороны тот же Perl – отличный инструмент для обработки данных перед внесением их в базу данных.

Прочитав всё это, вы, вероятно, зададитесь вопросом: «А стоит ли овчинка выделки»? К сожалению, на него нет однозначного ответа. Всё зависит от множества факторов: количества и характера пользователей вашей библиотеки, её архитектуры, частоты выхода новых версий, ваших знаний о том, как именно используется библиотека и т.д. и т.п. В любом случае, после проведения подобных мероприятий существенно улучшатся ваши знания о привычках ваших пользователей. :-)