Refactoring and TDD

Тренинг сайт события http://scrumtrek.ru/trainings/view/55/

Добавить в календарь:
Поделиться:

Зачем нужен курс бизнесу

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

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

Зачем нужен курс специалисту

Test-Driven Development изначально заточен на решение задачи длительной поддержки проекта. И по нашим наблюдениям, после внедрения TDD разработчки обычно вздыхают полной грудью. Типовые муторные проблемы с воспроизводством дефектов и внесением изменений становятся гораздо менее значимыми. Вы сразу и автоматически получаете понятный поддерживаемый дизайн и глубокое покрытие тестами. Время, проведенное в дебаге, стремится к нулю. Баги перестают быть проблемой, поскольку каждую вновь найденную проблему можно будет закрепить тестом и больше к ней не возвращаться. Автоматические тесты так же замещают ручную работу по проверке того или иного функционала перед тем, как отдать ее на финальное тестирование.

Практика TDD позволяет вспомнить давно забытое чувство – когда после завершения очередного шага разработки все заводится без проблем и с первого раза. И поначалу это может с непривычки даже пугать, но потом Вы привыкнете к этому ощущению драйва и «потока» и уже не сможете писать код, не начав с теста. Применяя рефакторинг, можно значительно повысить гибкость системы при изменении требований и значительно снизить силы на поддержку и больше внимания уделять новому функционалу. Согласитесь, разработчику всегда гораздо более комфортно работать с чистым понятным кодом, и это резко повышает продуктивность команды.

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

Для кого

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

Цели

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

  1. поймут причины технического долга и смогут на практике обоснованно оперировать ими в оценках затрат
  2. осознают характеристики и метрики поддерживаемого дизайна и смогут на практике двигаться к нему через рефакторинг
  3. узнают типовые проблемные анти-паттерны в коде («smells») и смогут идентифицировать и избавиться от них в своем проекте
  4. узнают типовые трансформации («refactorings») из общепризнанных каталогов и смогут оперировать ими в общении и использовать эти трансформации в своем проекте
  5. поймут процессные подходы к рефакторингу и смогут обоснованно выбирать из них в своей команде
  6. узнают про оценку рефакторинга и смогут эффективно закладывать ее на планировании итерации
  7. узнают, как вести рефакторинг маленькими шажками, чтобы обеспечить безопасность и уверенность
  8. значительно повысят скорость разработки, несмотря на кажущиеся дополнительные усилия на тесты
  9. научатся отличать unit testing от TDD и смогут аргументированно выбирать тот или иной подход
  10. поймут цикл разработки TDD и смогут на практике держать постоянный темп производства
  11. поймут, как TDD помогает сохранять высочайшую концентрацию и узнают про состояние «потока»
  12. поймут шаблоны TDD и смогут на практике быстро писать подддерживаемые тесты
  13. поймут типовые ошибки внедрения TDD и смогут избежать их в своем проекте
  14. Поймут области применения TDD

Для обеспечения стабильных поставок и непрерывной поддержки качества продукта тимлиды и PM:

  1. поймут процессные паттерны внедрения рефакторинга и смогут внедрить практику в своей команде
  2. поймут ключевые метрики дизайна и кода и смогут внедрить объективную оценку поддерживаемости своего продукта
  3. узнают каталоги анти-паттернов («smells») и трансформаций («refactorings») и смогут внедрить единый словарь для эффективного общения в своей команде
  4. узнают про оценку рефакторинга и смогут эффективно закладывать ее на планировании итерации
  5. повысят скорость разработки в команде, несмотря на кажущиеся дополнительные усилия на тесты
  6. Избавятся от типичных страхов, связанных с внедрением TDD и смогут доказать полезность этой практики своему руководству
  7. Поймут области применения TDD
  8. Обсудят пути внедрения TDD в команду

1 день. Вводная + Рефакторинг

Упражнение 1. Выделить метод
Упражнение 2. Переименовать переменную/метод
Упражнение 3. Переместить метод
Упражнение 4. Замена временных переменных вызовами
Упражнение 5. Frequent Renter Points
Упражнение 6. Разбить цикл
Упражнение 7. Замена switch полиморфизмом
Упражнение 8. Что будет, если проводить рефакторинг без тестов
Упражнение 9. Code smells
Упражнение 10. Разбиение условий на стратегии

Обсуждение

- Разбор ситуаций, предложенных аудиторией
- Как и когда рефакторить код
- Как включать рефакторинг в оценки
- Как рефакторить легаси код без тестов
- Маленькие шаги

 

День 2. Парное программирование, Юнит тестирование, TDD

Упражнение 0. Парное программирование
Упражнение 1. Вводим юнит тесты
Упражнение 2. Вводим TDD. Отличие юнит тестов от TDD
Упражнение 3. Рефакторинг тестов. Структура Arrange/Act/Assert. Именование. Структура.
Упражнение 4. Использование Mock объектов для работы с легаси кодом. Тесты на поведение/состояние

Обсуждение

Тесты на поведение и тесты состояние - что использовать?
Приемы из реальной жизни
Как и когда писать тесты
Как и когда фиксить баги
Как работать с легаси кодом и как гасить технический долг
Рабочий день девелопера

 

Отличия от других

Мы фокусируемся на конкретных понятных целях наших участников, поэтому все темы рассматриваются через вопросы практического применения.

Участники в рамках практики сами почуствуют специфику и смогут сделать самостоятельные выводы. А все устные обсуждения основаны не на книжных примерах, а на опыте и вопросах непосредственно участников тренинга. Мы обсудим именно Ваши проблемы и пожелания.

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

Тренер:

Антон Бевзюк

Занимается разработкой с 1996 года. Сертифицированный Скрам Мастер. Имеет 8-летний опыт применения XP, Scrum, Kanban и Lean при разработке бизнес-приложений в компании Intel. Докладчик на конференциях AgileDays, Microsot Platform, Intel Agile, Intel Summer School.

Комментарии (0):

Оставлять комментарии могут только зарегистрированные пользователи

Для получения embed кода необходимо кликнуть правой
кнопкой мыши на видео и выбрать пункт меню
'Сгенерировать HTML код'

Забыли пароль? Регистрация