Ниже будут разобраны основные понятия и проблемы, встречающиеся при разработке программ в парадигме ООП на языке PHP. Преподаватель курса — опытный бэкенд разработчик из Авито, Афанаьев Юрий, расскажет, как грамотно проектировать архитектуру кода, чтобы он соответствовал принципам SOLID.

Содержание:

/**/

  • Автор/спикер: Юра Афанасьев

  • Источник лекций: Ютуб-канал Avito.tech , плейлист первого сезона

  • (warning) Изученные лекции, с фрагментами конмпектов — ниже.


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 Проблемы больших проектов

Признаки больших проектов:

Тезис:

Борьба со сложностью проекта:

О пользе паттернов:

(warning) Когда не надо заморачиваться с оптимизацией кода:

Итого:


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 Подходы при проектировании

Два подхода к реализации проекта:

Простое решение:

Сложное/правильное решение: доменная модель

  • Усложнение: добавляем скидки

Сложнее: добавлена новая сущность — Скидка:

  • Усложнение логики: бспл доставка товаров, если в месяц куплено на сумму более 10.000 руб:

(звезда) Delivery и др. мб вынесены в отд. микросервис

  • Усложнение: подарочные товары

Итого:

~ KISS

~ проще работать разработчикам всех уровней

~ сложнее порог входа в проект

  • Монолит или микросервис?

Лучше монолит на старте:

(плюс) простота и понятность отд. микросервиса

Итого:


1.9 Введение в GRASP-шаблоны

Видео: https://youtu.be/USWry_o3xAA

  • GRASP — элемент ООАП

(звезда) См. книгу — К. Калман — “Применение UML 2.0 и шаблонов проектирования

Назначение паттернов:

(звезда) Примечания:

Слабая связность и сильное сцепление


1.10 GRASP Паттерн Low Coupling (слабая связность)

Видео: https://youtu.be/guEHShTF1B0

  • Проблема

  • Обязанность

  • Пример плохой слабой связанности (и оптимизация): ~ Order связан со множеством сущностей

  • Решение: выносим лишнее в абстракции

Итого:

(плюс) Плюсы:


1.11 High Cohesion (сильное сцепление)

Проблема:

Цели сильного сцепления:

Пример:

~ лучше делегировать задачи или разделять их по времени

Пример кода:

НЕ Верно:

Верно: низая связанность

Пример:

Низкая связанность:

Решение: делим класс на 3 сущности:

ProductData, ProductOperation, ProductView

Итого:

(минус) Божественные классы: со множеством функций и нечетким предназначением

Пример

Верно

Не верно

Пример в коде: библиотека Doctrine

(звезда) рекомендует книги:


1.12 UML-шаблоны

История развития:

Виды диаграмм: основные выделены

(warning) Удобно использовать UML на этапе проектирования/обсуждения архитектуры (до/вместо кодирования)

Пример диаграммы:

Диаграмма класса:

Абстрактный класс (выделяется курсивом):

Интерфейсы: отмечаются через <<….>>

Комментарии к диаграммам:

Области видимости

Связи между классами

Связь “Наследование”

Связь “Реализация“

Связь “Ассоциация“

Связь “Зависимость“

Связь “Агрегация“ и “Композиция“

Пример:

Разница между композицией и агрегацией:

Пример реализации агрегации:

Пример композиции:

Крастность в связях между классами:

Советы:

Диаграмма поледовательности

Пример диаграммы:

(детальное описание диаграммы — в видео, ссылка выше), пояснения:

Взаимосвязи диаграмме последовательности:

Советы:

(звезда) Советует книгу: Мартин Фаулер: UML — Основы, 3-е издание


(warning) Рекомендую курс “Otus PHP Pro“, где разбираются все виды паттернов и понятия ООП

Tags

Нет Ответов

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Рубрики


Подпишись на новости
👋

Есть вопросы?