Разве Composer бесполезен в 2017?

Question

[Максим Кудрявцев]

Доброго времени суток.

Решил уйти с фриланса в офис. Сходил на пару собеседований, в минувший понедельник вышел на стажировку.
Дал мне тимлид один из проектов(php 5.4 + kohana 3.2), поставил несколько задач и начал я работать. Про проект сказать ничего не могу, код как код, в каких-то местах лучше, в каких-то хуже. Никаких тестов нет, совсем и никаких, и, со слов тимлида, никто их тут до меня не даже не предлагал.

Для того чтобы не утонуть в большом объеме чужого кода, чтобы ничего там случайно не сломать, инициализировал в директории с проектом composer.json, затянул phpunit + selenium и начал разбираться с проектом. По ходу работы заметил несколько сторонних библиотек, включенных в код copy-past, которые поставил зависимостями от composer.
Трое суток ходил с отладчиком исследуя и исправляя баги, писал тесты, чтобы ничего не сломать. Сегодня, четвертый день моей стажировки, отчитываюсь перед тимлидом о проделанной работе, говорю мол вот добавил composer в проект, вынес на него вот эти захардкоренные библиотеки из кода, написал такие-то тесты, которые позволили закрыть вот эту вот задачу.

После всего этого слышу от тимлида: "А зачем ты использовал composer? Мы не используем его и вообще для 99% наших задач он бесполезен". Composer в 2017 году, который используется в любом современном PHP фреймворке(Laravel & Symphony как минимум) для 99% задач нашей компании бесполезен... Бум!!! У меня в голове это как-то даже не укладывается. Как может быть один из самых популярных инструментов в PHP среде бесполезен для 99% задач компании, которая использует стек технологий, основанный на PHP?

Господа, я отстал от жизни и чего-то не знаю? Может быть кто-то знает лучшую альтернативу чем composer для PHP?
Также, я задумался, а стоит ли вообще продолжать работу с командой? Стоит ли мне пытаться менять процесс? Стоит ли мне пытаться переубедить тимлида или же покинуть команду?

Comments

[zorca]

Это просто ядерный звиздец! Пускай гавнокодят дальше, но без вас.
Как вариант, пойти к руководству и стать новым тимлидом.

[Lander]

Что за херня в последнее время с Тимлидами творится? Как их вообще назначают на эту должность с таким подходом то?

[Maxim Nepritimov]

Если нет смысла/возможности/желания менять подход у команды и компании, то лучше уйти оттуда, пока тебя не испортили.
Если же есть смысл/возможность/желание, то действительно, нужно обратиться к вышестоящему начальству с объяснением своей позиции. В худшем случае, тебя уволят. В лучшем - повысят должность/ЗП/нагрузку.

[Igor Makarov]

Из ваших слов получается, что если не используется инструмент, который вы считаете необходимым, то это неприемлемо? Для начала стоило бы взять объяснения от лида, почему они отказались от композера, и уже после этого можно делать выводы. Либо доводы были и они не представлены в вопросе.

[anton_lazarev]

Беги

[Макс Жук]

Видимо во всех проектах компании все на столько не повторимо, задачи такие уникальные, что никто никогда ничего подобного не делал и подтягивать в зависимости просто нечего в 99% случаев, а ради 1% тащить такой тяжелый инструмент бессмысленно.
PS. sarcasm

[LINKeR UA]

Чувак:) Ты не поверишь :) Но я на такой компании проработал 3 года :)
Хоть и кохана мне по душе, но приходится писать на laravel на новом месте.
Мне твоя ситуация знакома:)

Лид твой - просто верная собака начальника :), который скорее всего исполнил команду сделать свои наработки на том фреймворке, который очень быстро может выучить даже младенец.
- Ведь там скорее всего работает молодежь 18-22 лет?
- И кадры часто меняются?
- И проекты все +- однообразные?
- А директор, наверное, заказчикам говорит что "команда профессионалов", "перспективная молодежь" и т.д. ломит цены как за работу с прогрессивными веб студиями?
- А вам платит (если платит) по 3 копейки оправдываясь что вы еще юные и учитесь?
- Написанием тестов никто не занимается, так как заказчики за это не хотят платить?
- В лучшем случае проект менеджер в ручном режиме тестирует типичные сценарии поведения пользователя на предмет "а ни отвалилось ли что то после интеграции сделанного не оплачиваемого тестового задания потенциальным сотрудником для уже работающего проекта"?

Блин! Что-то меня понесло воспоминаниями))))

Кохана и композер без напильника ну ни как и не надо! Сама структура фреймворка создана для решений которые поставляются в виде "все в коробке одной самодельной cms и оно будет работать пока в код не полезешь". А composer зависимые фреймоврки - это уже другое.

И так о сути:
Композер - еще в тренде и удобен! Но не везде его можно использовать, в частности - в старых фреймворках!

Answer 1

[Максим Федоров]

Вали от туда

А вообще вопрос глуповат. Если там php 5.4 и Kohana старенькая, то конечно они не используют композер.
Если нет тестов — не всегда плохо, очень много проектов без тестов работают. Да там ты не научишься хорошему программированию, но не так все ужасно... можно потихоньку их притащить, но не всегда это нужно бизнесу (вообще это задачи тимлидов и гигиены разработчиков)

А вот ответ Тимлида ужасен. Почему это выяснилось не на собеседовании?

Не ужели с вашим подходом к программированию и опытом вас не взяли в компанию получше?

UPD: Очень хороший ответ ниже по ссылке -- Разве Composer бесполезен в 2017?

Comments

[Camaro67]

Если нет тестов — не всегда плохо, очень много проектов без тестов работают.

Если какой-то мелкий проектик, то еще возможно. Что-то более-менее серьезно до поры до времени. Мы тестами покрываем даже мелкие проекты и как показывает практика - это экономит уйму времени и избавляет от лишней головной боли.

[zorca]

Бегом оттуда!

[Denis]

Camaro67,
Тесты хороши когда за них платят, помоему соотношения кода к тестам 1:4 может даже и больше я же не думаю когда вам выделили на две фичи по 4 часа вы приходите в воскресенье и для успокоения души пишите тесты для них

Answer 2

[Demian Smith]

Композер - это, пожалуй, лучшее что произошло с пхп 5й версии.
Валить или переубеждать тимлида - это по сути одно и тоже, если присмотреться. Просто демонстрация вашей неспособности брать на себя ответственность.

Года 3 назад на моей прошлой работе в команду пришел очень толковый проактивный человек, который никого не стал переубеждать. Он просто стал делать правильные вещи. Без объяснений. И без приглашений. Коммитеть юнит тесты. Подключать линтеры. Деклайнить неудачные пулл-реквесты. В итоге он сам стал тимлидом где-то через год.

Такие дела.

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

Comments

[Максим Федоров]

Сильный ответ! Но могу предположить, что человек мог уйти до этого с пары других мест, пока не нашел места с адекватными людьми (ну чисто гипотетически :)

[Demian Smith]

Максим Федоров, на самом деле, всё наоборот. Он до этого работал в очень сильных командах и не представлял себе как можно жить по-другому.

[Максим Федоров]

Demian Smith, ну да, как-то не предположил это даже :)
но тут опять есть сценарий, отличный от ТС :)

Answer 3

[Олег Кольжанов]

Если тимлид не ставил задач по подключению композера и настройки тестов, то получается, что вместо реальных задач вы занимались самодеятельностью и потратили на это ресурсы компании (свое рабочее время).
Junior-вакансия это прощает, но если хотите работать в команде, нужно понимать, что в работе важен результат, а не самолюбование.
Кроме того, исходя из того, что проект старый, высок риск того, что вы подключив композер что-то сломали. Например, кто-то когда-то "пофиксил" код в копипастенной библиотеке (как бы это дико не звучало), а вы выкачали ее исходную версию из репозитория и т.д. - моментов, на самом деле много.
Может это разовая задача по внешнему проекту на 3 рубля и какой смысл в ней городить огород, если ее нужно сделать за пару часов, отдать клиенту и забыть.
Конечно, тимлид хоть и динозавр, но будет обоснованно не доволен. Странно, что он не контролировал ход работы - такую самодеятельность в процессе работы нужно пресекать на корню.

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

Рефакторинг проекта и модернизация процесса разработки - замечательные, но отдельные задачи, которые требуют предварительного обсуждения и согласования.
Сделай поставленную задачу, предложи вариант развития (композер и тесты), обсудите с командой и тимлидом, запланируйте внедрение - все будут довольны.

Comments

[Макс Жук]

Звучит очень правильно, но лично мой опыт в нескольких компаниях похожего состояния кода, как у Максима, показывает, что на предложения об улучшении кода, внедрении новых фич в лучшем случае скажут - хорошо, как будет время надо будет сделать. А времени не будет никогда, потому, что поддержка легаси хавает 24/7 и еще чуть чуть.

[Олег Кольжанов]

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

Answer 4

[Andrey Shatokhin]

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

Особенно это хорошо если проекты пишутся за один раз и потом не поддерживаются. Много раз видел как composer install в новом окружении собирал не рабочий проект.

Я лично знаю не мало крупных сайтов (миллионы просмотров в день) в которых композера нет.

Композер это не стандарт разработки php. Это инструмент. Который имеет свои плюсы и минусы.

Comments

[Максим Федоров]

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

[Andrey Shatokhin]

К@Maksclub, Какая бы не была задача у ТC (тест или что угодно другое) - использовать композер, означает выполнить ее быстрее(это плюс). Но и принести кусок чужого(а иногда и излишнего и даже с багами) кода в зависимостях, который останется в проекте на всю жизнь.

[Максим Федоров]

А вообще вопрос такого плана.

Ок -- мы оправдали, почему такое могло произойти. Но мы видим — проект нужно поддерживать. Взяли на него человека явно с хорошей гигиеной разработки. Как ему быть? Делать также?

[Andrey Shatokhin]

Максим Федоров, На пальцах показать выигрыш времен от использования композера в разработке. Ведь в разы быстрее с композером. Бизнес это любит. Если не разрешат - тихо искать другую работу. Тут профессионального роста будет очень мало.

[Александр]

Андрей, если компанию устраивает текущая скорость разработки значит, что тимлид дурит бизнес. Это плохо кончится.
И дело не только в скорости разработки, но и в её стоимости. Не приходится тратить ресурсы на актуализацию версии, поддержку и устранение багов. Бизнес любит быстро, дешево, ох*енно.
А то, что composer собирает нерабочий проект, исключительно вина разработчика-профана.
Тот, кто не познал composer, не познает нирвану.

[Andrey Shatokhin]

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

Но одно точно - тимлид не идущий на аргументированный диалог - мудак.

[Максим Федоров]

Андрей, опять идет умиление джунов.
Сейчас джуниором устроиться, нужно быть мидлом по вашим меркам :)

[Andrey Shatokhin]

Максим Федоров, Если копирует код из документации мидл. То что делает джун, когда ему хочется добавить новый модуль?

[Максим Федоров]

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

[Алексей Скобкин]

Весь профит композера в скорости разработки. Подключить компонент быстрее чем реализовать самому.

Composer - это не средство подключения чужого кода. Это средство управления зависимостями. Код может быть вашим, но разрабатываться в отдельном репозитории.
У нас с помощью Composer подключается куча своих библиотек, которые мы же и поддерживаем. Это даёт нам во-первых гибкость при управлении версиями зависимостей, во вторых - стабильность. Особенно это показательно когда в компании есть общие компоненты, которые используются на нескольких проектах.
Кроме того, Composer приносит с собой автолоадер совместимый с PSR-0 и PSR-4, а так же генератор оптимизированного автолоадера.
В общем, вы как-то однобоко на него смотрите.

[Andrey Shatokhin]

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

Автолоадер - да приносит. И оптимизирует импорт. И гидратация моделек. Вообще все что хотят делать зависимости можно делать через него. Вообще отличный инструмент. Но очень часто избыточный.

Недавно в композере увеличили внутреннюю константу memory_limit с 1Gb до 1.5Gb. И встретить проект на современном фреймворке которому нужно столько памяти для композера - не сложно. Это печально же.

[Максим Федоров]

Алексей Скобкин, да че уж там, я будучи джуниором уже своих модулей сделал, которые использую повторно

[DevMan]

Андрей,

Весь профит композера в скорости разработки. Подключить компонент быстрее чем реализовать самому.

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

ну и Алексей Скобкин правильно написал про управление зависимостями.

[Алексей Скобкин]

Андрей,

И встретить проект на современном фреймворке которому нужно столько памяти для композера - не сложно. Это печально же.

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

Answer 5

[Lander]

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

Answer 6

[Илья Белобородов]

Ничему не научишься и никого не переубедишь.

Comments

[Dmitry D]

лучше и не объяснить

Answer 7

[Yustas Alexu]

Тут мне видится проблема в самом тимлиде. Ему просто не понравилось, что какой-то стажер начал тыкать его мордой в его же дерьмо.

Answer 8

[Пума Тайланд]

очевидно что тимлид застрял в прошлом не более того

Answer 9

[Mikhail Osher]

же покинуть команду

Я бы выбрал этот вариант.

Либо пойти к начальству выше, рассказать что они все некомпетентны, уволить их, стать самому лидом и набрать нормальную команду. Но тут можно услышать штуки про "бизнес", "всё работает, не трогай" итд.

Comments

[Antonio Solo]

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

[Mikhail Osher]

Antonio Solo, не надо никакой аргументации. Неиспользование composer в наше время - это, очень мягко говоря, глупость. Давайте в других языках npm, gradle/maven, cargo не будем использовать..

[Antonio Solo]

Mikhail Osher, организуй контору, наладь бизнес-процесс, заполучи постоянных клиентов , серьезные проекты на поддержку. а потом я посмотрю на скорость вылета из твоей организации подобных "рационализаторов".

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

p.s. "плохой работник" не значит "плохой специалист".

Answer 10

[Light Air]

"Ух, эти ваши композеры доморощеные. Напридумывали."

Беги оттуда как Форест Гамп. Беги пока этот тимлид со своим легаси тебя не доканал.
От "жизни" не думаю, что ты отстал. Альтернативы пока нет. Могу ошибаться, но скорее всего поменять процесс, вправить мозг не получится, они там сидят в своём мирке и сами ничего не хотят. Надеюсь хоть git используют.

Answer 11

[Untitled Cropped]

Я бы не хотел работать в компании где composer бесполезен. У них это так, он бесполезен. Но мне страшно представлять что там за проект, мне точно не было бы интересно работать в проекте, который не использует самые лучшие мировые библиотеки и стандарты. Я не люблю эти все самописы потому что они почти всегда ужасного качества, ведь устоявшиеся проверенные временем библиотеки делают лучшие программисты и тратят на них огромное количество времени совершенствуя их, не представляю себе бизнес кроме mail.ru или яндекса который может себе позволить потратить столько же много времени на собственную библиотеку. Конечно этот тимлид приведёт 100 аргументов почему это круто делать свой самопис, но мне без разницы, я просто не хочу ковыряться в бесконечных самописах, я хочу прийти на следующую работу и сказать что у меня есть опыт работы с этим и этим, а они скажут, о это хорошо, мы это тоже используем.

Answer 12

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

Такое случается бывает если закрыться от внешнего мира и надолго засесть в тёплом, уютном месте. Технологии как раз обычно толкает тимлид который сам желает двигаться вперёд и тянет за собой команду вынуждая менять версии на новые, применять всё более новые фреймворки и всё самое продвинутое.
Вам вероятно всё же придётся найти себе более продвинутую команду. Обязательно используйте composer и тесты, вы делаете всё правильно.

Answer 13

[MisterN]

Если они до сих пор на 5.4, то сдается мне, что как библиотеки, так и окружение там просто не меняют "пока работает". Скорость обновления библиотек не важна, пока ты их не обновляешь. Походу, тут это делается редко и да, копипостом. Не знаю, какие там задачи, вот хрен его знает, может и не нужен.
Сабмодули гит? Тоже вариант, так-то ))

Answer 14

[Тимур Маликин]

Валить, однозначно.

Answer 15

[Antonio Solo]

вопрос работать там или нет зависит от денег которые там платят. если ты можешь выполнять работу и получать за нее хорошую оплату - почему бы не делать ее? То что ты несогласен с требованиями - всегда будет что-то что тебя раздражает.

Answer 16

[Иван Веков]

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

1. Композер реально бесполезен в некоторых проектах. Нужно смотреть от конкретной ситуации и целей. Приведу несколько примеров для понимания:

• Проект полон легаси-кода. Ну как в вашем случае. 5.4, серьёзно? Вероятно этот проект просто на "дожитии", его надо поддерживать в состоянии "работает и ладно", а параллельно вероятно планируется его полный ремейк на нормальных технологиях.
  
• CMS-ки. Ну тот же Битрикс. Сейчас еще суют туда композер, когда не знают толком нативные для Битрикса либы и его возможности из коробки. Но в 2017-м прямо 100% не стоит лезть в него с композером.
  
• Проект банально очень простой. Ну нет необходимости подключать либы. Делаем допустим обычный CRUD сервис. На кой хрен в него дирижерами тыкать?
  
• Делаем микросервисы. Близко к прошлому пункту. Большинство микросервисов реализуют всего лишь пару простейших операций, и их цель - весить мало, работать быстро. Грузить их каким-то мусором, пусть даже легковесным - совсем не нужно.
  
• Упоротость безопасности. Бывают компании, которые блокируют всё - ресурсы, либы, технологии. Вот допустим мы в такой компании, которая запретила 90% рнр-шных либ. На кой вам композер?
  

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

Ваш вопрос мне напомнил собеседование в 2020-м кажется году.
Я тогда собеседовался на позицию CTO к одному небольшому производителю мебели. У них была сайт-витрина (ну знаете, таких тысячи - товары есть, а купить там их нельзя. По сути визитка для каждого товара, с минимумом опций). И они начали его делать на микросервисах. Ну прямо подняли кубернетес и начали его делать.
Это первое что меня напрягло, так как очевидно, что для подобного сайта микросервисы - не нужны абсолютно. Ставишь вордпресс/битрих/тильду - и потребности бизнеса решены за бесплатно и 0 времени.
Второе что меня окончательно отпугнуло от той технической команды - они делали микросервисы на Ubuntu + Laravel. Это прямо ад. Какой Alpine, какой Slim/Lumen, зачем это всё :) И опять же, обосновали это тем, что:
Убунту - самая популярная линуксовая система
Ларавель - самый популярный фреймворк
Микросервисы - самый прорывной паттерн

И вроде бы всё верно. Но:
1. Мозайка не складывается
2. Им это всё нахрен не нужно. Ни убунту, ни ларавель, ни микросервисы, ни куча разрабов. Потому что задача такая - сделать "сайт-визитку".

При этом микросервисы я обожаю, композер юзаю, тесты пишем :)
Но в нужном месте, в нужное время.