Пятничное чтиво

Сегодня порекомендую доклад Алексея Катаева Рефакторинг: договариваемся, планируем, внедряем! Расшифровку можно почитать здесь.

Основные моменты:

• Если у вас есть желание переписать всё с нуля, значит вы всё время добавляли новые и новые костыли и не рефакторили
• Если в команде отсутствует культура рефакторинга:
  • скорость разработки замедляется
  • стабильность будет падать
  • сложнее набирать новых разработчиков, ведь легаси дофига, а документации нифига
  • как результат ⇒ бизнес теряет деньги
• Необходимо проводить непрерывный рефакторинг
• Чтобы убедить руководство в необходимости рефакторинга, необходимо договариваться, а не жаловаться. Нужны конкретные предложения вместо нытья
• Определять фронт работ (список областей для рефакторинга) должны все разработчики, а не только тимлид, ведь он наверняка не в курсе всех проблем в коде.
• С чего начать? Наверняка у каждого разработчика есть код, который он ненавидит всей душой, ведь после каждого изменения в этом коде он получает 5 новых багов. Можно начать с рефакторинга этих областей.
• Вести “Рефакторинг задачи” можно в вашем привычном таск трекере.
• “Рефакторинг задачи” должны описываться по определённому формату:
  • Проблема
  • Профит
  • Возможное решение
  • Оценка по срокам
• Что с приоритетом? Как уже было сказано, разработчики лучше других знают приоритет, они и должны его выставлять.
• Выделить бюджет для рефакторинга, например 15% от времени спринта.
• Чтобы уменьшить количество нового технического долга, необходимо:
  • Заниматься ростом команды
  • Шарить знания по проекту
• По прошествии какого-то времени можно будет оценить количество технического долга и его рост.