Ключ к быстрому и эффективному проектированию систем

1. Осознанность
рефакторинга
Евгений Кривошеев,

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

3. Сценарий

4. Понятие качества
Scope, Defects
Time Resources
Quality

5. Сценарий

6. Обоснование через качество
Не уверен, что делаю в коде
так, потому что надо…
…или потому что так
написано в книжке

7. Кейсы рефакторингов
// extract method

8. Кейсы рефакторингов
// move method

9. Кейсы рефакторингов
// extract class

10. Кейсы рефакторингов
// creator pattern → factory pattern

11. Кейсы участников
• Напишите на листочке
последнюю сложную или
нерешенную проблему
• Последний holy war
• Проблема любая, но
желательно в контексте
дизайна / рефакторинга
• В конце Вы решите её для себя

12. Сценарий

13. Задача рефакторинга
Привести дизайн
к желаемым характеристикам
Какие характеристики
желаемые?*
*→быть фабрике или
создателю?

14. Сценарий

15. Место QA в требованиях

16. Важность простоты

17. Простота vs Понятность*

18. Влияние D.M. на QA
Дизайн должен
реализовать
требования

19. Рефакторинги и QA
Рефакторинг Гибкость Простота Понимаемость Тестабельность
extract method
extract class
move method
introduce factory
↑ или ↓ или ?
Меняя дизайн, меняем и QA

20. Сценарий

21. Корреляции требований

22. Корреляции требований

23. Корреляции требований
Требования зачастую
конфликтуют.
Дизайн – это компромисс.*
*За все приходится платить

24. Конфликты требований
интеллект
готовка
уборкаTCO
специальные
навыки
Ирка Петрова
Саша Грей

25. Design is a tradeoff
Factory
Pattern
Cache
Pattern

26. Design is a tradeoff
Нет «хорошего» и «плохого»
дизайна.
Есть подходящий и
неподходящий.

27. Так быть или не быть?
Factory
Pattern

28. Сценарий

29. Минутка матана
<матан>
<a>Вторая теорема Гёделя о неполноте</a>
</матан>

30. Метамодель дизайна

31. Дизайн через требования
Инкапсулируем
ответственность в
класс
Инлайнируем
ответственность
Гибкость Простота
Функционал
вариабелен
(ось вариативности)
Функционал
стабилен

32. Полнота требований
Функционал
вариабелен
(ось вариативности)
Функционал
стабилен?

33. Метамодель требований
BDUF YAGNI

34. Метамодель требований
BDUF YAGNI?

35. Метамодель процесса

36. Сценарий

37. Обоснованный дизайн
Инкапсулируем
ответственность в
класс
Инлайнируем
ответственность
Гибкость Простота
Функционал
вариабелен
(ось вариативности)
Функционал
стабилен?
BDUF YAGNI
?
?

38. Обоснованный дизайн
Наличие java interface в кодев итоге обосновываетсябизнес-моделью компании

39. Сценарий

40. Отлить в граните
• Рефакторинг – направленное
обоснованное изменение дизайна.
• Дизайн – это компромисс. За все
нужно платить.
• Необходимо выявить конфликт
ожиданий.
• Для принятия решения следует
подняться выше на уровень
абстракции.
• Решения локальны и специфичны.

41. Персональный кейс
Получилось ли решить Ваш
кейс?*
*Если нет, продолжим за

42. Контакты
Евгений Кривошеев, ekrivosheyev@scrumtrek.ru
«Тяжело в учении – легко в бою»
SkillTrek – это корпоративный центр компетенций,
где специалисты получают востребованные на
рынке знания и навыки в условиях реальных
проектов с выбором удобной им загрузки