[.NET, Проектирование и рефакторинг] Королевские рефакторинги с Roslyn
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Всем привет! Давно хотел написать эту статью, но материал всё никак не собирался: всё-таки рефакторинг - не на каждый день развлечение. Особенно если крупный. Речь пойдёт о том, как можно использовать Roslyn для лечения разной боли в шарповом коде. Если по центру вашего проекта возвышается огромная куча неудобного легаси и вам страшно на неё смотреть - добро пожаловать под кат. Возможно, мой материал позволит взглянуть на проблему с другого ракурса и понять, что не всё так печально. По идее сам подход может быть применим к любому языку, экосистема которого включает в себя тулинг для компилятора. Но это не точно. Однако, я расскажу всё, что знаю на двух примерах из реальной жизни.ПредысторияЧто вообще такое легаси? Дословно это переводится "наследие". В контексте - куча кода, которая написана давно, на старых технологиях, с использованием старых, глупых или попросту странноватых подходов. Все понимают что легаси-код - это плохо, но никто ничего не решается с ним сделать: с одной стороны вроде как всё работает, а работает - не трожь. А с другой стороны объём работы будет такой, что парализует всю разработку. Кстати тот редкий случай, когда разработчики с менеджерами могут обняться и заплакать. Первые не хотят вкладываться в разгребание тех. долга, а вторым не хочется ковыряться в вековых залежах сомнительных субстанций. Вот и висят такие куски как бельмо на глазу. Бесят всех, разработку замедляют, развитие продукта блокируют.Осмысленная переработка легаси - это больно. Создаётся примерный план как от всего этого избавляться, легаси-часть проекта консервируется (лучше - если в отдельном репозитории), новая функциональность начинает дописываться как бы "сбоку", а легаси-часть используется через API. В лучшем случае этот API стараются обложить unit-тестами, после чего весь легаси записывают в технический долг, который потихоньку начинают сортировать под пристальным наблюдением архитекта. Архитект же, отвлекаясь от построения дата-пайплайнов, носится вокруг возникающих пулл-реквестов, следит за грануляцией и циклическими зависимостям. Ну это в лучшем случае. В худшем же, легаси-код продолжает жить своей жизнью до тепловой смерти вселенной, абстрагированный от новых фич.В общем, избавление от легаси-кода - долгий процесс, требующий выдержки руководителя, политической воли владельца продукта и координации работы нескольких десятков человек. Я сам расчётов не видел, но полагаю что на ФОТ и эффективность в пересчёте на фича-километры такие изменения влияют не лучшим образом. И такая ситуация, по моим наблюдениям - чуть ли не в КАЖДОМ проекте. Ладно, преувеличиваю, конечно, но частенько случается. Кто виноват и как так вышло - не предмет этой статьи. А важно вот что: в определённых случаях можно очень хорошо "срезать углы" и раскидаться с застарелым легаси-техдолгом, используя достижения теории трансляции и компиляции. Рассказываю как это сделать в уютном мире C# и .NET.RoslynМоё знакомство с Roslyn случилось совершенно случайно. Мы сошлись на почве ненависти к JavaScript-у. Случилось это ещё в доwebpack-овскую эпоху, когда веб-приложения уже начали усложняться, а тулинга толком ещё не было. В свете софитов тогда были extJS, незамедлительно превращающийся в страх и ужас на масштабных проектах, GWT, который работал, кажется, только внутри гугла, а приложухи по-проще благоразумно сидели на jQuery. TypeScript тогда не было и в проекте, так что мы выживали как могли. Писать на чистом JS мне категорически не нравилось, потому как медленно и многословно. А вот C# я знал превосходно. Да, я знал о существовании Bridge.NET, DuoCode и Script#. На первые два у меня не было денег, а Script# не нравился своей монументальностью. Перегружать mscorlib из коробки - это же фу как грубо. Ну и ReSharper с ним не дружил.Будучи юношей бледным со взором горящим, я решился на авантюру. Сделать велосипед. Свой транслятор из C# в JS с блекджеком и визитёрами. Если так посудить, то мне много не надо - так... Генерить портянки бойлерплейта, переводя шарповые классы в прототипы. Ну и переписывать на JS мелкие методы с основными управляющими конструкциями. Циклы-условия, вот это всё. О трансляции-компиляции я тогда знал мало (в активе - НГУшный курс МТК), а свободное время жгло карман. Чего б не попрактиковаться? И я нырнул в это болото.Парсить C# руками оказалось непросто. Нужна была грамматика. Я сделал что-то подобное на CoCo/R для Javascript (да, мои вкусы специфичны и я больной ублюдок), но повторять этот номер для C# или адаптировать готовую грамматику, создавать сотню классов для нод и токенов решительно не хотелось. Нужно было готовое решение. Я безрезультатно поковырял ANTLR и уже было загрустил, как тут на моё счастье вышла одна из первых RC-версий Roslyn.Сейчас Roslyn разросся и больше известен как .NET Compiler Platform. Если кратко, то это набор библиотек, содержащий лексеры-парсеры, превращающие шарповый (и не только) код в поток токенов и в AST. Это дерево можно обходить визитёрами и переписывать. Другие части Roslyn умеют строить семантическую модель кода и связывать её с AST. Можно даже грабить корованы собирать код в исполняемый файл. Прямо в рантайме! Вообще, если заморочиться, то с помощью Roslyn можно сделать собственный диалект C# с бочкой синтаксичекого варенья и compile-time печенья. Но это - удовольствие для истинных ценителей. Даже я при всей своей отшибленности и авантюрности не рекомендую так делать. Креш-курс по Roslyn можно найти вот в этой статье. Она старая, но подход принципиально с тех пор не изменился. Так что я не вижу смысла делать туториал, да и в принципе показывать какой-то код. Вместо этого, я бы хотел рассказать про два конкретных кейса очень удачного применения магии синтаксического анализа для спасения вполне себе живого проекта из бездны безблагодатности. Возможно, это даст кому-то пищу для размышлений и позволит по-новому взглянуть на рефакторинг или на свой продукт.А чем закончилась история с моим транслятором? Да ничем. Забросил. Стало напряжно корректно обрабатывать замыкания, а потом появился TypeScript и потребность в подобных разработках отпала как класс. Поэтому, давайте к кейсам.Кейс №1: прощаемся с VB.NETВводные: небольшая компания, работающая со складом. Система складского учёта объёмом примерно 200-300 тысяч строк кода. Она была невесть у кого куплена, потом криво проаутсоршена и, в общем, в самом центре системы находится сборка с кодом на Visual Basic .NET. Сотни три небольших классов: DTO-шки, сущности и, как водится, статические классы с логикой.Что болит: VB.NET-код и болит. В нём довольно много логики в масштабах проекта и за фиксом каждого бага приходится лазить туда. На проекте всего 3 разработчика и своими силами перелопатить такую кучу кода не представляется возможным. Функциональность пилится медленно, онбордить новых людей в проект сложно (кандидаты разбегаются, услышав про VB.NET). Хочется съехать на EntityFramework с LINQ2SQL, но все планы на радужное будущее упираются в этот чёртов кусок VB.NET-а.Как решаем: основная идея состоит в том, чтобы набросать на коленке транслятор из VB.NET в C#. Без претензий на универсальность, сугубо для конкретного случая. Технически это обычный визитёр, наследующий VisualBasicSyntaxVisitor<CSharpSyntaxNode>, которому скармливаются все .vb-файлы, разложенные в AST средствами самого Roslyn. Каркас транслятора был сделан за несколько часов, после чего в течение недели он допиливался напильником по bleeding-edge методологии "запускаем - смотрим результат - правим - запускаем". Такой рефакторинг на уровне AST хорош тем, что не производит логических ошибок (если у вас руки и голова на месте). Все ошибки видны на этапе компиляции, но процессор перманентно загружен сборкой кода. Как gentoo собирать, только почему-то в Visual Studio.Челленджи: Visual Basic.NET довольно сильно отличается от C#. Например, он производит просто тонны неявных приведений типов в самых неожиданных местах (например, в LINQ-запросах). Чтобы как-то жить с этим адом пришлось построить семантическую модель, указать вручную все используемые dll-ки и слёзно просить Roslyn выводить тип во всех подозрительных местах. В результирующем C#-коде транслятор заботливо расставлял касты к требуемым типам. В основном это были преобразование численных типов данных, но ощущения неприятные.Второй челлендж - сами LINQ-запросы. Тут даже я с удивлением обнаружил, что синтаксис LINQ в VB.NET довольно сильно отличается от оного в C#. Как ни странно, не в пользу последнего. Для трансляции LINQ-запросов пришлось заводить отдельный маленький визитёр, со своим контекстом трансляции, который корректно вытянет все range variables на свет б-жий, а так же развернёт конструкции вроде Distinct/Take/While в вызовы шарповых методов. И всё равно некоторые group join-ы в итоге пришлось править руками, благо их было немного.Результат: трансляция прошла успешно. Примерно неделя ушла на настройку транслятора, после чего пару дней я почистил код руками - и вуаля. Структура кода позволяла тупо убрать модификатор static и получить на выходе вполне себе сервисы логики, которые были тут же запихнуты в IoC. Итого около двух недель занял полный перевод VB.NET-кода на C#. Провернуть что-то подобное мечтало и руководство и немногочисленные разработчики, но никто не знал как. Через некоторое время мы съехали на EntityFramework, наняли ещё разработчиков и продолжили пилить фичи с удвоенной скоростью. Успех достигнут. На радостях менеджмент одарил меня деньгами, пригласил на корпоратив в Европу, оплатив билеты, а на месте одарил душевными презентами, которые были привезены обратно в Новосибирск и там выпиты. Мы долго и плодотворно сотрудничали, но это уже совсем другая история.Кейс №2: геноцид статикиВводные: добрых размеров компания, в разработке 5 команд по 5 человек, разнородный стек технологий, но преимущественно C#/.NET. Продукт с гигантским количеством функциональности. 700 тысяч строк кода. Состоит это добро из нескольких WebAPI-проектов, 5 штук виндовых сервисов, делающих разные вычисления и трёх сотен dll-ок только в основном солюшене. Сложная мультиарендная инфраструктура с базами-кэшами-очередями, плюс облачная часть-админка. Исполнено всё на .NET 4.8.Что болит: покоится эта махина на нескольких огромных сборках, содержащих - увы и ах - статические классы. В них - старая, поросшая паутиной статическая бизнес-логика, а так же доступ к БД. Да, все обращения к базе прибиты гвоздями к нескольким статическим методам, которые вычитывают строку подключения из конфига (база разная для каждого клиента) и создают подключения. Из-за этого сервисы невозможно отодрать от базы, а следовательно никакой тебе мультиарендности и динамического скейлинга. По техническим причинам само подключение к базе данных прибито гвоздями к .NET 4.8 из-за чего любая попытка перевести продукт на .NET Core влоб терпит неудачу. Любому, кто начнёт этот поход - уже через пару дней становится очевидно что тут работы на полгода, не меньше. Не говоря уже о том, что покрыть это unit-тестами не представляется возможным без убойных костылей. О том, чтобы раздробить этот монолит никто даже и не думает. Как решаем: первый шаг навстречу прекрасному будущему - убить статические классы, к которым приклеена система. Решать задачу будем в несколько этапов.
- Подготавливаем код вручную.
- Вычищаем мелкий мусор: 5-6 классов ведущих себя как ActiveRecord, какие-то невнятные вложенные классы, файлы с несколькими классами и прочая чушь. Пара часов максимум на это уходит;
- Вся монструозность держится на трёх вспомогательных классах. Ну вы знаете - Util, Common и Aux. Читаем их код, обнаруживаем кучу статической работы с инфраструктурой. Сеть там, файловая система, база. Особенно мне запомнился extension-метод для выполнения SQL-команд. Он используется как "DELETE FROM table".ExecuteSql(). Ковырять такое синтаксическим анализом неудобно, поэтому просим Rider сделать нам Convert - Extension Method to Plain Static. Идём пить чай, пока Rider думает над этой задачей (10-15 минут). Допивая чай, делаем то же самое ещё на дюжине методов;
- Сортируем методы вспомогательных классов руками, вычленяя чистые функции. Это всё пока без Roslyn, чисто Rider-овским Move-ом. По итогу ручной сортировки все чистые функции уходят в отдельный класс, а во вспомогательных классах остаётся не более 50 методов. Перетасовываем их по семантике - и вуаля: вместо невнятных Util, Common и Aux имеем вполне логичные SqlService, FileSystemService, NetworkService. Они всё ещё статические, поэтому я их копирую, переименовываю в Refactored*Service, убираю модификатор static и делаю extract interface. Таким образом, для каждого статического класса, на которые опирается система - имеем вполне себе интерфейс/реализацию. Прогресс! Дело за малым - заменить одно на другое;
- В дело вступает Roslyn. В стороннем проекте с подключённым Roslyn-ом загружаю все C#-файлы из солюшена продукта. Задача проста: пройтись по каждому файлу, найти где используются наши статические классы, сделать локальное поле, добавить параметр в конструктор (для IoC), поменять все места использования.
То есть как-то так, если делать руками, только автоматически3. Вручную убираем всякую чушь вроде написанного на коленке ServiceLocator-а и синглтонов. Занятие довольно скучное, в пояснениях не нуждается. Удаляем код - собираем - смотрим где упало - чиним. Можно было написать рефакторинг и для этих действий, но таких мест в коде было не более 30 - вполне можно разрулить руками, не включая головной мозг.4. Чиним IoC-контейнер. Все статические классы превратились в сервисы и их надо прописать в IoC-е.Челленджи: Беда пришла откуда не ждали: оказывается, в системе есть и другие статические классы, зависящие от изначальных. Ну кто бы мог подумать! (sarcasm) Статические классы пирамидкой нагромождены друг на друга, а на их основе уже построены обычные классы-сервисы. И я только что выбил у этой пирамидки фундамент. Произошло примерно следующее:
Что делать? Опускаю промежуточные рассуждения и сразу перехожу к решению: заводим реестр, в который добавляем информацию о том, какие статические классы затронуты в ходе преобразования. Само же преобразование проводим в несколько проходов, пользуясь на каждом шагу новой и новой информацией из реестра. Короче, жмакаем F5 до тех пор, пока реестр не перестанет пополняться, что ознаменует смерть всех статических классов:
Второй челлендж - починить IoC-контейнер. Тут я начал выпендриваться: построил модель связей между классами. Покрутил её туда-сюда, даже попробовал отрисовать через graphviz (такая фигня получилась). По этой модели связей сгенерил довольно сносные регистрации для NInject, однако дело осложнялось наличием кастомных провайдеров для некоторых сервисов и лайфтаймовой магией, которую можно было воспроизвести только руками. На красивую модель связей я в итоге забил и сделал проще: написал unit-тесты, проверяющие консистентность контейнера. Тут всё довольно прозаично: создаём IoC-контейнер, применяем регистрации, пытаемся достать из контейнера требуемые сущности. Тест падает, читаем описание NInject-а что пошло не так, добавляем в IoC нужные классы, запускаем снова. И так пока тест не станет зелёненьким. Container Consistency-тесты, кстати, остались. Увеличили покрытие кода ажно на 3% (около 20 тысяч строк в масштабе проекта).Кстати, оффтоп: в Tecture вот проблемы с контейнером отсутствуют как класс из-за позднего связывания на типах. Но до Tecture тут далеко - нам бы статические классы выкинуть.Результат: всё работает. Пулл-реквест на 1500 изменённых файлов вмерджен в мастер, релиз прошёл успешно. На написание и отладку всей Roslyn-овой обвязки ушла примерно пара недель. Плюс ещё пара недель на бюрократию, фикс упавших (по синтаксическим причинам) юнит-тестов и проваленных автотестов. Директор отдела признал что 15 поломанных автотестов (из 1500) после такого рефакторинга - это успех. Дружеские похлопывания по плечу, "you did something considered impossible", "Pavel did revolution". Уже на следующий день после мерджа в мастер другие команды побежали переводить веб-сервисы на .NET Core, настраивать мультиарендность и покрывать тестами всё, что плохо лежит. Мне подарили презент, который был незамедлительно распит и дали халявную неделю дейоффов. Непосредственный начальник признался что я - один из лучших, кого он когда-либо нанимал. Happy end.Кейс №3: бонус (Tecture)Я настолько люблю Roslyn что использую его в своих проектах. Да, это совсем не про рефакторинг, зато про Roslyn. А суть вот в чём. В своих предыдущих статьях я рассказывал, что Tecture позволяет генерировать unit-тесты и автоматически захватывать тестовые данные из инфраструктуры. Когда я впервые додумался до этой тупой, как валенок идеи, встал вопрос - а в каком виде это добро хранить? Как сериализовать очередь команд и ответы от внешних систем? Это всё шарповые классы и их можно, конечно, скинуть в JSON, но есть пара сложностей. Во-первых JSON не любит циклические ссылки (которые нет-нет, да и проскакивают). А во-вторых, unit-тест должен оставаться "в контакте" с основным кодом приложения. То есть хочется чтобы в случае чего тест сначала переставал собираться, а не сразу вероломно падал. Я не нашёл ничего лучше чем скидывать тестовые данные и валидацию команд в тот же самый шарповый код.Строковая шаблонизация плохо работает на таких задачах, так что я сразу взял Roslyn. Сделал несколько классов-прокладок для метаданных (чтобы не тащить Roslyn в само ядро Tecture) и написал соответствующие генераторы. Код, конечно, получился грязноват и лично мне в нём сложновато разобраться после долгого перерыва. Однако, свою задачу он выполняет на ура. Валидация и тестовые данные получаются опрятными и красивыми.ВыводыЧто надо сказать в первую очередь: для королевских рефакторингов лучше иметь тесты. Чем больше - тем лучше. Какие угодно тесты становятся важны, когда проводишь столь массивные изменения. Из моих двух кейсов первый был наиболее рисковым - тестирование в проекте отсутствовало как класс. Выручали только масштабы: система по современным меркам была довольно маленькая, да и изменения касались в основном служебного кода (а не логики). А основные кейсы вполне можно было прокликать руками.Во втором кейсе у меня было довольно много тестов: около полутора тысяч unit-тестов и ещё примерно столько же автотестов UI. И они своим падением - таки да, помогли выловить несколько бажных мест, которые я упустил. Однако, главным другом и боевым товарищем в таких походах по-прежнему остаётся компилятор. Я давно топлю за максиму "всё, что может упасть на этапе сборки - должно упасть на этапе сборки", и в этом случае я в очередной раз на своей шкуре убедился как это важно. Roslyn же, применённый к месту вполне может сэкономить кучу времени и ничего не поломать. У меня всё. Ставьте плюсы, подписывайтесь на мой телеграм-канал.Успехов.
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-инфраструктура, Сетевые технологии] Network Infrastructure — how is it seen by hyperscalers
- [Разработка под iOS, Разработка мобильных приложений, Разработка под Android, Swift] Онлайн-митап DevDay Mobile: C++ -> Swift, скрытый API Android и будни разработчика
- [Разработка мобильных приложений, Здоровье, IT-компании] Google завела на Android прививочные карточки с QR-кодами
- [Программирование, Анализ и проектирование систем, Совершенный код, Проектирование и рефакторинг, ООП] Метрика Cognitive complexity или простой способ измерить сложность кода
- [Законодательство в IT] Роскомнадзор попросил соцсети удалять страницы, предлагающие поддельные QR-коды, и заблокировал 19 таких сайтов
- [.NET, C#] Миграция Bing's Workflow Engine на .NET 5
- [Ненормальное программирование, Программирование, Совершенный код, C++, C] Металингвистический совратитель Си. Опус III: Садистская машина
- [Kotlin] Detekt — пишем свои правила
- [C++, Подготовка технической документации] Документирование кодовой базы. Зачем и как?
- [Информационная безопасность, Законодательство в IT, Здоровье] Специалисты нашли уязвимость в системе доступа к московскому общепиту по QR-кодам
Теги для поиска: #_.net, #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_refaktoring (рефакторинг), #_roslyn, #_.net, #_.net_core, #_rider, #_kod (код), #_ast, #_sintaksicheskij_analiz (синтаксический анализ), #_.net, #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:18
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Всем привет! Давно хотел написать эту статью, но материал всё никак не собирался: всё-таки рефакторинг - не на каждый день развлечение. Особенно если крупный. Речь пойдёт о том, как можно использовать Roslyn для лечения разной боли в шарповом коде. Если по центру вашего проекта возвышается огромная куча неудобного легаси и вам страшно на неё смотреть - добро пожаловать под кат. Возможно, мой материал позволит взглянуть на проблему с другого ракурса и понять, что не всё так печально. По идее сам подход может быть применим к любому языку, экосистема которого включает в себя тулинг для компилятора. Но это не точно. Однако, я расскажу всё, что знаю на двух примерах из реальной жизни.ПредысторияЧто вообще такое легаси? Дословно это переводится "наследие". В контексте - куча кода, которая написана давно, на старых технологиях, с использованием старых, глупых или попросту странноватых подходов. Все понимают что легаси-код - это плохо, но никто ничего не решается с ним сделать: с одной стороны вроде как всё работает, а работает - не трожь. А с другой стороны объём работы будет такой, что парализует всю разработку. Кстати тот редкий случай, когда разработчики с менеджерами могут обняться и заплакать. Первые не хотят вкладываться в разгребание тех. долга, а вторым не хочется ковыряться в вековых залежах сомнительных субстанций. Вот и висят такие куски как бельмо на глазу. Бесят всех, разработку замедляют, развитие продукта блокируют.Осмысленная переработка легаси - это больно. Создаётся примерный план как от всего этого избавляться, легаси-часть проекта консервируется (лучше - если в отдельном репозитории), новая функциональность начинает дописываться как бы "сбоку", а легаси-часть используется через API. В лучшем случае этот API стараются обложить unit-тестами, после чего весь легаси записывают в технический долг, который потихоньку начинают сортировать под пристальным наблюдением архитекта. Архитект же, отвлекаясь от построения дата-пайплайнов, носится вокруг возникающих пулл-реквестов, следит за грануляцией и циклическими зависимостям. Ну это в лучшем случае. В худшем же, легаси-код продолжает жить своей жизнью до тепловой смерти вселенной, абстрагированный от новых фич.В общем, избавление от легаси-кода - долгий процесс, требующий выдержки руководителя, политической воли владельца продукта и координации работы нескольких десятков человек. Я сам расчётов не видел, но полагаю что на ФОТ и эффективность в пересчёте на фича-километры такие изменения влияют не лучшим образом. И такая ситуация, по моим наблюдениям - чуть ли не в КАЖДОМ проекте. Ладно, преувеличиваю, конечно, но частенько случается. Кто виноват и как так вышло - не предмет этой статьи. А важно вот что: в определённых случаях можно очень хорошо "срезать углы" и раскидаться с застарелым легаси-техдолгом, используя достижения теории трансляции и компиляции. Рассказываю как это сделать в уютном мире C# и .NET.RoslynМоё знакомство с Roslyn случилось совершенно случайно. Мы сошлись на почве ненависти к JavaScript-у. Случилось это ещё в доwebpack-овскую эпоху, когда веб-приложения уже начали усложняться, а тулинга толком ещё не было. В свете софитов тогда были extJS, незамедлительно превращающийся в страх и ужас на масштабных проектах, GWT, который работал, кажется, только внутри гугла, а приложухи по-проще благоразумно сидели на jQuery. TypeScript тогда не было и в проекте, так что мы выживали как могли. Писать на чистом JS мне категорически не нравилось, потому как медленно и многословно. А вот C# я знал превосходно. Да, я знал о существовании Bridge.NET, DuoCode и Script#. На первые два у меня не было денег, а Script# не нравился своей монументальностью. Перегружать mscorlib из коробки - это же фу как грубо. Ну и ReSharper с ним не дружил.Будучи юношей бледным со взором горящим, я решился на авантюру. Сделать велосипед. Свой транслятор из C# в JS с блекджеком и визитёрами. Если так посудить, то мне много не надо - так... Генерить портянки бойлерплейта, переводя шарповые классы в прототипы. Ну и переписывать на JS мелкие методы с основными управляющими конструкциями. Циклы-условия, вот это всё. О трансляции-компиляции я тогда знал мало (в активе - НГУшный курс МТК), а свободное время жгло карман. Чего б не попрактиковаться? И я нырнул в это болото.Парсить C# руками оказалось непросто. Нужна была грамматика. Я сделал что-то подобное на CoCo/R для Javascript (да, мои вкусы специфичны и я больной ублюдок), но повторять этот номер для C# или адаптировать готовую грамматику, создавать сотню классов для нод и токенов решительно не хотелось. Нужно было готовое решение. Я безрезультатно поковырял ANTLR и уже было загрустил, как тут на моё счастье вышла одна из первых RC-версий Roslyn.Сейчас Roslyn разросся и больше известен как .NET Compiler Platform. Если кратко, то это набор библиотек, содержащий лексеры-парсеры, превращающие шарповый (и не только) код в поток токенов и в AST. Это дерево можно обходить визитёрами и переписывать. Другие части Roslyn умеют строить семантическую модель кода и связывать её с AST. Можно даже грабить корованы собирать код в исполняемый файл. Прямо в рантайме! Вообще, если заморочиться, то с помощью Roslyn можно сделать собственный диалект C# с бочкой синтаксичекого варенья и compile-time печенья. Но это - удовольствие для истинных ценителей. Даже я при всей своей отшибленности и авантюрности не рекомендую так делать. Креш-курс по Roslyn можно найти вот в этой статье. Она старая, но подход принципиально с тех пор не изменился. Так что я не вижу смысла делать туториал, да и в принципе показывать какой-то код. Вместо этого, я бы хотел рассказать про два конкретных кейса очень удачного применения магии синтаксического анализа для спасения вполне себе живого проекта из бездны безблагодатности. Возможно, это даст кому-то пищу для размышлений и позволит по-новому взглянуть на рефакторинг или на свой продукт.А чем закончилась история с моим транслятором? Да ничем. Забросил. Стало напряжно корректно обрабатывать замыкания, а потом появился TypeScript и потребность в подобных разработках отпала как класс. Поэтому, давайте к кейсам.Кейс №1: прощаемся с VB.NETВводные: небольшая компания, работающая со складом. Система складского учёта объёмом примерно 200-300 тысяч строк кода. Она была невесть у кого куплена, потом криво проаутсоршена и, в общем, в самом центре системы находится сборка с кодом на Visual Basic .NET. Сотни три небольших классов: DTO-шки, сущности и, как водится, статические классы с логикой.Что болит: VB.NET-код и болит. В нём довольно много логики в масштабах проекта и за фиксом каждого бага приходится лазить туда. На проекте всего 3 разработчика и своими силами перелопатить такую кучу кода не представляется возможным. Функциональность пилится медленно, онбордить новых людей в проект сложно (кандидаты разбегаются, услышав про VB.NET). Хочется съехать на EntityFramework с LINQ2SQL, но все планы на радужное будущее упираются в этот чёртов кусок VB.NET-а.Как решаем: основная идея состоит в том, чтобы набросать на коленке транслятор из VB.NET в C#. Без претензий на универсальность, сугубо для конкретного случая. Технически это обычный визитёр, наследующий VisualBasicSyntaxVisitor<CSharpSyntaxNode>, которому скармливаются все .vb-файлы, разложенные в AST средствами самого Roslyn. Каркас транслятора был сделан за несколько часов, после чего в течение недели он допиливался напильником по bleeding-edge методологии "запускаем - смотрим результат - правим - запускаем". Такой рефакторинг на уровне AST хорош тем, что не производит логических ошибок (если у вас руки и голова на месте). Все ошибки видны на этапе компиляции, но процессор перманентно загружен сборкой кода. Как gentoo собирать, только почему-то в Visual Studio.Челленджи: Visual Basic.NET довольно сильно отличается от C#. Например, он производит просто тонны неявных приведений типов в самых неожиданных местах (например, в LINQ-запросах). Чтобы как-то жить с этим адом пришлось построить семантическую модель, указать вручную все используемые dll-ки и слёзно просить Roslyn выводить тип во всех подозрительных местах. В результирующем C#-коде транслятор заботливо расставлял касты к требуемым типам. В основном это были преобразование численных типов данных, но ощущения неприятные.Второй челлендж - сами LINQ-запросы. Тут даже я с удивлением обнаружил, что синтаксис LINQ в VB.NET довольно сильно отличается от оного в C#. Как ни странно, не в пользу последнего. Для трансляции LINQ-запросов пришлось заводить отдельный маленький визитёр, со своим контекстом трансляции, который корректно вытянет все range variables на свет б-жий, а так же развернёт конструкции вроде Distinct/Take/While в вызовы шарповых методов. И всё равно некоторые group join-ы в итоге пришлось править руками, благо их было немного.Результат: трансляция прошла успешно. Примерно неделя ушла на настройку транслятора, после чего пару дней я почистил код руками - и вуаля. Структура кода позволяла тупо убрать модификатор static и получить на выходе вполне себе сервисы логики, которые были тут же запихнуты в IoC. Итого около двух недель занял полный перевод VB.NET-кода на C#. Провернуть что-то подобное мечтало и руководство и немногочисленные разработчики, но никто не знал как. Через некоторое время мы съехали на EntityFramework, наняли ещё разработчиков и продолжили пилить фичи с удвоенной скоростью. Успех достигнут. На радостях менеджмент одарил меня деньгами, пригласил на корпоратив в Европу, оплатив билеты, а на месте одарил душевными презентами, которые были привезены обратно в Новосибирск и там выпиты. Мы долго и плодотворно сотрудничали, но это уже совсем другая история.Кейс №2: геноцид статикиВводные: добрых размеров компания, в разработке 5 команд по 5 человек, разнородный стек технологий, но преимущественно C#/.NET. Продукт с гигантским количеством функциональности. 700 тысяч строк кода. Состоит это добро из нескольких WebAPI-проектов, 5 штук виндовых сервисов, делающих разные вычисления и трёх сотен dll-ок только в основном солюшене. Сложная мультиарендная инфраструктура с базами-кэшами-очередями, плюс облачная часть-админка. Исполнено всё на .NET 4.8.Что болит: покоится эта махина на нескольких огромных сборках, содержащих - увы и ах - статические классы. В них - старая, поросшая паутиной статическая бизнес-логика, а так же доступ к БД. Да, все обращения к базе прибиты гвоздями к нескольким статическим методам, которые вычитывают строку подключения из конфига (база разная для каждого клиента) и создают подключения. Из-за этого сервисы невозможно отодрать от базы, а следовательно никакой тебе мультиарендности и динамического скейлинга. По техническим причинам само подключение к базе данных прибито гвоздями к .NET 4.8 из-за чего любая попытка перевести продукт на .NET Core влоб терпит неудачу. Любому, кто начнёт этот поход - уже через пару дней становится очевидно что тут работы на полгода, не меньше. Не говоря уже о том, что покрыть это unit-тестами не представляется возможным без убойных костылей. О том, чтобы раздробить этот монолит никто даже и не думает. Как решаем: первый шаг навстречу прекрасному будущему - убить статические классы, к которым приклеена система. Решать задачу будем в несколько этапов.
 То есть как-то так, если делать руками, только автоматически3. Вручную убираем всякую чушь вроде написанного на коленке ServiceLocator-а и синглтонов. Занятие довольно скучное, в пояснениях не нуждается. Удаляем код - собираем - смотрим где упало - чиним. Можно было написать рефакторинг и для этих действий, но таких мест в коде было не более 30 - вполне можно разрулить руками, не включая головной мозг.4. Чиним IoC-контейнер. Все статические классы превратились в сервисы и их надо прописать в IoC-е.Челленджи: Беда пришла откуда не ждали: оказывается, в системе есть и другие статические классы, зависящие от изначальных. Ну кто бы мог подумать! (sarcasm) Статические классы пирамидкой нагромождены друг на друга, а на их основе уже построены обычные классы-сервисы. И я только что выбил у этой пирамидки фундамент. Произошло примерно следующее:  Что делать? Опускаю промежуточные рассуждения и сразу перехожу к решению: заводим реестр, в который добавляем информацию о том, какие статические классы затронуты в ходе преобразования. Само же преобразование проводим в несколько проходов, пользуясь на каждом шагу новой и новой информацией из реестра. Короче, жмакаем F5 до тех пор, пока реестр не перестанет пополняться, что ознаменует смерть всех статических классов:  Второй челлендж - починить IoC-контейнер. Тут я начал выпендриваться: построил модель связей между классами. Покрутил её туда-сюда, даже попробовал отрисовать через graphviz (такая фигня получилась). По этой модели связей сгенерил довольно сносные регистрации для NInject, однако дело осложнялось наличием кастомных провайдеров для некоторых сервисов и лайфтаймовой магией, которую можно было воспроизвести только руками. На красивую модель связей я в итоге забил и сделал проще: написал unit-тесты, проверяющие консистентность контейнера. Тут всё довольно прозаично: создаём IoC-контейнер, применяем регистрации, пытаемся достать из контейнера требуемые сущности. Тест падает, читаем описание NInject-а что пошло не так, добавляем в IoC нужные классы, запускаем снова. И так пока тест не станет зелёненьким. Container Consistency-тесты, кстати, остались. Увеличили покрытие кода ажно на 3% (около 20 тысяч строк в масштабе проекта).Кстати, оффтоп: в Tecture вот проблемы с контейнером отсутствуют как класс из-за позднего связывания на типах. Но до Tecture тут далеко - нам бы статические классы выкинуть.Результат: всё работает. Пулл-реквест на 1500 изменённых файлов вмерджен в мастер, релиз прошёл успешно. На написание и отладку всей Roslyn-овой обвязки ушла примерно пара недель. Плюс ещё пара недель на бюрократию, фикс упавших (по синтаксическим причинам) юнит-тестов и проваленных автотестов. Директор отдела признал что 15 поломанных автотестов (из 1500) после такого рефакторинга - это успех. Дружеские похлопывания по плечу, "you did something considered impossible", "Pavel did revolution". Уже на следующий день после мерджа в мастер другие команды побежали переводить веб-сервисы на .NET Core, настраивать мультиарендность и покрывать тестами всё, что плохо лежит. Мне подарили презент, который был незамедлительно распит и дали халявную неделю дейоффов. Непосредственный начальник признался что я - один из лучших, кого он когда-либо нанимал. Happy end.Кейс №3: бонус (Tecture)Я настолько люблю Roslyn что использую его в своих проектах. Да, это совсем не про рефакторинг, зато про Roslyn. А суть вот в чём. В своих предыдущих статьях я рассказывал, что Tecture позволяет генерировать unit-тесты и автоматически захватывать тестовые данные из инфраструктуры. Когда я впервые додумался до этой тупой, как валенок идеи, встал вопрос - а в каком виде это добро хранить? Как сериализовать очередь команд и ответы от внешних систем? Это всё шарповые классы и их можно, конечно, скинуть в JSON, но есть пара сложностей. Во-первых JSON не любит циклические ссылки (которые нет-нет, да и проскакивают). А во-вторых, unit-тест должен оставаться "в контакте" с основным кодом приложения. То есть хочется чтобы в случае чего тест сначала переставал собираться, а не сразу вероломно падал. Я не нашёл ничего лучше чем скидывать тестовые данные и валидацию команд в тот же самый шарповый код.Строковая шаблонизация плохо работает на таких задачах, так что я сразу взял Roslyn. Сделал несколько классов-прокладок для метаданных (чтобы не тащить Roslyn в само ядро Tecture) и написал соответствующие генераторы. Код, конечно, получился грязноват и лично мне в нём сложновато разобраться после долгого перерыва. Однако, свою задачу он выполняет на ура. Валидация и тестовые данные получаются опрятными и красивыми.ВыводыЧто надо сказать в первую очередь: для королевских рефакторингов лучше иметь тесты. Чем больше - тем лучше. Какие угодно тесты становятся важны, когда проводишь столь массивные изменения. Из моих двух кейсов первый был наиболее рисковым - тестирование в проекте отсутствовало как класс. Выручали только масштабы: система по современным меркам была довольно маленькая, да и изменения касались в основном служебного кода (а не логики). А основные кейсы вполне можно было прокликать руками.Во втором кейсе у меня было довольно много тестов: около полутора тысяч unit-тестов и ещё примерно столько же автотестов UI. И они своим падением - таки да, помогли выловить несколько бажных мест, которые я упустил. Однако, главным другом и боевым товарищем в таких походах по-прежнему остаётся компилятор. Я давно топлю за максиму "всё, что может упасть на этапе сборки - должно упасть на этапе сборки", и в этом случае я в очередной раз на своей шкуре убедился как это важно. Roslyn же, применённый к месту вполне может сэкономить кучу времени и ничего не поломать. У меня всё. Ставьте плюсы, подписывайтесь на мой телеграм-канал.Успехов. =========== Источник: habr.com =========== Похожие новости:
Проектирование и рефакторинг ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:18
Часовой пояс: UTC + 5