Мой доклад с XP Days Ukraine 2011

1. SOLIDный код:
с TDD это просто
Сергей Калинец http://tdd4.net
Skype: sergiikalinets
@skalinets

2. Обо мне
• Более 10 лет в промышленной разработке
• Руковожу разработкой в киевском офисе
компании CompatibL
• Тренер по инженерным практикам в
scrumguides.com
• Ведущий клуба практической разработки в
stratoplan.ru

3. Disclaimer
Надиктовано КО

4. История одного
проекта

5. TDD: добро
• Уверенность в коде до запуска
• Нет лишнего кода
• Быстрее принимаются решения

6. TDD: зло
• Замедление
рефакторинга
• Сложные тесты
• Каскадные
отказы тестов

7. Жизнь проекта
• Черное-белое-черное-белое, а потом -- …

8. Как победить зло?

9. Уровни качества

10. Плохой дизайн это…

11. Неоправданная
сложность
В системе есть инфраструктура, которая или
не используется, или используется
неправильно

12. Повторение
Дубликаты структур, которые
должны иметь общую
абстракцию.

13. Мутность
Код сложно понимать

14. Жесткость
Систему сложно изменять.

15. Монолитность
Сложно выделить компоненты, которые
можно использовать повторно

16. Вязкость
Делать что-то правильно сложнее, чем
делать это неправильно.

17. Хрупкость
Изменения легко
ломают систему и
приводят к новым
изменениям.

18. Решение
• Single Responsibility
• Open/Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion

19. Single Responsibility
У класса есть только одна ответственность,
он умеет ее делать и делает ее хорошо

20. Single Responsibility
from http://microsoftnlayerapp.codeplex.com/

21. Single Responsibility: Test
• Данные
– Что знает?
– Какие связи
между объектами
поддерживает?
• Поведение
– Что решает?
– Какие услуги
предоставляет?

22. Single Responsibility
Show me the code:
MessageHandler

23. Open/Closed
• Программные сущности
(классы, модули, методы и т.д.) должны
быть открыты для расширения, но
закрыты от изменений
Было
Стало

24. Open/Closed и TDD
• Нет каскадных отказов
тестов
• Не нужно менять
работающий код
• Про тесты я уже
говорил?

25. Open/Closed
Show me the code:
OrderCalculator

26. Liskov Substitution
Клиенты, использующие базовый класс,
должны работать и с его наследниками, не
зная этого.

27. Liskov Substitution
• Предусловия не могут быть ужесточены в
наследнике
• Постусловия не могут быть ослаблены в
наследнике
• Инварианты базового типа должны
соблюдаться и в наследнике
• Исторические ограничения

28. Liskov Substitution и TDD
• Тесты могут проверять использование
наследников вместо предков
• В случае нарушения юнит тесты
усложняются

29. Liskov Substitution
Show me the code:
ReadOnlyQueue

30. Interface Segregation
• Utility Modules should be included
полностью
• Тесты на страже Extract interface/base class
• Тестовые дублёры могут скрывать
нарушения

31. Interface Segregation
Клиентам не должны навязываться
интерфейсы, которые им не нужны.

32. Interface Segregation и TDD
• Тестовые дублеры диктуют API
• Тесты усложняются, когда зацепление
понижается
• Тесты обезбаливают разбиение
интерфейсов

33. Dependency Inversion
• Высокоуровневые модули не должны
зависеть от низкоуровневых. Оба должны
зависеть от абстракций.
• Абстракции не должны зависеть от
деталей. Детали должны зависеть от
абстракций.

34. Dependency Inversion и TDD
• Service Locator или Dependency Injection?
• Двойники в TDD создают абстракции
• Настройка тестов легче с Dependency
Injection

35. Dependency Inversion
Show me the code

36. Начать никогда не поздно!
• Extract interface/superclass
• Use base type where possible
• Extract parameter

37. SOLID & YAGNI & KISS
Yo Aren’t Gonna Need It
Keep It Simple Stupid

38. Выводы
• SOLID упрощает TDD
• TDD упрощает SOLID
• Вместе они упрощают нашу жизнь

39. Спасибо!
Сергей Калинец http://tdd4.net
Skype: sergiikalinets
@skalinets