CUPID

Статья про параметры CUPID:

https://dannorth.net/2022/02/10/cupid-for-joyful-coding

Автор предлагает писать код ориентированный на CUPID, вместо следования устаревшим по его мнению принципам SOLID.

Отличная статья, аргументация на высоком уровне. Каждый из параметров заслуживает пристального рассмотрения.

Краткое определение параметров:

C - Composability, возможность блоков кода “стыковаться” друг с другом

U - Unix philosofy, делай что-то одно, но хорошо

P - Predictability, отсутствие сюрпризов в коде

I - Idiomatic, единообразный, узнаваемый стиль

D - Domain-based, код основанный на предметной области

Дале мои комментарии к статье, в контексте разработки на PHP.

Composability

Отсутствие простой интеграции одного кода с другим является серьёзной проблемой, масштаб и последствия которой сообщество веб-разработчиков ещё не осознаёт.

Я об этом пишу, автор статьи об этом пишет, но в целом сообщество такой проблемы даже не замечает, а если и уделяет внимание то на самом поверхностном уровне.

Я считаю, что любой написанный код должен интегрироваться с другим одним простым действием, “по нажатию кнопки”.

Сейчас имея Git, Github, менеджеры пакетов такие как Composer и NPM и поисковики как Packagist мы от этого не так далеки как раньше, но всё же усилий для подключения требуется сильно больше, чем “нажать кнопку”.

В рамках кодовой базы одного проекта можно добиться высокой “Composability”, но если смотреть шире, то интеграция кода из разных проектов всё ещё очень сложна и усилиями одного разработчика эту проблему не решить.

В этом направлении есть ещё вагон работы.

Unix philosofy

Этот параметр требует бережливого и вдумчивого подхода к проектированию модуля.

“Делает хорошо что-то одно” это логическое развитие принципа “Low Coupling, High Cohesion” (низкое зацепление, высокая связность), только переориентированного со структуры кода на его практический смысл.

Predictability

Код должен быть предсказуемым.

Для этого мы используем TDD и в целом автоматическое тестирование. Хорошо протестированный код обречён быть логичным и предсказуемым, иначе просто не получится написать для него хорошие тесты.

Idiomatic

Стиль написания и организации кода должен быть таким, чтобы в коде можно было легко ориентироваться, читать и понимать его.

По этому параметру сообществом проделана большая работа.

Здесь у нас есть PSR и другие стандарты кодирования и утилиты как CS Fixer для автоматического приведения кода к одному виду и проверок на соблюдение правил.

Domain-based

Группировка кода по предметной области ассоциируется с DDD, и для большей части программистов это ещё неосвоенная территория.

Хотя принципы группировки кода по бизнес-контексту, “юзкейсам” являются самым лучшим вариантом, но они не являются естественными для программистов.

Естественным образом программист группирует “по типу”, то есть “контроллеры”, “модели” и так далее.

Более опытные программисты группируют код “по функциональности”, то есть создают модули “отправка почты”, “кеш”, “роутинг”.

И уже только самые опытные программисты достигают понимания что код лучше всего группировать “по назначению”, то есть создавать модули по юзкейсам: “склад”, “промоакции”, “партнёрка”, “корзина”.

Группировка по юзкейсам хоть и является редкой и непривычной сегодня, но это самый эффективный способ организации кода.