Процедурный PHP не умер
Мне пришлось немного поработать с WordPress, и я уже успел забыть все его «прелести». А главное — давно не сталкивался с процедурным подходом в рамках целого проекта.
Одно дело — небольшой мусорный скрипт, который запускается пару раз, решает конкретную задачу и отправляется в мусорку.
И совсем другое — когда так устроен целый проект.
После чистого PHP и фреймворков вроде Symfony или Laravel внутри начинается настоящая война.
Где объекты?
Где зафиксированные контракты?
Где нормальные объекты данных?
Где разделение ответственности?
Всё это где-то там, в далёком будущем. Возможно. А возможно, и нет. 🙂
И как человеку, которому интересна архитектура ПО, мне это доставляет немало неудобств.
А потом я вспомнил Go.
Язык, про который часто говорят, что там «нет нормального ООП» и невозможно построить красивую архитектуру.
Но даже там у меня получается гораздо более выразительный код и понятная структура проекта, чем в WordPress.
И тут возникает интересный вопрос: а почему WordPress вообще до сих пор такой?
Похоже, в какой-то момент ради обратной совместимости с огромным количеством плагинов и тем в жертву было принесено практически всё остальное.
Система расширения, которая когда-то была преимуществом, со временем сама стала архитектурным ограничением.
При этом полностью переписать проект и начать новую жизнь — вполне возможно. Например, OpenCart когда-то прошёл путь от 1.5.x к 2.x, фактически получив новую архитектуру.
А WordPress выбрал другой путь: сохранять совместимость и развиваться поверх существующего фундамента.
И, возможно, именно поэтому процедурный PHP в 2026 году всё ещё живёт. 🙂
Мне пришлось немного поработать с WordPress, и я уже успел забыть все его «прелести». А главное — давно не сталкивался с процедурным подходом в рамках целого проекта.
Одно дело — небольшой мусорный скрипт, который запускается пару раз, решает конкретную задачу и отправляется в мусорку.
И совсем другое — когда так устроен целый проект.
После чистого PHP и фреймворков вроде Symfony или Laravel внутри начинается настоящая война.
Где объекты?
Где зафиксированные контракты?
Где нормальные объекты данных?
Где разделение ответственности?
Всё это где-то там, в далёком будущем. Возможно. А возможно, и нет. 🙂
И как человеку, которому интересна архитектура ПО, мне это доставляет немало неудобств.
А потом я вспомнил Go.
Язык, про который часто говорят, что там «нет нормального ООП» и невозможно построить красивую архитектуру.
Но даже там у меня получается гораздо более выразительный код и понятная структура проекта, чем в WordPress.
И тут возникает интересный вопрос: а почему WordPress вообще до сих пор такой?
Похоже, в какой-то момент ради обратной совместимости с огромным количеством плагинов и тем в жертву было принесено практически всё остальное.
Система расширения, которая когда-то была преимуществом, со временем сама стала архитектурным ограничением.
При этом полностью переписать проект и начать новую жизнь — вполне возможно. Например, OpenCart когда-то прошёл путь от 1.5.x к 2.x, фактически получив новую архитектуру.
А WordPress выбрал другой путь: сохранять совместимость и развиваться поверх существующего фундамента.
И, возможно, именно поэтому процедурный PHP в 2026 году всё ещё живёт. 🙂
Views: 12