# Composer и PSR

Когда-то, на PHP писали только в процедурном стиле. Хотя сам язык появился чуть позже чем Java, у которой вся архитектура построена на ООП, в PHP это было избыточно. На то время браузеры не могли похвастаться большой функциональностью, а значит и писать сложные сайты, тем более web приложения никто даже не думал. Шли годы, производительность компьютеров росла, появлялась потребность в более прогрессивных сайтах. И как язык, который создан исключительно для сайтов, PHP приходилось развиваться и стараться идти в ногу со временем.
PHP (Personal Home Page) - интерпретируемый скриптовый язык программирования общего назначения, который создавался для разработки динамических веб-сайтов 
ООП в PHP был добавлен по сути только в 5-й версии (2004 год), да и то в слишком простой форме. Более-менее говорить об ООП в PHP можно лишь с версии 5.3 (2009 год).  
Главное правило разработчиков гласит: Не изобретай велосипед! Не пиши то, что уже давно написано, протестировано и поддерживается большой командой. И хоть на тот момент (2004-2009) уже были первые версии контроля версий Git и SVN, ими мало кто пользовался. "Да кому он вообще нужен?" - подумали люди, и продолжили называть переменные типа $peremennaya;
Все изменилось с появлением composer в мире веб-разработчиков.
Composer - менеджер зависимостей для языка программирования PHP
Эта простая, но очень мощная приблуда решала сразу несколько задач:
Первое, люди могли к себе подтянуть версию зависимости всего одной командой, а composer.json говорил другим разработчикам, какие библиотеки использует данный проект, тем самым давать им возможность развернуть все зависимости одной командой.
Второе, объем проекта стал гораздо меньше, так как больше не было необходимости хранить у себя все библиотеки - их в любой момент можно было подтянуть.
Третье, программисты больше не переживали о том, что у зависимости с которой они писали свое приложение, выйдет новая версия, которая все сломает, а старую версию никогда больше не найдешь. Ведь composer запоминал версию, и обновлял ее только, если разработчик сам запустит обновление.
Казалось бы, composer решил множество глобальных проблем проектов на PHP, но и это еще не все. 
Помнишь, я говорил что на PHP раньше писали только в процедурном стиле? Этот архаизм никуда не делся. Конечно, люди могли писать свой код в нескольких файлах, разбивать логику, но подключение совершалось с помощью команд include и require. Но каждый раз, каждый файл необходимо было подключать вручную. А я напомню, что раньше, шаблоном проектирования Единая точка входа , мало кто пользовался. Точнее пользовались не только лишь все, не каждый хотел это делать. Представь, сколько нужно было держать в голове при разработке, чтобы не сломать проект. А после появления ООП еще нужно было что-то делать с именами классов, ведь название класса должно быть уникальным. 
Composer принес с собой не только контроль зависимостей, но и namespace с автоматической загрузкой классов со стандартом PSR-0, а после PSR-4
Конечно, у PHP на тот момент была своя загрузка классов, но composer сделал ее унифицированной
PSR-4 дает гораздо более простую структуру каталогов, поскольку вы можете не создавать вложенные каталоги, но при этом использовать полные пространства имен.  
PSR (PHP Standards Recommendations) - стандарты, которые рекомендуется применять. Описывают общие концепции, которые уже были проверены и отработаны.
Подробнее изучить стандарты вы можете здесь