11. Как использовать
● Разделить сущности в проекте на категории
- Экспериментальные
- Стабильные
- Deprecated (Не рекомендованные)
● Ввести в проект процедуру заморозки API классов
- Дать коду вылежаться
- Провести ревью кода перед заморозкой
15. Как использовать
• Пишите юнит-тесты на интерфейсы и базовые классы
• Запускайте юнит-тесты для базового класса или
интерфейса на классах наследниках
19. Как использовать
• Не бояться “создавать интерфейс ради интерфейса”
• Следить за чистотой интерфейсов во время:
– Разработки
– Баг-фикса
– Хот-фиксов
28. Backbone и SOLID
● Нет иерархии View
● Смешивание ответственности View
- из-за неправильного использования(!)
29.
30.
31. Flux, Redux и SOLID
● Четко очерченные зоны ответственности
- Action creator
- Dispatcher
- Store
- View(from React)
● Redux - нарушает принцип единственной
ответственности
● Redux - нет информации, как расширять приложение
32.
33.
34.
35. React и SOLID
● Четко очерченные зоны ответственности
- View
● shouldComponentUpdate - имеет слишком большую
ответственность
● Реализации контекстов не хватает
для Dependency Injection (не Dependency Inversion)
36. Один из предков в дереве
реализует
shouldComponentUpdate
Выбор дочернего компонента происходит через механизм
внедрения зависимости
37. Что же делать дальше
● SOLID - не икона, чтобы молиться
● Продолжать обучаться
- использовать SOLID при написании кода
● Делать ретроспективы
- изучать влияние на скорость багфикса
- изучать влияние на скорость рефакторинга