Это первая статья из цикла, который я посвящу рефакторингу программного кода. Больше года я изучал материалы по этому навыку и, наконец, решил поделиться своими находками с вами. Тема оказалась настолько глубока и широка, что я даже не буду пытаться пересказывать всю мудрость, которой напитался за это время, но попытаюсь структурировать подход к её изучению. На каждом этапе я буду делать обзор материалов (книг и докладов), которые помогут вам разобраться с каждым кусочком этого паззла. Тут не будет абстрактных банальностей «хорошо делай – хорошо будет». Только мясо от экспертов из отрасли, чьи работы меня впечатлили.

Абстракции сложны для человека, т.к. мы привыкли оперировать тем, что ощущаем. Когда же речь заходит о их перестройке в сложной системе, мозг того и гляди наровит вообще выйти из чата. Поэтому, чтобы начать сталкиваться с подобным не только в рабочие часы, но и в свободное время, неплохо бы сперва убедиться, что у вас есть достаточный запал, который будет поддерживать всю дорогу. Как я нашёл его в себе, почему именно сейчас – об этом в первом эпизоде.

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

Сейчас же мой продукт мчится вперёд силами десятка бэкендеров, работающих в одном монолите, а бизнесу важен Time-to-Market. Редкие Merge Request-ы с экспериментальными фичами меньше тысячи строк. Несколько релизов на прод в неделю. Часто доработки cross-cutting: затрагивают и ветвящуюся бизнес логику, и интеграции с внешними сервисами, и пользовательский интерфейс. И всё это приправлено требованием по максимальной параллельности сбора данных.

Как известно, в любом успешном продукте постоянны только изменения. Поэтому покой нам только снится :-) Ещё Роберт Мартин подметил, что у бизнеса не возникают вопросы, когда изменение большого куска бизнес требований требует больших ресурсов. Но вопросы появляются, когда «логический размер» доработки, с их точки зрения, небольшой, но из-за характера изменений разработчики почему-то выставляют чек как на новое крыло от самолёта. Где-то в этом моменте звучат избитые фразы: «технический долг» и «нам нужен рефакторинг». И даже если вы договорились на перестройку, чтобы адаптироваться под изменение, появляются вопросы, как её сделать, чтобы:

• она не сломала проект;
• она не заняла непрелично много времени;
• не пришлось это же переделывать спустя какое-то время.

В распределённые системы я уже наигрался, в перформанс тоже. А вот сталкиваться на практике с вопросами эффективного дизайна кода под постоянные изменения в больших сложных кодовых базах мне не приходилось. И всё это ещё и на Golang :-) В общем, много вопросов, мало ответов и живой проект для практики. И, как я вижу, для современного Ecom-a этот навык в разработчиках очень востребован. Челлендж выглядел интересно, и я начал копать.

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