Как лучше организовать код?

Question

[Евгений Иванов]

Разрабатываю проекты на php, которые становятся все больше. При разработке нового проекта я столкнулся с проблемой - организацией кода в проекте, логики и т.д.

Кратко опишу мой проект и его структуру. Опишу образно и упрощенно.
Проект разделен на модули, каждый из которых выполняет свои задачи. Модуль - это отдельный проект (папка с файлами). для каждого модуля создана своя БД с именем этого модуля, содержащая таблицы, используемые при работе этого модуля.

Примеры модулей
Модуль статистики - собирает статистику.
Модуль отображения - выводит графики на экран.
Это только пара из множества модулей.

Важно обеспечить стабильность работы системы. А также независимость работы модулей.
Например, чтобы при удалении модуля статистики, модуль отображения оставался работоспособным.
(С учетом того, что он не использует модуль статистики, например его данные. )

Полная независимость модулей друг от друга не рациональна т.к. они используют общие файлы, общие функции (js билиотеки, css и т.д.). Например - для каждого модуля нужна проверка авторизации пользователя.
Значит нужна функция. Где её писать? Как организовать структуру?

Я руководствуюсь следующей логикой. Так как это общая функция т.е. будет использоваться во многих модулях, то создаю папку common.
Так как эта функция связана с безопасностью, то создаю файл security_functions.php. И там пишу функцию.
Итого имею файл common/security_functions.php и подключаю его во все модули.

Хорошо. Но теперь мне надо создать систему логирования. Чтобы знать, если вдруг пользователь не смог войти в систему (подбор пароля). По аналогии пишу функцию. Итого имею второй файл common/log_functions.php

Также мне надо работать с данными. Например создать массив с кодами ошибок. Которые будут использованы в системе логирования.

И вот тут уже возникает проблема. Новая предполагаемая функция будет работать и с данными и с безопасностью. Там будут и коды событий и коды ошибок. Куда её писать? В какой файл?
С другой стороны и функция логирования тоже связана с безопасностью. Она может писать и стандартные события (любые) и события неудачных попыток входа.

Разделение функций по назначению становится сомнительным. Особенно при огромном их числе.
Система многофункциональная у неё много задач и просто так разделить функции у меня не выходит.
Писать всё в один файл и подключать его ко всем модулям - создавать риск одной ошибкой сломать всю систему. Писать куда попало - плохо с организационной точки зрения.

Создавать 10 файлов с функциями (в которых есть и пространства имен), подключать их к модулю (или часть файлов), а потом использовать тоже затруднительно. Иногда просто забываешь а в каком файле у тебя эта функция. Ты не видишь их всех, "бегаешь по файлам".

Помимо этой проблемы, возникает ещё проблема взаимосвязи с БД.
Каждый модуль выполняет свои задачи. И для своих задач он использует свою БД, со своими таблицами.

Иногда, общеиспользуемая функция - та что используется в нескольких модулях, вынуждена брать информацию из БД другого модуля. И это снова зависимость. Удалив модуль и БД мы повлияем на работу других модулей. Изменив структуру БД мы повлияем на работу других модулей.

Возникает множество логических противоречий. Деление функций по задачам, назначению затруднительно, при их большом количестве. Деление по модулям (эти функции только используем в этом файле с этой бд) невозможно в силу того, что часть из них повторяются. Проще говоря общие - и дублировать их в каждом модуле нет смысла. Деление функций по БД - эта функция принадлежит этому модулю т.к. для него используется эта БД тоже невозможно т.к. функции могут использовать разные БД.

Надеюсь поняли о чем я говорю. Хотя это сложно, понять этот текст.)
Проще - система состоит из кучи всего и это всё крайне взаимосвязано. А надо устранить большинство связей, разложить всё по полочкам, по категориям для удобной разработки и поиска ошибок.

Как лучше организовать код? Предложения?

Comments

[Дмитрий Ларин]

Возможно, вы изобретите абсолютно новый подход к организации кода, который через несколько лет станет мировым стандартом. Возможно, но сейчас...
сейчас это похоже на какой то велосипед. То что вы описали это описание микросервисов. Раз, два, три. Проблемы взаимодейтсвия микросервисов известны давно, они решаются и описываются. Вот например в формате видео. Или вот например про модули. Я рекомендую для начала ознакомится с литературой. Мэтт Зандстра "PHP. Объекты, шаблоны и методики программирования" например.

[wAML]

Да, да. Фреймворки это новый тренд. То ООП вдруг всем понадобилось. Возьмут одну статик функцию, обернут ее в класс и ваууу. То МVC тыкали куда надо и не надо, сейчас вот паттерны и фреймворки.

По сабжу.

1) Namespace + автолоад классов
2) расширенный stdObject как null объект.
что-то типа такого:

class null_object extends \stdClass{
	public function __call($a,$b){return $this;}
	public function __get($a){return null;} 
	public function __set($a,$b){return null;}
}
// как вариант <b>return $this;</b> во всех переопределенных функциях. Это уже по вкусу.

3) Паттерн registry - чтобы не порождать одно и тоже :) В идеале им и возвращать null_object.

Автолоадер подгрузит класс по пути сопоставленному с namespace. А пути вы уже можете тусить, как посчитаете нужным и правильным.

Про автолоад Тырк
Про STD Тырк
Про registry многое написано, но ссылки не даю, так как лучше повариться и малость обдумать.

Answer 1

[Артур К.]

У меня сложилось впечатление, что вы изобрели велосипед.
В общем-то в вашем тексте много разумных находок и выводов.
Однако может вам имеет смысл выбрать какой-то фреймворк? Yii, Laravel, Symfony и т.п.
Вы автоматом получите и структуру, и порядок работы, и разделение и кучу всего, что упростило бы вам жизнь. М?

Comments

[Alex Wells]

Не знаю как на счет других фреймов, но Laravel вам НЕ упростит жизнь при разделении проекта на модули, даже если они будут зависимы друг от друга. Поверьте на слово.

[Евгений Иванов]

Зачем мне фреймворк, когда я сам могу писать что угодно по своим правилам?
Как я понимаю, фреймворк хорош для типовых задач. Мои же задачи не всегда подразумевают типовые решения. Также очень не хочется допиливать фреймворк под свой проект.

[stratosmi]

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

Своей головой лучше, поскольку у него голова светлая.

[Ба Ань Доан]

Евгений Иванов, "я сам могу писать что угодно по своим правилам"
А что есть архитектура/организация кода, как не набор правил? Документируйте свои правила, вот Вам и организация кода. Не хотите документировать - пользуйтесь фреймворками, за Вас это уже сделали.

PHP фреймворки хороши для любых задач, в которых можно использовать PHP. Даже не представляю, что это за "нетиповая задача".

[Ба Ань Доан]

Alex Wells, на слово не верю.
https://github.com/nWidart/laravel-modules

[Alex Wells]

Ба Ань Доан, во-первых, я говорил об самом фреймворке, а не каких-то сторонних пакетах. Ясен пень что переделать можно что угодно. Во-вторых, указанный пакет - хрень.

https://nwidart.com/laravel-modules/v4/advanced-to...
А давайте наплодим кучу неподдерживаемых, никому не нужных команд per module,
потом припилим механизм включения-выключения модулей (facepalm),
прийдем к системе паблиша бандлов, от которой симфония только недавно отказалась,
потом раскидаем регистрацию всего по разным файлам,
не забыв прилепить структуру "под себя" (ентити, репозитории, ассеты),
а так-же говно-плагин компоузера что бы мерджить все это дело (удивлен, что они и компоузерские команды не продублировали для каждого модуля),
что бы потом не предложить какой-либо общей структуры (серьезно, отдельная папка Modules?) и основы для проекта (и что делать с /app? Пихать "Ship" туда не выйдет, так в чем прикол? В программистах, которые прийдя в проект, начнут там срать?),
и вишенка на торте - инфа об модуле в .json файле.

Перед тем, как выбрать Apiato, я уже искал такие пакеты. И нашел их все, даже абсолютно непопулярные и неподдерживаемые. У всех есть кучу ненужного оверхеда, причем такого, который не расширяется от слова "совсем". Это же и стало одной из причин ухода от Apiato.

[Артур К.]

Евгений Иванов, на счет типовых задач все очень не однозначно.
Я знаю проект медицинской ИС, написанной на yii. Это типовой для фрейморка проект?

Да и по поводу "допиливать фреймворк", если речь идёт об изменениях в код феймворка — очень сомнительная мысль.

Answer 2

[ThunderCat]

Во первых - ООП, иначе нет смысла заморачиваться с крупным проектом, да и функциональный подход сегодня вообще в проектах больше чем "свой микроблог" никто не использует, это не рационально.
Так же откройте для себя MVC и возьмите какой-то фреймворк в котором все это уже нормально реализовано, в итоге время потраченное на прочтение документации и написание контроллеров и моделей к проекту будет в разы меньше чем вы потратите на свое кошмарное велосипедостроение. Кроме того, построенный по вашим наброскам Титаник и показать то кому-либо будет стыдно, а знания любого современного фреймворка напротив - будет большим плюсом.

Удалив модуль и БД мы повлияем на работу других модулей. Изменив структуру БД мы повлияем на работу других модулей.

SOLID, DRY, KISS...PSR4 и много других страшных аббривиатур вам помогут )

Comments

[Евгений Иванов]

Мне не стыдно показывать свои Титаники ) Про любой код можно сказать стыдно. Всегда найдется человек, который будет критиковать код.
С каждым разом мой Титаник всё меньше критикуют.

ООП - хорошо. Но вот так про функциональный подход...

Я сомневаюсь что фреймворк решит специфические задачи. Это не сайт, не блог, не соцсеть.
Это модульная система. Это не стандартный проект.
Да, частично что то и решит. Но допиливать я буду очень долго.

[Евгений Ромашкан]

Евгений Иванов, Ключевое здесь - ООП. У вас огромные проблемы в архитектуре.

[ThunderCat]

Евгений Иванов,

Это модульная система. Это не стандартный проект.

не вижу противоречия, в любом проекте есть стандартные компоненты, тот же CRUD, работа с хранилищами, авторизация. логирование, маршрутизация и много еще чего, которое вы все равно будете делать, но в любом фреймворке это уже есть, готовое, покрытое тестами и обкатанное. Если вы ССЗБ - флаг в руки, пилите свое. Однако все же советую не упираться рогом в стену и прочитать про архитектуру современных приложений на пыхе, почитать хотя бы что умеют современные фреймворки. Уверен, 80% ваших задач либо можно покрыть компонентами искаропки, либо немного их допилив, ну или готовыми модулями для фреймворка с гитхаба.

[stratosmi]

Во первых - ООП, иначе нет смысла заморачиваться с крупным проектом, да и функциональный подход сегодня вообще в проектах больше чем "свой микроблог" никто не использует, это не рационально.

Шта?

[Дмитрий Ларин]

Мне просто интересно, что это за такая модульная система, где не применим ооп, что за специфические задачи можно решать на php?

[ThunderCat]

stratosmi, у вас есть какие-то аргументы против? Я готов их послушать.

[stratosmi]

ThunderCat,

у вас есть какие-то аргументы против? Я готов их послушать.

Да это ж холиварная тема.
Я понимаю, что вы только-только открыли для себя ООП и теперь применяете где надо и где не надо.
Но концепция ООП - устарела. В современных языках ООП вообще не стали делать - Rust, Go.

[ThunderCat]

stratosmi,

Я понимаю, что вы только-только открыли для себя ООП и теперь применяете где надо и где не надо.

спасибо за комплимент, но я давно вышел из возраста когда от любой новой освоенной фичи впадаешь в щенячий восторг, да и за овер 15 лет в программировании кое-что для себя вывел, чем и делюсь тут.

В современных языках ООП вообще не стали делать - Rust, Go.

не надо путать хрен с пальцем, то что в го нет объектов в явном виде не означает что он не объектно ориентированный. Там нет наследования, но вместо него есть имплементация. А для инкапсуляции используются структуры. Если вы не в курсе - ооп не реализация, а парадигма и метод структурирования, а не классы и объекты.

Что касается конкретно вопроса - в пхп именно реализация ооп в классическом виде(как вы наверно себе это представляете - классы, объекты, наследование...) и тут без классов и нормальной структуры хрен что нормальное напишешь. Молчу о том что это вечный оверхед на загрузку функций которые в данный момент нахрен не сдались + вечное копание в лапше, которую никак нормально не организовать.

Answer 3

[Alex Wells]

На TS есть фреймворк, называется Nest. Он изначально использует модульную структуру, и там она реализована достаточно хорошо. Гляньте.

Далее как я делаю в Laravel проекте:
- /vendor - зависимости компоузера, в виде сторонних библиотек и компонентов symfony/laravel. Там есть весь базовый функционал, как, например, работа с БД. Такие зависимости в любом случае будут тесно связанны с логикой приложения, и думать об их удалении не стоит вообще. Максимум, что вы можете - построить слой абстракции над /vendor, но это ПЛОХАЯ идея.
- /app/Ship - увидел это в другом фреймворке, называется Apiato. Сам по себе он хрень, но сама идея мне понравилась. Этот "корабль" - слой твиков, временных фиксов, загрузчиков и другого, что касается каких-то базовых, недостающий частей фреймворка/библиотек, и используется всемя модулями в проекте. Например:

• загрузка модулей. Так как для laravel нету нормальной системы, пришлось написать свой костыльчик. Лежит он в ship.
  
• обработчик исключений
  
• ядра (хттп и консольное)
  
• твики для миграций
  
• общие трейты, скоупы
  
• миксины
  
• общие миддлвейры
  

В общем все то, что относится ко всему проекту в целому. Структура - хаотична.

Таким образом в третьем, финальном слое, у меня только чистая бизнес логика:
- /app/Containers - контейнеры - пафосное слово на замену модулям. Идея та же. В каждом контейнере, в корне, лежит класс с названием контейнера, в котором находятся такие штуки как: краткое название для авто-префикса ресурсов, список провайдеров и миграций (назовем их "штуками из фреймворка", к структуре не относятся).
Структура каждого контейнера:

• API/ - все, что касается хттп апи приложения
  - Controllers/ - контроллеры хттп
  - Requests/ - классы form request хттп
  - Tests/ - функциональные тесты этого апи
  - routes.php - файл раутов
  
• Broadcasting/ - все, что относится к броадкастингу через сокеты
  - Events/ - сами классы эвентов
  - channels.php - файл регистрации каналов броадкастинга
  
• Configs/ - конфиги этого конкретного контейнера (и НЕ его зависимостей)
  
• Extra/ - иногда бывает что-то, немного выходящее за рамки контейнера, но еще не входит в Ship. Идет сюда.
  
• Middlewares/ - хттп миддлвейры
  
• Database/ - все, что связано с базой данных
  - Factories/ - файлы пхп, регистрирующие фабрики моделей ларавель
  - Migrations/ - классы миграций
  - Seeders/ - сидеры базы
  - Setup/ - классы-фабрики, обложка над Factories
  
• Enums/ - энамы
  
• Exceptions/ - исключения
  
• JsonResources/ - гсон ресурсы
  
• Models/ - eloquent модели
  
• Providers/ - провадйеры
  
• Services/ - маленькие классы-сервисы, содержащие всю бизнес логику, не привязанные к ХТТП. Каждый сервис выполняет либо одну задачу, либо несколько мелких задач одного типа. Singleton
  
• Traits/ - трейты
  

Все, что я выше указал - либо часть самого языка (как трейты), либо часть фреймворка Laravel. Гуглите.

Есстественно, под разные фреймворки внутренняя структура каждого контейнера может и будет менятся.

PS: БД одна для всего проекта. Зачем вам разные БД, когда есть разные таблицы?)
PS2: то, что вы себе представили - называется микросервис. Выполняет какой-то небольшой набор задач, имеет отдельную базу и вообще изолирован от всего остального. Но раз вы задаете такие вопросы, вам они точно не нужны.

Comments

[Alex]

Тоже хотел порекомендовать apiato.io
Делали пару проектов на нем, остались довольны.

[Alex Wells]

Alex, я не могу его порекомендовать. Я с ужасом выпиливал его, постепенно превращаясь в красного монстра от злости. Ветка называлась "apiato-get-the-fuck-outta-here". Более того, даже сам Porto я не могу рекомендовать. Сейчас проект полон экшенов и тасков, и это выглядит просто ужасно. К тому же, это ОЧЕНЬ сложно структурировать, учитывая что таски не могут вызывать другие таски (точнее, не должны). У Apiato в целом есть очень много проблем, и использовать его не стоит, но как пример плохой реализации - он отлично подходит, и именно он научил меня многому)

[Евгений Иванов]

PS: БД одна для всего проекта. Зачем вам разные БД, когда есть разные таблицы?)

Логично. Это не первая моя система. Самые первые были 1 бд и с таблицами.

Дело в том, что модули предыдущих систем могут подключаться к новой системе.
Банальный конфликт таблиц. Это по простому.
По сложному - куча не состыковок и зависимостей. Единственным решением было полное разделение модуля. Один модуль - одна БД.

[Артур К.]

Евгений Иванов, ведь можно сделать префикс для таблиц модуля?

[Евгений Иванов]

Артур Э., разумеется - как и организовано в джумле и многих других системах.
Подчеркну - это небольшие системы, где бд редко превышает гигабайт.

Но разделение по базам лучше. Например не надо выбирать по префиксам таблицы модуля, для резервного копирования. Разделение один модуль - одна база просто сразу "ставит все точки над И."

Один модуль, в одной папке, с единообразной структурой, с своей базой. Разделение, стандартизация, единообразие.
Например есть модуль, каждую минуту записывающий в базу значения. База за 6 месяцев около 5 гигабайт. А если в результате непредвиденной ошибки база "сломается"? Да много что может быть.
Конечно и сервер может сломаться, но тут уже финансовый вопрос. Были бы деньги - обязательно сделал бы систему на нескольких серверах, для повышения отказоустойчивости.

Я за принцип - разделяй и властвуй.

Answer 4

[ipokos]

Как вариант использовать Symfony. Уже имеет модульную структуру (модули используют одну БД, но каждый может использовать свои таблицы и быть независимым от остальных)

Answer 5

[Игорь Воротнёв]

А я бы посоветовал начать с изучения концепта DDD - Domain Driven Design. Это позволит уложить в голове структуру по части бизнес логики и как это натянуть на код. А уже организация в конкретном фреймворке - дело второе.