[Java, Тестирование веб-сервисов] Приложения с тяжелой наследственностью. Поддержка или реставрация?

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
08-Фев-2021 19:33

Цитировать

Привет, Хабр! На прошедшем 28 января Luxoft TechFest, Михаил Занкович, Senior Team Lead в Luxoft, рассказывал про приложения с тяжелой наследственностью. Сегодня он делится дополнительными мыслями, замешанными на содержании этого доклада, который вызвал достаточно бурное обсуждение во время митапа.
Какие эмоции и ассоциации вызывает у вас фраза: «У нас легаси проект»? Чаще всего — отсутствие структуры, бардак, тонны не документированного кода, ужас, архитектурная анархия, отвращение, море костылей, надо бежать! Мои эмоции: «О! Наконец-то, что-то интересное. Давайте заставим это работать!» Подозреваю, что это очень не типичная реакция.
В этой статье я попытаюсь раскрыть иную идеологию работы с легаси. Обозначим ее как «реставрация ПО». Я не ставлю цель поменять ваше отношение к легаси, но если получится хотя бы заронить зерно сомнения о том, что легаси — это может быть интересно, я буду рад.
Типичный legacy
Что такое легаси? По моему опыту, можно составить следующий чек-лист на соответствие продукта «легаси»:

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

Неактуальная документация.
Затрудняет сопровождение проекта, формирует из продукта black-box. Увеличивает время погружения новых сотрудников. и плавно приводит к следующей характеристике.
Отсутствие архитектурного плана развития системы.
Функционал дублируется между модулями, нет четкой декомпозиции и зон ответственности между компонентами.
Низкая культура кода.
В первую очередь отсутствие или избыток комментариев. Отсутствие единого соглашения о наименовании объектов/интерфейсов классов и т.д.

Всё это приводит к тому, что сопровождать такой проект с каждым релизом становится все сложнее, ровно как и прорабатывать новую функциональность/новые требования. Любое изменение превращается в reverse-engineering с обязательным регрессионным тестированием и т.п. И в результате проект становится дорого поддерживать и его «замораживают» в существующем виде с минимизацией каких бы то ни было изменений.
Но из-за чего появляются legacy продукты?
Редко какая команда осознанно и целенаправленно создает некачественный продукт. Чаще всего это результат возможностей, ограниченных текущей ситуацией на проекте.
Нет четких требований — нет возможности сбалансированного проектирования функционала приложения.
Постоянное изменение требований, нечеткое формулирование, сжатые сроки имплементации, постоянно растущий технический долг — явные признаки гибких процессов разработки в команде, которая не смогла полностью адаптироваться к этим самым «гибким» подходам. И из «гибкого» работает только «быстро меняющиеся запросы от бизнеса».
Нередко это приводит к повышенной ротации внутри команды, что в свою очередь не сказывается позитивно на качестве. Представьте, новый специалист подключился к команде, два-три месяца только вникает в процесс, затем полтора-два месяца реализует какой-то функционал и готовится покинуть проект. Он не заинтересован в качественном продукте, в полноценном документировании своей части, передаче знаний коллегам и т.д. Экспертиза размывается.
В определенный момент принимается роковое решение: легче заменить/выключить, чем сопровождать. И проект переходит в фазу «low maintenance», когда его поддержкой занимаются по остаточному принципу, пытаясь минимизировать изменения, создать дополнительные «костыли», которые реализуют новые запросы быстро, но некачественно. А зачем качественно? Продукт же будет меняться. В таком режиме продукт может просуществовать долгие года, обрастая «костылями» и становясь все более монструознее.
Резюмируя все вышесказанное, можно выделить следующий основные причины возникновения legacy продуктов:

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

Добавляем сюда уровень профессионального развития специалистов на этот момент. Откройте свой проект пяти-, а лучше десяти летней давности. Уверен, без труда найдете элементы, которые сейчас бы вы реализовали иначе.
Итак, берем за аксиому: «код не создается изначально плохим». А значит в любом продукте была заложена какая-то идея. И если код вышел в продакшен, значит он работал и удовлетворял запросам бизнеса на тот момент.
Подход сопровождения
Задачи со стороны заказчиков достаточно просты: поддерживать наследие в рабочем состоянии, не нарушая текущие бизнес-процессы (часть из которых вообще никому не известны), при этом развивать функционал согласно новым требованиям согласно бюджета, который скорее всего ограничен.
Типичный подход команды, высадившейся на проект – продолжать медленно, но верно усугублять ситуацию. Не трогать лишнего, менять только то, что попросят и только тогда, когда попросят. Если модуль работает, но требует модификации логики – оставить и не трогать – лучше создать еще один такой, но с нужной логикой. Хаос растет, приложение усложняется.
Подход реставратора
Подход реставратора ПО – разобраться, что за механизм перед ним. Какая основная идея была заложена его создателями. Попытаться отсечь всё лишнее и сохранить всё самое лучшее. Если и изменять существующую структуру, то крайне осторожно и внимательно к деталям. От взгляда реставратора не должна скрыться ни одна мелочь, влияющая на систему. Вносимые изменения сначала прорабатываются по логике сопровождения, а потом идет анализ на возможность имплементации полноценного решения.
Это сложная и трудоемкая работа. Далеко не каждый разработчик желает, а главное реально способен заниматься реставрацией. Требования к уровню реставратора на порядок выше, нежели для обычного девелопера. Без опыта в реальных проектах, без понимания того, как могут развиваться системы, без столкновения не только с лучшими подходами на практике, но и с явно неудачными имплементациями – заниматься реставрацией не имеет никакого смысла.
Вместо типичного первого позыва «Да это ж костыли! Здесь надо всё переписать!» – истинный реставратор задаст вопрос «Почему было сделано так? Как именно планировалось это использовать?». И только удостоверившись, что не было никаких явных предпосылок к созданию такого кода, реставратор может воскликнуть: «Да это ж костыли! Здесь надо всё переписать!», и с чувством выполненного долга может действительно отколоть ненужный нарост на закостеневшем остове программного обеспечения, сделав объект реставрации лучше и качественнее.
Но такое случается редко, хотя и доставляет непередаваемое удовольствие реставратору. Чаще всего приходится распутывать клубок зависимостей между различными модулями. Не редко нити тянутся далеко за пределы зоны ответственности разбираемого компонента (а иногда и системы). И все эти хитросплетения взаимоотношений модулей должны учитываться при реставрации.

Таким образом, реставратор ПО работает на стыке девелопмента, архитектуры, бизнес-анализа, тестирования и медицины. И сложно сказать, какие навыки из обозначенных областей наиболее приоритетны. Должен быть определенный баланс между ними, приправленный честным желанием заниматься реставрацией. Причем здесь медицина? Так основной принцип реставратора «primum non nocere» – прежде всего не навреди.
Собственно этот подход будем рассматривать далее на конкретных примерах, постепенно разбирая и реставрируя типичное наследие, доставшееся от предыдущих технических владельцев систем. И на конкретных примерах посмотрим, почему важны все вышеперечисленные навыки.
Реставрация хранилища данных
Что хранит система?
Высаживаясь на новый проект, реставратор обратит внимание на объекты, обрабатываемые системой. Для полноценного погружения в бизнес-потоки и исходный код, особенно в условиях отсутствия нормальной документации, потребуется не меньше нескольких месяцев.
Одна из первых задач реставратора – оценить эффективность хранилища. Можно ли что-то улучшить, не опираясь на понимание бизнес-процессов? Типичная болевая точка любого хранилища данных, в первую очередь, связана с объемом этих самых данных. Чем больше объем, тем больше стоимость владения системой.
Вторая болевая точка – рост этого самого объема, что негативно сказывается на производительности системы в первую очередь. Скорее всего, уже существуют некоторые практики удержания информации в системе, но насколько они эффективны?
Все рассматриваемые здесь практики в большей степени применимы к классическим РСУБД, но и для no-sql решений подход не сильно отличается.
Одной из основных тактик реставратора в этом направлении является создание мониторинга объектов хранения информации. В случае классических СУБД – мониторинг таблиц.
Необходим фреймворк, который позволит по метаданным системы собирать периодически данные о двух тривиальных параметрах – объеме данных и количестве элементов в каждой таблице. Периодичность придется подбирать вручную (об этом ниже), исходя из особенностей работы системы. Обычного стартового периода в 24 часа вполне достаточно для базового анализа.
Анализ данных
Что делать с данными? На что обращать внимание? Первый момент – выявить наиболее «тяжелые объекты». На практике работает стандартное правило 20/80 – не более 20 процентов объектов будут использовать более 80 процентов пространства. Это позволяет существенно сузить зону анализа на первом этапе.
Чем дольше и подробнее подобная статистика накапливается, тем более четко отражается поведение системы. Как показывает опыт, рекомендуемый период – не менее двух недель. Основная идея – «зацепить» нерабочие дни/периоды, в рамках которых чаще всего реализуются механизмы очистки и архивирования информации.
Итак фреймворк написан, и реставратор две недели ждет результатов? Конечно нет. Это не бьется с идеологией реставратора. Получив первую порцию данных, можно провести базовый анализ. А именно – посмотреть соотношение занимаемого объема к количеству хранимых объектов (строк). Чем больше эта величина, тем больше вероятность, что здесь хранятся BLOB поля. И как раз эти таблицы и поля становятся для реставратора объектом исследования и анализа.
Основные вопросы: как часто к этим объектам реально обращаются бизнес-процессы? Владелец системы, существующая команда может пролить свет на подобные моменты. И внезапно (а на практике очень часто) оказывается, что подобные поля хранят не важную для бизнеса информацию: дампы объектов / сообщений для анализа командой разработки, комментарии пользователей, отображаемые только при создании заказа и т.п.
Следующий шаг: если данные не используются часто, или не несут явной бизнес-ценности, почему бы их не переместить в архив? При этом кардинальный подход с разбиением монолитной таблицы на части, вынос BLOB-объектов на более дешевый/медленный носитель, но при этом с сохранением исходного интерфейса таблицы (основной момент – нет достоверных сведений о всех процессах, обращающихся к этой информации, а значит изменения не должны им навредить) – может стать достаточно интересной и сложной технической задачей.
Менее интересная, но не менее полезная задача – использовать встроенные средства системы хранения данных по архивированию значений определенных полей. К примеру, Sybase ASE имеет фичу ASE_Compression, Mongo DB позволяет задать опции компрессии для коллекций и т.д. Практически любая система хранения информации имеет опцию дополнительного сжатия данных «под капотом». Функционал будет работать прозрачно для внешних систем и не потребует кардинальных изменений. На практике (особенно в legacy системах) подобные опции сжатия данных не используются по умолчанию.
Конечно же, применяя компрессию, реставратор в первую очередь должен оценить влияние подхода на производительность, а для этого должны быть проработаны ключевые показатели производительности системы, или, на крайний случай, должны присутствовать элементы регрессионного тестирования.
В общем, есть чем заняться в течение пары недель, пока собирается полноценная статистика по объектам.
Большая статистика: на что обратить внимание
Получив статистику за длительный период времени, реставратор пытается разобраться, что происходит с динамикой используемого места. Выполняется нормирование всех значений для одной таблицы/объекта к исходному. Это позволит оценивать именно относительный прирост данных и выявить наиболее интенсивно изменяющиеся объекты.
Построенный профиль, скорее всего, будет соответствовать одному из следующих типов:

Профиль 1 – константное значение. С максимальной вероятностью, это статичные справочники и с ними не столь интересно работать. Можно применить подход архивирования, описанный выше, опираясь на интенсивность использования справочника.
Небольшие флуктуации по объему – профиль 2 – могут говорить как о справочнике, так и об оперативной таблице, в которой интенсивно идет чтение/запись данных. Это наиболее сложные объекты с точки зрения реставратора, т.к. надо максимально детально анализировать их поведение. Именно для этих объектов, имеет смысл повысить частоту сбора информации: не раз в день, а раз в час, раз в минуту. Основная цель – более детально прорисовать изменение профиля и понять зависимости поведения.
Больший интерес вызывают профили 3 и 4. Профиль 3 (“пила”) четко говорит о том, что эта таблица периодически очищается. Но растущий тренд – каждый раз после очистки итоговый объем несколько больше, нежели был до этого – говорит о неэффективности существующих механизмов очистки. Т.е. за определенный период времени в системе появляется данных больше, чем удаляется в конце периода. Это может быть вполне нормальный бизнес-процесс, классический рост нагрузки на систему.
Но для реставратора это, в первую очередь, сигнал: не упущены ли какие-то условия для удаления информации? Исходя из практики, скорее всего какие-то сущности, ввиду сложных условий удержания данных в системе, незаслуженно остаются навсегда в хранилище. Цель реставратора – выявить такие сущности и также включить их в периодические активности.
Если же профиль 3 вырождается в постоянный рост – это первый претендент на узкое место в системе. Во-первых, нет явных указателей на процесс архивирования, во-вторых ожидается деградация производительности с ростом данных.
Профиль 4 – типичный пример архивной таблицы с периодическим наполнением данных. Обратите внимание, что рост таблицы происходит только в определенные дни. Вполне возможно, будут заметны корреляции с таблицами третьего профиля. Для архивных таблиц важно также понять принцип их использования – есть ли обращение к ним от пользователей? Или это история для анализа? Или это данные для репортинговых систем? В зависимости от ответов на эти вопросы вполне возможно будет принято решение выделить архивные таблицы в отдельный контур, отдельную базу, отдельный раздел. Тем самым освободив оперативное пространство.
Как это работает на практике?
В рамках одного из проектов подобное упражнение было сделано в первые полтора месяца после подключения к проекту. Именно объекты профиля №3 были целью, и они были найдены. Применение описанных практик (улучшение условий очистки), удаление данных, которые не использовались в рамках системы и т.п. позволили снизить объем занимаемого места более чем на 25%, а также остановить интенсивный рост хранилища.
В итоге мы смогли внести первые технические изменения в проекте и представить планы по улучшению функциональности. Заказчик остался довольным результатом команды, и она расширилась с 3 до 9 разработчиков. В течение года мы продолжали investigations, точки улучшения функциональности были использованы для поддержки системы и её характеристик.
К нам добавилось 2 аналитика, соответственно команда начала заниматься собственным девелопментом – не сопровождением, а реализацией нового бизнес-функционала. Теперь мы занимаемся разработкой новой системы.
Зачем всё это?
Если вы дочитали до этого места, то скорее всего вы ищете ответ на вопрос: «А зачем всё это?». В первую очередь реставрация – это отдельный процесс, не похожий на разработку, не похожий на сопровождение, но совмещающий их.
Это отдельный драйв для технического специалиста – вникнуть в логику того, кто создавал этот продукт, понять его смысл, очистить продукт от лишнего и сделать его еще лучше, чем был. Приложение выглядит как квест, с множеством загадок и неизвестными поворотами сюжета.
Нет вы не создаете с нуля, вы восстанавливаете уже существующий, но, возможно, разрушенный временем продукт. Помимо прочего, у реставратора появляется уникальная возможность прокачиваться в любом из шести направлений (см.картинку выше), при этом имея в качестве тестовой базы под руками реальный продукт. Прокачивается и чувство самоконтроля – не свалиться в технический перфекционизм, а продумывать и вносить только изменения, которые необходимы системе с точки зрения улучшения процессов.
Все это делает работу с легаси системами увлекательной и необычной. Но окончательный выбор реставрировать или поддерживать – остается за вами.
Доклад Михаила Занковича на Luxoft TechFest можно посмотреть по ссылке.
Автор статьи Михаил Занкович MikhailZankovich
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_java, #_testirovanie_vebservisov (Тестирование веб-сервисов), #_java, #_restavratsija (реставрация), #_arhitektura (архитектура), #_testirovanie (тестирование), #_bazy_dannyh (базы данных), #_project_management, #_data, #_blog_kompanii_luxoft (
Блог компании Luxoft
), #_java, #_testirovanie_vebservisov (
Тестирование веб-сервисов
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 20:04
Часовой пояс: UTC + 5