«Давайте сохраним этот код – на всякий случай, в интересах обратной совместимости». Часто ли вам приходится слышать такие слова? Как выясняется, это очень распространенное явление. Основная масса существующего кода не в ходу (70% JavaScript функций на веб-сайтах никак не используется).

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

Два месяца назад я прочитал отличную статью из блога The Pragmatic Engineer Гергея Ороса об организации хакатона по GenAI и решил устроить хакатон внутри своей компании. Это был уже четвертый моего авторства, и стандартные, ориентированные на бизнес тематики мне уже поднадоели. Я надумал попробовать что-нибудь радикально новое.

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

Прошу любить и жаловать – Чистотон!



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

• цели Чистотона
• цифры
• всё, что нужно учесть при организации хакатона: схему оценки результатов, стабильность, подогревание энтузиазма

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

Цели Чистотона

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

Мы ставили перед собой три основные цели:

1. Организовать занятное мероприятие для всей компании
2. Привести рабочую среду в максимально опрятный вид
3. Не нанести при этом ущерба проду

Цифры

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

Из результатов, которых мы достигли, я приведу только десять основных пунктов – было прибрано и удалено еще много другого:

1. Мы урезали расходы по ежемесячным платежам на несколько тысяч долларов
2. Мы удалили 4195 файлов из кодовой базы и вдобавок 4747 строк кода
3. Мы закрыли 120 открытых pull request-ов и удалили 2851 неиспользуемых ветвей
4. Мы избавились от 22 feature-флагов и удалили 46 пакетов из зависимостей
5. Мы удалили 42 Jenkins jobs и 58 kubeflow pipelines
6. Мы отправили в архив 50 репозиториев
7. Мы удалили 63 старые таблицы
8. Мы удалили и привели в порядок 47 804 файлов на Google Drive
9. Мы удалили 159 старых документов из Confluence и отправили в архив 200 тикетов в Jira
10. Мы удалили 6 файлов Figma и 40 правил автоматизации в Jira

Что нужно учитывать при организации хакатона

Начните с простых вопросов:

• Какие команды будут участвовать? (в нашем случае – все желающие)
• Сколько времени вы отводите на мероприятие? (мы остановились на одном рабочем дне, а не полных сутках, как обычно бывает на хакатонах, и, по-моему, решение было удачным)
• Будут ли смешанные команды? (мы решили, что команды будут соревноваться в своем естественном составе, так как для минимизации рисков важно было, чтобы каждое удаление получало одобрение людей, работающих в той же области)

Далее можно переходить к более сложной задаче: продумать всё так, чтобы игра была честной, все получали удовольствие и не пострадали пользователи продукта.

Для стабильности мы ввели четыре простых правила:

1. Pull request-ы: каждый pull request должен получить зеленый свет от двоих людей, хорошо знакомых с соответствующей частью кодовой базы.
2. Особые ветви: в крупных репозиториях для мероприятия будут создаваться специальные ветви – слияние нужно проводить с ними.
3. Тестирование: каждый разработчик несет ответственность за то, чтобы провести нужные тесты при внесении изменений.
4. По завершению будет проведено полное сквозное тестирование на Cypress со всеми ветвями, чтобы убедиться в стабильности работы перед официальным релизом.

На следующий день после хакатона необходимо проследить, чтобы все pull request-ы были протестированы разом, в одной среде, и проведено слияние.

В плане QA у нас всё надежно, и среда, и покрытие тестами, так что все проблемы (в общей сложности две-три) мы отловили, и они никак не сказались на опыте наших пользователей.

Подогревание энтузиазма

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

Лично я придумал названия и логотипы для всех девяти команд-участниц.



Кроме того, я решил распечатать на листах А4 небольшие таблички с логотипом, названием и фотографиями участников и развесить их на дверях кабинетов.



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

Зачем нужна система оценки результатов?

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

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

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

Создание системы оценки

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

Мой подход был таким. Я нацелился на средний результат в 10 000 очков на команду. Затем я поговорил с людьми на разных должностях, попросил оценить, сколько времени занимает та или иная задача и сколько их реально сделать за день.

По моим оценкам, команда разработчиков должна была удалить где-то 100 файлов плюс 5000 строк кода (тут я сильно просчитался), команда DevOps – получить 1000 $ экономии, финансовая команда – удалить 10 000 файлов с Google Drive (а они в ходе хакатона удалили 47 000!). Ну или так далее.

Ключевой пункт был добавлен в правила за день до мероприятия: внутри категорий для каждого действия устанавливалась максимальная награда в 1000 очков. Соответственно, если удалить 50 файлов из папки, получишь 1000 очков (не 5000). Если удалишь 1000 строк кода из одного файла – тоже 1000 очков. Если урежешь расходы на $150 за счет удаления виртуальной машины – опять же 1000 очков (не 1500). Определить границы понятие «действие» было непросто, приходилось выносить вердикт по каждому конкретному случаю.

Тройка победителей заработала 26 000, 23 000, и 17 000 очков так что разрыв был небольшим. Подробности можно посмотреть в шаблоне на Google Docs – там расписаны очки за изменения в коде, действия по урезанию расходов, уборке в Jira и многие другие категории. Шаблон вы можете сохранить и использовать.

Как подсчитывались очки

В каждой команде я назначил капитана, который отвечал за отслеживание всех изменений и подсчет очков за эти изменения. Если хотите, чтобы всё было честно, необходимо вести учет проделанной работы.

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

В конце общее число заработанных очков делилось на количество человек в команде.

В заключение

Состязание – отличная вещь, оно добавляет увлекательности занятию, которое большинству показалось бы скучным даже в наилучших обстоятельствах (а в не самых лучших – и вовсе ужасным).

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

Также следует задуматься о последствиях второго порядка. Две недели до Чистотона никто ничего не удалял, чтобы подкопить для дополнительных очков… Не случайно некоторые считают технические хакатоны пустой тратой времени. Нужно поощрять регулярную чистку кодовой базы — у нас даже кто-то предложил наградить команду на последнем месте, раз у них оказалось так мало пригодного к удалению.

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

Дополнение

В комментариях пользователь Serhii справделиво заметил: «В смысле? Хотите сказать, что в девяти отделах, по три-четыре участника из каждого, никому не было дела до всего этого мусора, пока не объявили хакатон?»

Отвечу так: очень сложно предотвратить подобную ситуацию, особенно когда речь идет о небольшом, быстрорастущем стартапе. Всегда находится что-то более срочное, чем уборка.
Главное здесь – не повторять свои ошибки. Поэтому если устраиваете Хакатон, воспользуйтесь случаем и введите правила. Вот что сделали мы:

• Обновили политику относительно ветвей – они должны удаляться сразу после слияния.
• Добавили программы для поиска мертвого кода на будущее.
• Начали еженедельно проводить анализ затрат на облачные сервисы для выявления любых отклонений и урезания всего ненужного.
• При создании feature-флага стали создавать и тикет на его удаление в рамках соответствующего спринта (обычно пара недель после релиза).