Когда на кухне требуется кетчуп, большинство людей покупает его, а не отправляется пахать землю, строить теплицы, сажать помидоры и специи, чтобы приготовить его самостоятельно. Немалая доля купивших не стесняется при этом, причмокнув, сообщить, что кетчуп уже не тот. Надо было брать "Империю вкуса", а не "Королевство запаха". На худой конец, "Царство консистенции".
Причина, по которой кулинар не занимается земледелием, очевидна: в нашем мире существует разделение труда, благодаря которому повышается общая производительность. Время кулинара расходуется на приготовление блюд.
В то же время, корпорация "Жирдоналдс", владеющая сетью ресторанов быстрого питания, использующая кетчуп как один из ингредиентов своих блюд, может позволить себе владение собственными плантациями помидоров (или, в интересах бухгалтерского баланса, оставить предпринимательский риск на фермере, номинальном владельце, но фактически управлять его бизнесом под соусом слежения за корпоративными стандартами качества). Для корпорации время не имеет значения, пока налажены бизнес-процессы.
Наличие "супермаркета" компонентов является признаком зрелости экосистемы разработки на данном языке программирования.
В PHP такой супермаркет появился в 2012-м году. Трудно себе представить, что до PHP 5.3 не было поддержки namespaces, позволяющих разделить код на твой собственный и код того парня. Трудно не потому, что я этого не помню, а потому что это вот натурально физически больно: вспоминать, как поддержка зависимостей делалась вручную через подключение файлов, каждый из которых тоже лежал как попало: PSR-0, описывающий стандарт на размещение файлов в папках, появился в 2010-м (а современный PSR-4 - аж в 2013-м).
Сейчас, когда требуется добавить на своем PHP-участке забор, программист пишет в консоли "composer require penitentiary/fence" и вуаля - в коде появляется забор. Немного смущает колючая проволока и вышки, но выбор поставщика уже произведен, переделывать на другого лень, и так работает.
Все это, разумеется, невероятно ускоряет разработку, позволяя стоять на плечах индийских гигантов. Зачем для каждого проекта писать свою систему управления логами, если есть прекрасные готовые компоненты, тот же Monolog? Нет необходимости даже один раз в жизни писать собственную систему, чтобы потом таскать её по разным проектам. А если есть - можно оформить её отдельным пакетом composer и подключать как стороннюю библиотеку.
После появления такого супермаркета кое-кто заголосил: "да, да, это принцип DRY (don't repeat yourself), мы всегда его использовали", стыдливо прикрывая свои старые методы подключения зависимостей.
Итак, плюсы подключения зависимостей через пакетный менеджер:
- вы красавчик, вы в тренде
- не надо писать что-то самому
- вся цепочка зависимостей подтягивается автоматически
- не захламляется собственный код - зависимости лежат отдельно
- иногда нужно быстро сделать прототип, хотя бы и работающий через пень колоду, чтобы получить аванс в сто тысяч пятьсот мешков золота на его внедрение и доработку
К сожалению, у этого подхода есть и несколько минусов.
Во-первых, подключение зависимости многие воспринимают как код, данный свыше, который нельзя критиковать, потому что умные люди писали. Скажем мягко: код писали такие же люди, как и те, которые его используют. Однажды, взяв некий код себе в проект, я обнаружил, что его работу можно ускорить ровно в 1000 (тысячу!) раз, изменив две-три строчки в узком месте. В новых версиях разработчик устранил эту проблему (возможно, добавив новые - я не проверял).
Во-вторых, всегда нужно убедиться, что подключается только то, что нужно. Что к пакету не подцепилась еще пара-тройка (десятков) зависимостей, нужных для специфических случаев, не использующихся в твоем проекте. Благодаря механике автозагрузки, часто такой лишний код просто занимает место, но повторюсь - код писали люди.
В-третьих, иногда действительно требуется написать код самостоятельно, потому что хочется получить контроль над происходящим вокруг. Из компонентов тюремных построек можно, конечно, попытаться построить уютный дачный домик, но иногда лучше отринуть эти попытки и сделать именно то, что требуется, с нуля.
Наконец, стоит помнить о том, что, чем более популярен некий компонент, тем больше шансов, что он пытается быть универсальным, в угоду массовости. Лучше взять три компонента, каждый из которых идеален, а четвертый (идеальный, в меру способностей) написать самому, чем затащить в проект целый город ради одного двора.
Использовать чужие компоненты можно!
Если они:
- качественно написаны
- делают то, что нужно
- не делают того, что не нужно
В остальном же это выбор между одеждой, пошитой по индивидуальному заказу, и одеждой из магазина.
В супермаркете зависимостей чаще всего вы пытаетесь купить собственное время. Но выбирать надо придирчиво, чтобы не окружить дачный домик тюремным забором с вышками.