Про мой любимый рефакторинг.

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

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

Ребята сели переписывать логику и весь день убили на написание класса, который бы за один раз бы все нужное взял из базы.

В конце дня я по-дружески интересуюсь, как у них дела. Ответ: тесты красные - пока ничего не получилось.

Вот именно, говорю, поэтому и не получилось. При правильном рефакторинге тесты, если и краснеют, то очень ненадолго.

Мы сели вместе и за полчаса вытянули наверх по стеку все места, где шли обращения к базе данных. Дотянули до места, где коллекция делилась на отдельные элементы, и там сделали запросы уже на всю коллекцию, а не для отдельных элементов.

Уходя домой, один из них сказал, что мы с ним за полчаса сделали то, что они не сделали за целый день.

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

В чем секрет быстрого рефакторинга?

В комбинации быстрых надёжных тестов и маленьких шагов, "от зелёного к зелёному".

Что это даёт?

Это не сделает всю разработку быстрее в разы, но вот обширные рефакторинги - легко. В результате разработчики перестают бояться рефакторинга и больше не говорят "это невозможно" там, где раньше это значило "надо переписать все".

Что требуется, чтобы вот такое делать?

А очень дофига для этого требуется, на самом деле. К сожалению, друзья.

Во-первых, надёжные и быстрые автотесты, которым вы можете доверять. Надёжные, значит, что вы не побоитесь отправить по зелёным тестам сборку в пром. Быстрые, значит, что основной цикл обратной связи по тестам во время рефакторинга не превышает десятка секунд, максимум - двух. Не все тесты должны быть такими быстрыми, но заметная часть, та, на которую вы будете опираться при рефакторинге, должна быть. Много таких команд видели? Вот поэтому мне и пришлось делать свою с нуля.

Во-вторых, так рефакторить надо уметь. Я учился по книжкам и докладам. Моя команда училась у меня. И далеко не сразу научились.

Где на это посмотреть?

Три года назад, работая в моей любимой Айтентике, я на их канале опубликовал видео про рефакторинг, набравшее 70к просмотров, где разобрал пример такого рефакторинга из книжки Фаулера. Там эта мысль видна, но, к сожалению, она утонула в том, какой код авторы книги считали хорошим, а какой - плохим. Обратите внимание на запуски тестов и стиль работы с кодом.

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