(домашка к первой главе курса по методологии)
Что делал: реинжиниринг микросервиса, реинжиниринг бизнес-логики, моделирование, перепроектирование. Ситуация: есть микросервис, в котором много legacy, старых и мало кому понятных сейчас решений. Внесение “линейных” обновлений стало слишком дорогим. Проект: рефакторинг сервиса. Субпроект 1: сделать такое описание системы, которое будет служить стартовой точкой. Субпроект 2: сделать инъекцию идей и (внезапно) методов из DDD.
Метод декомпозирую на такие практики:
- Сбор информации
- Определение источников
- Устные опросы агентов
- Письменные опросы агентов
- Анализ документации
- Использования системы/Имитация пользовательских сценариев
- Выявление интересов
- Подойти и спросить
- Дистилляция данных
- Выделение объектов
- Классификация
- Моделирование табличками
- Формализация
- Онтологическое моделирование
- Описание::метод (описание текстом чего то)
- Описание для себя
- Описание для читателя
- Деление по уровням системы
- Обработка обратной связи
- Через комментарии в конфе от коллег
- Через комментарии онлайн
- Другое
- Маппинг/связывание (таблички Юлии и своей/продуктов и технарей)
- Введение понятий/Единого языка
- Тиражирование единого языка
- Стратегирование
- Управление тактом
Стратегирование - это новинка этой недели. Управление тактом - это когда я проектирую X работ до следующего такта обратной связи, конкретно в этом проекте это такой объем работ, который в моем воображении даст максимум полезной обратной связи в цикле сделать работу-получить ОС. Выделяю эти методы как “особенные”, потому что они не то чтобы входят в реинжиниринг, а, я бы сказал, являются над-/трансметодами, куда не примени, станет лучше. И вот здесь я видел в них пользу, и применил, если бы реинжиниринг каких то систем был для меня шаблонным, наверное, мне эти два пункта и не были нужны.
Сбор информации работает на увеличение ее объема. Спросить у того кто знает, или тот, кто может знать хотя бы кусочек информации. Почитать документацию, написанную когда то, и может уже неактуальную. Потыкаться сейчас в то, как работает сервис, воспроизвести пользовательские сценарии.
Извлечение данных — это достать из информации то, что не является “шумом и оттенками”. Это все то, что проверяемо и проверено, а не догадки других людей. По смыслу это близко к понятию дистилляция из DDD Эванса. Выделение объектов - это когда разработчик тебе пишет как это работает, и его описание является описанием спагетти-кода, т.е. ровно таким же запутанным и непонятным, а ты выделяешь из этого объекты (абстрактные, которые в коде), называешь их и говоришь “ты пишешь про это”. Классификация - это когда объекты классифицируются по их свойствам, классификация нужна если не всегда, то почти всегда. Моделирование табличками - это та самая структуризация, в моем случае это были сценарии использования и бэковые объекты бизнес-логики, которые в каждом сценарии меняли свои состояния. Формализация в моем мире - это метод упрощения сложного, так я называю лютое пережимание больших табличек в таблички поменьше.
Выявление интересов. У меня явно не “Игра престолов”, так что я просто спросил у каждого, что им нужно.
Описание есть как минимум две категории, для себя и для кого то. В моем случае кем то были: архитектор, продукт-менеджер, рук. отдела, разработчик, лид команды. Читателей много, они по-разному погружены в контекст, у них разный профессиональный уровень, у них разные интересы, и для каждого из них необходимо написать так, чтобы ему было понятно. Понятность я определяю по кол-ву встречных вопросов, а для разработчика в его субъективной “этого достаточно для работы”.
Обработка обратной связи. Комментарии в конфлюенс: читаю комментарий, делю что написано на два класса: если автор указал мне на ошибку/неточность/пропуски, то просто дополняю доку этой информацией; если спросил про то, что не понимает, иду дальше по пути выбора описать по-другому или не делать этого (может человек просто был не внимателен); если его вопрос “глубже”, чаще всего о противоречиях, то это становится предметом исследования (если оно того стоит). Кажется замороченным, но важнейший шаг валидации что сделано о пользователей того, что сделано. С комментариями в других местах ± также.
Маппниг/связывание в моем проекте было связыванием сценариев использования (например, сценарий номер 6.1) и правил из конфигурации (одна из табличек, правила работы функции). Не то чтобы большая работа, но я ее делал, а значит она была частью метода. Введение единого языка - выделить объекты, назвать объекты, определить объекты и (почему я поместил это отдельно от выделения объектов) согласовать определения. Чтобы языком стали пользоваться, все вокруг должны увидеть его полезность, и это не произоейдет сразу/вдруг, поэтому в здесь я для каждого понятия еще пишу ассоциативный ряд, а еще пишу то, что не является определяемым в методе как пояснение, а еще специально употребляю только термины единого языка. В общем это не “тосты поджарить”, ввести единый язык отдельный метод от того, чтобы нацарапать глоссарий в конфле и сказать всем “надо говорить так, потому что провильно”.
Выводы:
- Практики повторяемы и вообще похожи на “адаптивные функции”/классы. И под “адаптивностью” я здесь имею в виду то, что для какой то работы я беру как бы “экземпляр” метода, такой его паттерн, который не избыточен конкертно для этой ситуации. Вот я так специально пишу, чтобы уйти от управления методом как функцией через аргументы/что она “должна” на входе получать. Потому что в моей головое для каждого метода в момент работы нет всех возможных вариантов входа, если для обратной связи мне нужно ответить на комментарии в конфе, я даже не думаю о том, чтобы делать это в комментариях в джире.
- Чего в списке методов нет? Способов перейти от описания (про которое все скажут да-да понятно) до проекта самого рефакторинга, в котором будут таски и план работ. Снова история про целевую систему и ее безудержный поиск. Подумаю.
- Хочется какую то оценку ресурсов, чек-листы для каждого метода, в общем описать/определить его для себя так, чтобы он стал натреннированно нативным. Но реинжиниринг я делаю не то чтобы часто, поэтому следствием вижу выбрать наиболее используемую практику и ее описать, а не метод в целом.
- Подумал о принципиальной схеме всего этого мероприятия. Вторая мысль про то, что снова сомнения идти в это из-за высокой ресурсности описания схемы, это по-сути еще один проект сбоку, и не факт что он нужен мне или кому то.
- Вижу некоторое пересечение и смешивание практик, тоже выделение объектов и введение единого языка. Не одно и то же, но очень близко, нужно пробовать разделять разными способами.