Ниже будут разобраны основные понятия и проблемы, встречающиеся при разработке программ в парадигме ООП на языке PHP. Преподаватель курса — опытный бэкенд разработчик из Авито, Афанаьев Юрий, расскажет, как грамотно проектировать архитектуру кода, чтобы он соответствовал принципам SOLID.
Содержание:
/**/
- 1.1 Код-ревью и читаемость кода
- 1.2 Качество кода. От истории к классам
- 1.3 Вложенность и комментарии в коде
- 1.4 Работа с исключениями в коде
- 1.5 Проблемы больших проектов
- 1.6 MVC, архитектура, проектирование и абстракции
- 1.7 Проблемы плохих проектов
- 1.8 Подходы при проектировании
- 1.9 Введение в GRASP-шаблоны
- 1.10 GRASP Паттерн Low Coupling (слабая связность)
- 1.11 High Cohesion (сильное сцепление)
- 1.12 UML-шаблоны
-
Автор/спикер: Юра Афанасьев
-
Источник лекций: Ютуб-канал Avito.tech , плейлист первого сезона
-
Изученные лекции, с фрагментами конмпектов — ниже.
1.1 Код-ревью и читаемость кода
Видео: https://www.youtube.com/watch?v=YybfRrtjdXE
-
рекомендации по написанию понятного кода, примеры:
1.2 Качество кода. От истории к классам
Видео: https://www.youtube.com/watch?v=-ncCgOlujaQ
-
при классы, методы, в чем их удобство (ООП) и т.п.
-
названия методов должно всегда начинаться с глагола : SendRequest, calcSum, …
-
Пример рефакторинга (до и после):
Еще рефакторинг:
Советы:
1.3 Вложенность и комментарии в коде
Видео: https://youtu.be/T2KS6ozM_lo
Пример рефакторинга кода с большой вложенностью:
Удалять такой мусор отладочный:
-
Автор в корпоративной разработке лишний:
-
Очевидный код не нужно комментировать:
-
Совет №1: выносить условия в методы
см. книгу “Рефакторинг“ М. Фаулера.
-
Совет №2: выносить числа в константы
Когда нужны комментарии:
-
сложная бизнес-логика
-
спицифический/сложны код (highload)
-
описание очень тонкого ньюанса (“не править”)
-
объяснение сложно мат. формулы
1.4 Работа с исключениями в коде
Видео: https://youtu.be/zn42cRfWVgU
Структура обработчика исключений:
Новый термин: частичная деградация
Советы:
Советует книги:
-
“Совершенный код“, Стив Макконелл
-
“Чистый код“ Роберта Мартина
-
“Рефакторинг“ Мартина Фаулера
1.5 Проблемы больших проектов
-
Видео с лекцией: https://youtu.be/Tl2tq_nnQi4
Признаки больших проектов:
Тезис:
Борьба со сложностью проекта:
О пользе паттернов:
Когда не надо заморачиваться с оптимизацией кода:
Итого:
1.6 MVC, архитектура, проектирование и абстракции
Видео: https://youtu.be/6Xygkx6VsXc
Где реализуем бизнес-логику?
Контроллеры: антипаттерн
Дублирование логики:
Баги дублируются:
Что оставить в контроллере:
права доступа:
валидацию:
Модели: также плохи
Правильно: вынестии логику в отдельный слой/компонент:
Итого: правильная структура:
-
Архитектура и проектирование — в чем разница?
Разница:
Абстракция
-
Это 4й принцип ООП:
Пример:
Пример №2: разные области (контексты) — разные методы классов:
-
Доменная модель ~ Предметная область
Итого:
1.7 Проблемы плохих проектов
Видео: https://youtu.be/OwNOYPMdNkc
Перечисляем проблемы:
1. Закрепощенность кода
2. Неустойчивость к изменениям
3. Неподвижность кода
4. Вязкость
5. Неоправданная сложность
Пример: переход с множеста микросервисов на монолит
Принцип:
6. Неоправданные повторения
Пример:
DRY
7. Неопределенность
Пример:
Итого, список 7 проблем:
1.8 Подходы при проектировании
-
Видео : https://youtu.be/d5Tj5tAmYcE
Два подхода к реализации проекта:
Простое решение:
Сложное/правильное решение: доменная модель
-
Усложнение: добавляем скидки
Сложнее: добавлена новая сущность — Скидка:
-
Усложнение логики: бспл доставка товаров, если в месяц куплено на сумму более 10.000 руб:
Delivery и др. мб вынесены в отд. микросервис
-
Усложнение: подарочные товары
Итого:
~ KISS
~ проще работать разработчикам всех уровней
~ сложнее порог входа в проект
-
Монолит или микросервис?
Лучше монолит на старте:
простота и понятность отд. микросервиса
Итого:
См. книгу — К. Калман — “Применение UML 2.0 и шаблонов проектирования”
Назначение паттернов:
Примечания:
Слабая связность и сильное сцепление
1.10 GRASP Паттерн Low Coupling (слабая связность)
Видео: https://youtu.be/guEHShTF1B0
-
Проблема
-
Обязанность
-
Пример плохой слабой связанности (и оптимизация): ~ Order связан со множеством сущностей
-
Решение: выносим лишнее в абстракции
Цели сильного сцепления:
Пример:
~ лучше делегировать задачи или разделять их по времени
Пример кода:
НЕ Верно:
Верно: низая связанность
Пример:
Низкая связанность:
Решение: делим класс на 3 сущности:
ProductData, ProductOperation, ProductView
Итого:
Божественные классы: со множеством функций и нечетким предназначением
Пример
Верно
Не верно
Пример в коде: библиотека Doctrine
рекомендует книги:
-
“Объектно-ориентированный анализ и проектирование”, Б. Макфлин
-
“Аналитические паттерны“, М. Фаулер
1.12 UML-шаблоны
История развития:
Виды диаграмм: основные выделены
Удобно использовать UML на этапе проектирования/обсуждения архитектуры (до/вместо кодирования)
Пример диаграммы:
Диаграмма класса:
Абстрактный класс (выделяется курсивом):
Интерфейсы: отмечаются через <<….>>
Комментарии к диаграммам:
Области видимости
Связи между классами
Связь “Наследование”
Связь “Реализация“
Связь “Ассоциация“
Связь “Зависимость“
Связь “Агрегация“ и “Композиция“
Пример:
Разница между композицией и агрегацией:
Пример реализации агрегации:
Пример композиции:
Крастность в связях между классами:
Советы:
Диаграмма поледовательности
Пример диаграммы:
(детальное описание диаграммы — в видео, ссылка выше), пояснения:
Взаимосвязи диаграмме последовательности:
Советы:
Советует книгу: Мартин Фаулер: UML — Основы, 3-е издание
Рекомендую курс “Otus PHP Pro“, где разбираются все виды паттернов и понятия ООП
Нет Ответов