Осознанность рефакторинга: Модель принятия инженерных решений
6 likes2,397 views
Доклад Евгения Кривошеева о рефакторинге сосредоточен на том, как участники могут принимать осознанные инженерные решения для улучшения качества дизайна. Он обсуждает различные методы рефакторинга и важность понимания компромиссов в дизайне, а также выявления конфликтующих требований. В конце участники имеют возможность обсудить и решить свои нерешенные практические проблемы в контексте рефакторинга.
Осознанность рефакторинга: Модель принятия инженерных решений
- 2. Цели доклада • Участники смогут принимать осознанные инженерные решения • Участники смогут обеспечить высокое качество дизайна • Участники решат как минимум одну нерешенную практическую проблему
- 3. Сценарий
- 4. Понятие качества Scope, Defects Quality Time Resources
- 5. Сценарий
- 6. Обоснование через качество Не уверен, что делаю в коде так, потому что надо… …или потому что так написано в книжке
- 7. Кейсы рефакторингов // extract method
- 8. Кейсы рефакторингов // move method
- 9. Кейсы рефакторингов // extract class
- 10. Кейсы рефакторингов // creator pattern → factory pattern
- 11. Кейсы участников • Напишите на листочке последнюю сложную или нерешенную проблему • Последний holy war • Проблема любая, но желательно в контексте дизайна / рефакторинга • В конце Вы попробуем решить её
- 12. Сценарий
- 13. Задача рефакторинга Привести дизайн к желаемым характеристикам Какие характеристики желаемые?* *→быть фабрике или создателю?
- 14. Сценарий
- 15. Место QA в требованиях
- 18. Влияние D.M. на QA Дизайн должен реализовать требования
- 19. Рефакторинги и QA Меняя дизайн, меняем и QA Рефакторинг Гибкость Простота Понимаемость Тестабельность extract method extract class move method introduce factory ↑ или ↓ или ?
- 20. Сценарий
- 23. Корреляции требований Требования зачастую конфликтуют. Дизайн – это компромисс.* *За все приходится платить
- 24. Конфликты требований интеллект специальные готовка навыки Ирка Петрова Саша Грей TCO уборка
- 25. Design is a tradeoff Factory Cache Pattern Pattern
- 26. Design is a tradeoff Нет «хорошего» и «плохого» дизайна. Есть подходящий и неподходящий.
- 27. Так быть или не быть? Factory Pattern
- 28. Сценарий
- 29. Минутка матана <матан> <a>Вторая теорема Гёделя о неполноте</a> </матан>
- 31. Дизайн через требования Функционал Функционал вариабелен стабилен (ось вариативности) Гибкость Простота Инкапсулируем Инлайнируем ответственность в ответственность класс
- 32. Полнота требований Функционал вариабелен (ось вариативности) ? Функционал стабилен
- 33. Метамодель требований BDUF YAGNI
- 34. Метамодель требований BDUF ? YAGNI
- 36. Сценарий
- 37. Обоснованный дизайн ? ? BDUF YAGNI ? Функционал вариабелен (ось вариативности) Функционал стабилен Гибкость Простота Инкапсулируем Инлайнируем ответственность в ответственность класс
- 38. Обоснованный дизайн Наличие java i nterface в к в итоге обосно оде вывается бизнес-модель ю компании
- 39. Сценарий
- 40. Отлить в граните • Рефакторинг – направленное обоснованное изменение дизайна. • Дизайн – это компромисс. За все нужно платить. • Необходимо выявить конфликт ожиданий. • Для принятия решения следует подняться выше на уровень абстракции. • Решения локальны и специфичны.
- 41. Персональный кейс Получилось ли решить Ваш кейс?* *Если нет, продолжим за
- 42. Контакты Евгений Кривошеев, ekrivosheyev@scrumtrek.ru Никита Филиппов, nfilippov@scrumtrek.ru Асхат Уразбаев, askhat@scrumtrek.ru «Тяжело в учении – легко в бою» SkillTrek – это дистанционный центр компетенций, где специалисты получают востребованные на рынке знания и навыки в условиях реальных проектов с выбором удобной им загрузки