Рефакторинг – не роскошь: как внедрить культуру улучшений в команде

Код как актив

В этой статье мы поговорим о том, почему рефакторинг – это не роскошь, а скорее норма.

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

Думаю, мы все сталкивались с ситуацией: вы заходите в магазин, просите продавца-консультанта сделать что-то нестандартное, а он говорит, что не может этого сделать, потому что программа не позволяет. Он смотрит на вас щенячьими глазами, искренне пытается помочь, но говорит: «Никак я не могу это сделать». И действительно не может. В программе нет кнопки: вернуть товар, отправить в сервис, что-то сделать каким-то хитрым способом.

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

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

Перед вами график из книги Мартина «Чистый код». Он показывает, как производительность команды падает со временем. Грязный код затрудняет разработку. Техдолг, который копится, замедляет разработку новых фичей.

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

Перед вами Нонака и Такеучи, авторы модели создания знаний. Они объяснили, как появляются новые знания. И эта модель прекрасно ложится на нашу действительность.

У нас есть пользователь, который работает в нашей программе, с нашей системой, и рано или поздно у него появляется какая-то интересная идея – это неявное знание. Он общается с нашим аналитиком и говорит: «Есть классная идея, давай обсудим». Аналитик это неявное знание трансформирует в явное, формируя ТЗ. Спустя какое-то время ТЗ доходит до разработчика, разработчик работает и на основании этого явного знания делает какой-то продукт. Взаимодействуя с этим продуктом, наши пользователи снова могут получить какие-то инсайты, узнать что-то новое, сделать что-то быстрее, эффективнее, и благодаря этому у них может снова возникнуть новая идея. Этот круг мы можем продолжать множество раз.

Если наш код качественный, каждый оборот проходит быстрее. И это еще один довод, почему код – это актив.

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

Как сделать код качественным

Как сделать так, чтобы наш код был качественным?

Прежде всего не забываем разбираться в стандартах. У нас, благо, они есть на ИТС. Много ребят в Telegram пишет о стандартах, очень много видеоразборов. Стандарты – это норма. Пожалуйста, читайте стандарты, занимайтесь ими. Они написаны болью и кровью.

Пишем чистый код. Есть «Чистый код» Мартина, есть много других книг. Читайте любую – ваш код станет значительно лучше, вам будет удобнее и легче писать.

Не забываем покрывать код тестами. Бывает много разных кейсов: лень протестировать, лень что-то проверить, забыли что-то протестировать. Чтобы такой истории не было, покрыли все тестами, запустили, все отлично – пошли дальше.

Применяем принципы программирования. Принципы тоже написаны не просто так. Это некоторый опыт, некоторая боль, которая накопилась и прижилась. Им стоит следовать.

Используйте паттерны. Паттерны можно применять как объектно-ориентированные, натягивая их на 1С, так и придумывать свои личные. Паттерны решают ваши проблемы каким-то шаблонным образом. Не стесняйтесь их использовать.

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

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

Оптимизация – это улучшение производительности, потребления памяти, использования других ресурсов. Было 23 секунды, стало меньше секунды. Оптимизация прошла очень хорошо.

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

Перед вами схема применения принципов программирования. Сначала YAGNI, когда мы отбрасываем все ненужное и убираем ненужные фрагменты кода. Потом применяем KISS - делаем наш код проще. Затем применяем DRY – don’t repeat yourself. Убираем дублирование кода, и наш код из ужасного превращается в прекрасный.

Рефакторинг и деньги

Перейдем ко второй части. Тут мы будем говорить о деньгах.

Давайте будем честны: редко в каких компаниях IT-отделы генерируют прибыль. В основном мы помогаем другим отделам генерировать прибыль немного быстрее.

Представьте, что вы директор успешной компании по продаже бумаги. К вам приходят два человека из IT-отдела и говорят: «Дай денег, мы сделаем что-то, ты ничего не увидишь, но потом будет хорошо». Ваша реакция, скорее всего, будет понятной: у вас восемь проектов, которые нужно было сделать вчера, и еще парочка, которые нужно было сдать пару недель назад.

И тут главный вопрос: как донести бизнесу, что от рефакторинга он получает профит?

Это не реинжиниринг, который видно кардинально. Это не оптимизация, где можно сказать: «Было 20 секунд, стало одна секунда». Это большая проблема рефакторинга.

Но у нас есть вариант: мы можем посмотреть на наши задачи и сказать бизнесу: «Обрати внимание на наши задачи, на то, как мы с ними работаем, и ты сможешь увидеть, что от рефакторинга есть профит».

Есть признаки, которые может увидеть бизнес, не зная ни строчки кода и не залезая в наш код.

Первое – замедление разработки. Простые задачи почему-то делаются долго.

Второе – неточная оценка. Разработчики говорят: «Я сделаю эту задачу за N часов», но почему-то делают ее два дня, три дня, переносят сроки и так далее.

Третье – разработчики пугаются кода. Говорят: «Там legacy, лучше туда не лезь, не трогай, а то все сломаешь. Там разбираться надо». Все это про эту историю.

Четвертое – высокая связанность. Изменяем один фрагмент, потом понимаем, что нужно изменить другой фрагмент, за ним третий. Эта цепочка только растет.

И это ведет к хрупкой системе. Сломали в одном месте – отвалилось в другом. Сделали фичу в одном месте, чуть поменяли логику – отвалилось вообще в третьем. Откуда это взялось, непонятно.

Если все-таки выделить команде ресурс и дать ей возможность работать, мы можем увидеть интересный эффект.

Разберем на нашем примере. У нас в команде был один интересный инструмент, подключение которого было довольно сложным. Для того, чтобы его подключить, нужно было: поменять определяемый тип, изменить реквизиты объекта, изменить реквизиты на форме, править модуль объекта, модуль формы, модуль менеджера и еще один общий модуль. И в каждом нужно было поправить несколько процедур и методов, поменять ветвление, добавить еще несколько кусков кода.

Все это занимало от четырех до двенадцати часов – смотря какой разработчик делал и насколько он уже был в этом месте.

Но когда мы провели рефакторинг, ситуация поменялась. У нас появился один определяемый тип, в который нужно было добавить новый объект. И в модуле менеджера этого объекта нужно было добавить четыре метода – и все начинало работать.

Для этого мы просто отвязали все зависимости из этого инструмента и немного пересмотрели его работу. В целом, как он работал, как печатал этикетки, так он и печатал этикетки. Но подключение теперь занимает не часы, а минуты. Сейчас разработчики подключают новый объект за 5–20 минут.

Когда, мы начинаем делать задачи на порядок быстрее, то бизнес становится довольным. Мы можем подойти и сказать: «Давай сейчас мы с тобой потратим не восемь часов, а четырнадцать. Зато потом будем делать это значительно быстрее».

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

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

Во-первых, мы должны понять: код, который мы хотим отрефакторить, вообще будет изменяться? Мы туда планируем залезать или нет? Или это код проекта, который мы закроем через пару недель и перейдем на новый? Это legacy, которое мы сейчас будем как-то дорабатывать, или нет?

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

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

Как договариваться с бизнесом

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

Как минимум мы используем три разных варианта договоренности с бизнесом. В разное время то один сильнее, то другой.

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

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

Вариант, который мне нравится больше всего, – это постоянное улучшение, налог на рефакторинг. Договариваемся с бизнесом, что от задачи или от спринта тратим 10–20% времени на рефакторинг. Для бизнеса это немного: часом больше, часом меньше – не так критично. Но команда получает постоянный процесс рефакторинга, и бизнес понимает, что разработчики постоянно занимаются рефакторингом. Это уже становится нормой.

Но эти варианты надо комбинировать и смотреть по ситуации. И самое главное – не забывайте напоминать бизнесу: рефакторинг – это профит.

Как не выстрелить себе в ногу

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

Во-первых, давайте не будем делать рефакторинг кода так, чтобы после него требовалось провести еще один рефакторинг этого же кода. У нас есть вендор, есть специалисты, наш 1С-вендор позаботился о нас и сказал: «Есть стандарты, пишите правильно, пишите хорошо». Если хотя бы следовать им, код уже будет чище. Поэтому подходите к своему коду качественно, пишите чисто.

Во-вторых, я понимаю, что мы все крутые специалисты и один в поле воин, но когда мы увлекаемся – тут немного поправили, там немного поправили – проходит месяц, мы не сделали ни одной фичи, зато провели много рефакторинга. У бизнеса, скорее всего, появятся вопросы.

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

В-третьих: «Я тут поменяю одну строчку кода. Разве что-то сломается?» Кто-нибудь когда-нибудь ломал прод одной строчкой кода? Я тоже как-то ломал: остановил завод, назвав переменную общим именем общего модуля.

Так что не забывайте тестировать. Все изменения, все, что мы сделали по рефакторингу, нужно тестировать. Сейчас есть классные Vanessa Automation, YAxUnit, Vanessa ADD. Можно просто написать свои тесты. Для этого есть много возможностей. Тестировать обязательно.

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

Рефакторить надо то, что вам реально нужно, что вы реально будете использовать, переписывать, изменять, модифицировать. Кусок кода, в который вы никогда не зайдете или который в ближайшее время удалите, трогать не нужно. Пусть он остается таким, какой он есть. Рефакторить нужно то, что будет изменяться.

Если сгладить эти четыре проблемы, делать рефакторинг уже будет значительно проще и спокойнее.

Рефакторинг как часть культуры

Теперь поговорим про культуру.

Культура есть в любой команде. Неважно, занимаетесь вы ею или не занимаетесь, она у вас все равно есть. Это как законы физики: можете заниматься физикой, можете не заниматься законами физики, но они все равно присутствуют в вашей жизни.

Но культурой все-таки лучше заниматься, особенно тимлидам. И одной из частей вашей культуры как раз может быть рефакторинг.

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

Скорее всего, если вы работаете в enterprise, то у вас с этим в большинстве случаев проблем не будет. Я практически не встречал бизнес, который не вкладывается в свое будущее, в свою инфраструктуру, в свое развитие.

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

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

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

Основное – код трудно читать. Если ваша команда говорит, что там непонятно, что написано, заходит и не может сразу разобраться, то, кажется, это место уже стоит начать рефакторить.

Много дублирования. Вроде надо поправить один метод, но есть похожие вызовы, есть копипаст, который тоже вызывается. Почему-то НДС рассчитывается не в общем модуле, а сразу в трех разных объектах, и везде надо менять. Если вы такое видите – рефакторить.

Методы, которые делают все. Открываем метод: один экран, два экрана, три экрана, четыре экрана, а может быть и еще больше. Если такое есть – это однозначно рефакторить.

Для архитекторов и тимлидов важно быть примером. Если мы как лидеры не понимаем, зачем нужен рефакторинг и зачем нужен чистый код, то джун, который вдруг придет и скажет: «Мне кажется, этот метод странный, давайте его отрефакторим», скорее всего, будет захейчен. Тогда рефакторинг у нас появится в культуре нескоро.

Поэтому тимлиды, сеньоры, архитекторы должны подавать пример: показывать, как делать рефакторинг правильно, в том числе делать рефакторинг самостоятельно. Тем более для лида, чтобы не забывать, что такое код, рефакторинг – хорошее время. Дополнительно это позволяет тренировать навыки.

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

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

Также напишите своей команде регламент. У команды должны быть ответы на вопросы. Если есть какие-то дополнительные вопросы, всегда отвечайте на них. Желательно это прописать, чтобы люди могли сами обратиться, прочитать, а не дергать вас каждый раз.

Когда делать рефакторинг

Перед нами временная линия, которая показывает время и период (зеленый квадрат), когда была сделана задача. Когда делать рефакторинг? Есть несколько вариантов.

Мы можем делать рефакторинг перед задачей. Это хорошо подходит для ситуации, когда вы смотрите на код и понимаете: тут большая связанность, чтобы внести новую фичу, нужно будет изменить тут, тут и тут; здесь сложно и непонятно; здесь что-то странное. Если это есть, как раз стоит провести рефакторинг до задачи.

Можно делать рефакторинг во время задачи. Если вы заходите в метод и вдруг видите переменную «Подразделение», а в ней почему-то контрагент, то как минимум это стоит исправить и не называть контрагента подразделением. Правило Бойскаута отлично ложится на работу во время задачи.

Можно делать рефакторинг после задачи. Если у разработчика есть свободное время, если у него есть время на что-то дополнительное, надеюсь, у вас есть список техдолга, и он сможет сделать что-то из него.

Алгоритм рефакторинга очень простой. Его тоже нужно дать команде:

1. Сначала разобраться, что делает код.

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

3. Затем отрефакторить.

4. Отправить на ревью и залить изменения на прод.

Как понять, что можно отрефакторить

Во-первых, IDE. EDT замечательно подсвечивает. В конфигураторе, конечно, с этим сложнее, но пора переходить на EDT, советую. Черная тема – мой кайф.

Во-вторых, техдолг. Неважно, где вы его ведете: в табличках, в Excel, на салфетках пишете друг другу. Главное, что он у вас есть и что вы его ведете. Это очень помогает понять, что нужно сделать.

В-третьих, просто заходите в код и смотрите проблемные места. Там явно есть какие-то недочеты. Не всегда это бросается в глаза, но есть много вариантов, на что стоит обратить внимание.

Под проблемными местами я понимаю следующее.

Первое – мертвый код. Если функция или метод не используется, удалите его. Зачем тратить время на чтение и понимание? Зачем это? Вызывается он или не вызывается? Удаляйте, и все.

Второе – отсутствие симметрии. Ctrl + Shift + F, Alt + Shift + F – все выровнялось, все стало идеально. Не надо присылать лесенку. Сделайте так, как принято в вашей команде, чтобы все писали одинаково.

Если у вас есть сложный интерфейс, вы всегда можете его упростить: сделать новый интерфейс, добавить заранее какие-то предопределенные инструкции и облегчить его использование.

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

Объявление и инициализация переменных должны быть в том месте, где мы будем их использовать. Не надо определять их за километр, иначе мы забудем, что вообще в них хранится, изменялось ли что-то в них, есть ли там что-то и так далее.

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

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

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

Большие методы разбивайте. У метода должна быть одна ответственность. Он должен делать что-то одно.

Избыточные комментарии удаляйте. Комментарии должны облегчать понимание, а не дублировать код.

Если логика идет вперемешку с проверками, вынесите проверки наверх. Сначала проверили, что нужно делать, а потом уже выполняем код. Нужно ли его вообще выполнять, если мы завалились на проверках?

И, конечно, проверяем, все ли у нас по стандарту. Мы все 1Сники, пишем плюс-минус одинаково и должны придерживаться стандартов. Стандарты есть – замечательно.

Заключение

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

Но насколько нужно вкладываться в этот актив? Тут все зависит от вашей ситуации, от вашего контекста. На этот вопрос можете ответить только вы и ваш бизнес.

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

Но есть предположение, что нам все равно надо будет учиться рефакторить. Как минимум – чтобы облегчать наше общение с ИИ, помогать ему понимать наш проект, понимать, что мы от него хотим, и так далее.

Поэтому учиться рефакторить нужно здесь и сейчас. Ведь это нужно нам самим.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.