Как рефакторить большие системы

[Dhwtj]

Вот вам предельно политкорректный отзыв/выжимка от LLM. Я бы выразился крепче: вода.

Заголовок "Как рефакторить большие системы" предполагает, что статья будет содержать конкретные рекомендации и стратегии по проведению рефакторинга больших систем. Однако, содержание статьи в основном фокусируется на описании текущего состояния системы, проблем, с которыми столкнулась команда, и методов оценки состояния системы.

Связь между содержанием и заголовком можно увидеть в следующих аспектах:

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

2. Идентификация проблем: Описание текущих проблем в системе (например, циклические зависимости, сложная структура, использование устаревших технологий) помогает понять, какие области требуют внимания при рефакторинге.

3. Подготовка к рефакторингу: Статья указывает на необходимость понимания бизнес-запросов и жизненного цикла продукта перед началом рефакторинга. Это помогает определить, целесообразно ли вкладывать ресурсы в рефакторинг на данном этапе.

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

[Pan_Stephan]

спасибо за комментарий! Я решил разбить статью на 4 части, как и написано в самом ее начале. Эта вводная часть, которая лишь погружает в проблематику. В оставшихся частях будет больше конкретных действий.

[bjl]

Спасибо, интересно, прочёл бы продолжение.

П.С. приоритИзация.

[TTA]

Тема интересная. Не бросайте)

[MainEditor0]

Вот бы LLM, которая может съесть гигабайты кодовой базы...

[Rhbnbr]

Если мы определили, что бизнес планирует дальнейшее развитие, то мы можем начать оценивать текущее состояние системы по метрикам. Они бывают 2 видов:

1. Технические

2. Менеджерские

Технические метрики описывают состояния продукта / инфраструктуры
Менеджерские - систему управления.

Вообще, продукт который разрабатывался 7 лет в стол - очень тяжелый случай. И как я понял из вашего описание, да и иначе и быть не могло, он имел большие архитектурные проблемы.
И анализ именно архитектурных проблем и качества кода, на мой взгляд является главной задачей при вхождении со стороны на такие проекты.
Если продукт еще не вышел в прод и не находится под серьезной нагрузкой, технических метрик, у нас может еще и не быть, а просто сидеть и дожидаться проблем не стоит.

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