Принципы solid на практике
TRANSCRIPT
Как использовать
● Делить функционал на классы
● Следить за чистотой классов во время:- Разработки- Баг-фикса- Хот-фиксов
Как использовать
● Разделить сущности в проекте на категории- Экспериментальные- Стабильные- Deprecated (Не рекомендованные)
● Ввести в проект процедуру заморозки API классов- Дать коду вылежаться- Провести ревью кода перед заморозкой
Как использовать
• Пишите юнит-тесты на интерфейсы и базовые классы
• Запускайте юнит-тесты для базового класса или интерфейса на классах наследниках
Как использовать
• Не бояться “создавать интерфейс ради интерфейса”
• Следить за чистотой интерфейсов во время:– Разработки– Баг-фикса– Хот-фиксов
Как использовать
• Писать тесты
• Писать код без new()– Вынести логику создания объектов наружу,
в управляющий код
Backbone и SOLID
● Нет иерархии View
● Смешивание ответственности View- из-за неправильного использования(!)
Flux, Redux и SOLID
● Четко очерченные зоны ответственности- Action creator- Dispatcher- Store- View(from React)
● Redux - нарушает принцип единственной ответственности
● Redux - нет информации, как расширять приложение
React и SOLID
● Четко очерченные зоны ответственности- View
● shouldComponentUpdate - имеет слишком большую ответственность
● Реализации контекстов не хватает для Dependency Injection (не Dependency Inversion)
Один из предков в деревереализуетshouldComponentUpdate
Выбор дочернего компонента происходит через механизм внедрения зависимости
Что же делать дальше
● SOLID - не икона, чтобы молиться
● Продолжать обучаться- использовать SOLID при написании кода
● Делать ретроспективы- изучать влияние на скорость багфикса- изучать влияние на скорость рефакторинга
Спасибо!Q&A
twitter: amuzalevskiy
Почитать:http://goo.gl/soxxEw