Пост о реинжиниринге как методе работы

(домашка к первой главе курса по методологии)

Что делал: реинжиниринг микросервиса, реинжиниринг бизнес-логики, моделирование, перепроектирование. Ситуация: есть микросервис, в котором много legacy, старых и мало кому понятных сейчас решений. Внесение “линейных” обновлений стало слишком дорогим. Проект: рефакторинг сервиса. Субпроект 1: сделать такое описание системы, которое будет служить стартовой точкой. Субпроект 2: сделать инъекцию идей и (внезапно) методов из DDD.

Метод декомпозирую на такие практики:

  • Сбор информации
    • Определение источников
    • Устные опросы агентов
    • Письменные опросы агентов
    • Анализ документации
    • Использования системы/Имитация пользовательских сценариев
  • Выявление интересов
    • Подойти и спросить
  • Дистилляция данных
    • Выделение объектов
    • Классификация
    • Моделирование табличками
    • Формализация
    • Онтологическое моделирование
  • Описание::метод (описание текстом чего то)
    • Описание для себя
    • Описание для читателя
    • Деление по уровням системы
  • Обработка обратной связи
    • Через комментарии в конфе от коллег
    • Через комментарии онлайн
  • Другое
    • Маппинг/связывание (таблички Юлии и своей/продуктов и технарей)
    • Введение понятий/Единого языка
    • Тиражирование единого языка
  • Стратегирование
  • Управление тактом

Стратегирование - это новинка этой недели. Управление тактом - это когда я проектирую X работ до следующего такта обратной связи, конкретно в этом проекте это такой объем работ, который в моем воображении даст максимум полезной обратной связи в цикле сделать работу-получить ОС. Выделяю эти методы как “особенные”, потому что они не то чтобы входят в реинжиниринг, а, я бы сказал, являются над-/трансметодами, куда не примени, станет лучше. И вот здесь я видел в них пользу, и применил, если бы реинжиниринг каких то систем был для меня шаблонным, наверное, мне эти два пункта и не были нужны.

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

Извлечение данных — это достать из информации то, что не является “шумом и оттенками”. Это все то, что проверяемо и проверено, а не догадки других людей. По смыслу это близко к понятию дистилляция из DDD Эванса. Выделение объектов - это когда разработчик тебе пишет как это работает, и его описание является описанием спагетти-кода, т.е. ровно таким же запутанным и непонятным, а ты выделяешь из этого объекты (абстрактные, которые в коде), называешь их и говоришь “ты пишешь про это”. Классификация - это когда объекты классифицируются по их свойствам, классификация нужна если не всегда, то почти всегда. Моделирование табличками - это та самая структуризация, в моем случае это были сценарии использования и бэковые объекты бизнес-логики, которые в каждом сценарии меняли свои состояния. Формализация в моем мире - это метод упрощения сложного, так я называю лютое пережимание больших табличек в таблички поменьше.

Выявление интересов. У меня явно не “Игра престолов”, так что я просто спросил у каждого, что им нужно.

Описание есть как минимум две категории, для себя и для кого то. В моем случае кем то были: архитектор, продукт-менеджер, рук. отдела, разработчик, лид команды. Читателей много, они по-разному погружены в контекст, у них разный профессиональный уровень, у них разные интересы, и для каждого из них необходимо написать так, чтобы ему было понятно. Понятность я определяю по кол-ву встречных вопросов, а для разработчика в его субъективной “этого достаточно для работы”.

Обработка обратной связи. Комментарии в конфлюенс: читаю комментарий, делю что написано на два класса: если автор указал мне на ошибку/неточность/пропуски, то просто дополняю доку этой информацией; если спросил про то, что не понимает, иду дальше по пути выбора описать по-другому или не делать этого (может человек просто был не внимателен); если его вопрос “глубже”, чаще всего о противоречиях, то это становится предметом исследования (если оно того стоит). Кажется замороченным, но важнейший шаг валидации что сделано о пользователей того, что сделано. С комментариями в других местах ± также.

Маппниг/связывание в моем проекте было связыванием сценариев использования (например, сценарий номер 6.1) и правил из конфигурации (одна из табличек, правила работы функции). Не то чтобы большая работа, но я ее делал, а значит она была частью метода. Введение единого языка - выделить объекты, назвать объекты, определить объекты и (почему я поместил это отдельно от выделения объектов) согласовать определения. Чтобы языком стали пользоваться, все вокруг должны увидеть его полезность, и это не произоейдет сразу/вдруг, поэтому в здесь я для каждого понятия еще пишу ассоциативный ряд, а еще пишу то, что не является определяемым в методе как пояснение, а еще специально употребляю только термины единого языка. В общем это не “тосты поджарить”, ввести единый язык отдельный метод от того, чтобы нацарапать глоссарий в конфле и сказать всем “надо говорить так, потому что провильно”.

Выводы:

  • Практики повторяемы и вообще похожи на “адаптивные функции”/классы. И под “адаптивностью” я здесь имею в виду то, что для какой то работы я беру как бы “экземпляр” метода, такой его паттерн, который не избыточен конкертно для этой ситуации. Вот я так специально пишу, чтобы уйти от управления методом как функцией через аргументы/что она “должна” на входе получать. Потому что в моей головое для каждого метода в момент работы нет всех возможных вариантов входа, если для обратной связи мне нужно ответить на комментарии в конфе, я даже не думаю о том, чтобы делать это в комментариях в джире.
  • Чего в списке методов нет? Способов перейти от описания (про которое все скажут да-да понятно) до проекта самого рефакторинга, в котором будут таски и план работ. Снова история про целевую систему и ее безудержный поиск. Подумаю.
  • Хочется какую то оценку ресурсов, чек-листы для каждого метода, в общем описать/определить его для себя так, чтобы он стал натреннированно нативным. Но реинжиниринг я делаю не то чтобы часто, поэтому следствием вижу выбрать наиболее используемую практику и ее описать, а не метод в целом.
  • Подумал о принципиальной схеме всего этого мероприятия. Вторая мысль про то, что снова сомнения идти в это из-за высокой ресурсности описания схемы, это по-сути еще один проект сбоку, и не факт что он нужен мне или кому то.
  • Вижу некоторое пересечение и смешивание практик, тоже выделение объектов и введение единого языка. Не одно и то же, но очень близко, нужно пробовать разделять разными способами.
2 лайка

Меня тут по соседству поправляли, что возможно пропущен этап классификации проблемы. Кажется у вас он тоже какой-то неявный. Стало дорого вносить обновления. Ага, а есть разбор причин? Там например, опрос разработчиков показал, что 1) 6 человек считают - задержки вызваны тем, что код непонятный (отсутствуют комментарии) 2) 7 человек - код плохо структурирован, в негл неудобно вносить изменения 3) ещё 5 человек пришли в команду недавно, кодовую базу не знают и всё предыдущее усложняет ситуацию. Это навскидку. А если людей вы опросили по сценариям использования, может оказаться что треть сервиса можно просто поудалять и никто не заметит разницы. Потому что что-то делали, а этим уже не пользуются например.

В зависимости от распространнености причин и их влияния на замедление скорости ваш рефакторинг можно делать очень разными методами. Пока для меня рефакторинг звучит как “мы нашли старый сервис, он нам зачем-то нужен, надо всё переписать”. Стоимостное обоснование/описание может сильно заземлить планы все переписать.

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

И ещё немного запуталась. Стратегирование это ж как раз выбор метода. А вы вроде кучу работы уже сделали, там даже проектирование/моделирование есть. А из чего выбирали, как делать рефакторинг? Откуда там вдруг DDD взялся?

1 лайк

Меня тут по соседству поправляли, что возможно пропущен этап классификации проблемы.

Поинт хороший, но в данном случае все крайне очевидно, только 1 из 7 разработчиков может писать код в модуль за какое то адекватное кол-во времени. На отделе это висит как риск “а если он уйдет”.

Стратегирование это ж как раз выбор метода. А вы вроде кучу работы уже сделали, там даже проектирование/моделирование есть.

Не, в начале, он сначала был в отдельном списке, потом склеил списки и оставил в конце. Техническая причина.

Откуда там вдруг DDD взялся?

Единый язык и модель предметной области как верхний/core слой архитектуры софта.