Что такое рефакторинг Tic Tac Toe и почему мы делаем его в LASERHUB?
TLDR: после одного успешного года в бизнесе наша кодовая база наследует вонючие части, которые мы хотим постоянно рефакторить. Итак, как сделать рефакторинг интересным для всех — и все включают в себя все заинтересованные стороны: команду разработчиков, коллег по бизнесу, клиентов, партнеров… Итак, вот что мы делаем: мы принимаем эту маленькую, но все же очень популярную игру крестики-нолики в качестве рабочего процесса рефакторинга. .
Игра
Общая идея всего этого: мы получаем итеративный процесс со сквозной ценностью для каждого шага. Значение в этом термине относится к классическим целям рефакторинга. Лучшая читабельность, ремонтопригодность, производительность, знания среди членов команды и т. д.
Таким образом, несмотря на то, что мы можем потерять немного времени, следуя перечисленным ниже правилам, ценность того, чтобы инженеры погрузились в наше приложение и научились новым навыкам друг у друга, гораздо важнее, чем разбивать функции и позволять кодовой базе разрушаться. Помните: мы создаем потрясающую команду, поэтому очень важно инвестировать время и ресурсы и быть инновационными в этой области. Хороший код будет создаваться только уполномоченными инженерами. Вот как мы это попробуем.
Правила
Следуя простому набору правил, мы надеемся привлечь команду инженеров к участию в более масштабном рефакторинге, не теряя фокуса, избегая ошибок и постепенно улучшая нашу кодовую базу.
Крестики-нолики так легко описать, поэтому мы придумали этот набор правил
- Существует набор столбцов, которые представляют различные уровни в приложении (например, внешний интерфейс, API/бизнес-логика, тестирование, модели данных и т. д.).
- Существует набор строк, представляющих приращения ваших усилий по рефакторингу (в нашем случае это различные домены, которые мы хотим провести сквозной рефакторинг).
- Когда вы создаете свою собственную игровую доску, начните с небольшой сложности внизу и постепенно увеличивайте сложность вверх.
- Каждая линия поставляется набором инженеров
- Один инженер может быть размещен только в одном столбце в строке.
- Инженеры перемешаны между рядами, поэтому они работают над разными столбцами/задачами.
- Не допускается стек инженеров
- Прежде чем вы сможете начать работать над рядом, необходимо закончить следующий ряд.
- Готово определяется
- Для каждой строки создается одна ветвь
- Ветка содержит весь код, связанный с соответствующей строкой
- Все необходимые модификации кода для конкретной строки делают все инженеры
- Проведен обзор кода для обсуждения необходимых изменений
- Согласованные изменения вносятся во все части кода
- Филиал полностью развернут в тестовой системе
- Испытания прошли успешно
- Филиал объединен и развернут в рабочем приложении
- Команда побеждает, когда все ряды заполнены/сделаны
LASERHUB — как, вероятно, и любой другой стартап — сталкивается с ситуацией ограниченных ресурсов, огромного отставания, срочности и срочности, увеличения продаж (это хорошо!), повышения ожиданий клиентов (тоже хорошо!), …
Рефакторинг в этом контексте — или управление скрытой дорожной картой — нуждается в хорошей методологии, чтобы быть успешным и бесконфликтным. Заинтересованные стороны бизнеса надеются увидеть новые функции, которые упростят процесс или увеличат продажи. Команде по работе с клиентами нужны новые функции и исправление ошибок. Инженеры хотят работать над новыми захватывающими модулями с новейшими технологиями в потрясающей кодовой базе. Правда в том, что в какой-то момент вам регулярно нужно делать какую-то домашнюю работу, и мы строго хотим избежать того, чтобы это делал какой-то случайно выбранный инженер по хозяйству.
Рефакторинг Tic Tac Toe фокусирует внимание (т. е. фокусируется на одном домене), увеличивает ценность за счет приращений (каждая строка создает ценность) и может выполняться параллельно с текущей разработкой функций, поскольку для рефакторинга части приложения не требуется вся команда. и для выполнения поставленной задачи не требуется полный ресурс в течение x дней.
Это еще больше снижает риск того, что один инженер рефакторит одну часть приложения, а другой расширяет его с помощью функций (слияние, подверженное ошибкам, — лишь одна из причин разочарования здесь). Многие разработчики вовлечены в процесс — они знают, что рефакторится, и могут заявить слово, если ожидают конфликтов (пожалуйста, сделайте это!).
Мы понимаем, что при использовании этой методологии некоторые части рефакторинга займут больше времени. Простые домены могут быть рефакторингом одним инженером за день или два. Наша стратегия состоит в том, чтобы заставить всех инженеров учиться в простых областях, быстро и часто терпеть неудачи в простых областях, завоевать доверие к выбранным вами мерам рефакторинга (фреймворкам, технологиям, шаблонам и т. д.), начать любить новый код, который вы создаете. а затем прибить жесткую часть.
В конце концов, мы надеемся, что это принесет немного удовольствия и приведет к лучшему коду.
