Решил уйти с фриланса в офис. Сходил на пару собеседований, в минувший понедельник вышел на стажировку.
Дал мне тимлид один из проектов(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?
Также, я задумался, а стоит ли вообще продолжать работу с командой? Стоит ли мне пытаться менять процесс? Стоит ли мне пытаться переубедить тимлида или же покинуть команду?
Если нет смысла/возможности/желания менять подход у команды и компании, то лучше уйти оттуда, пока тебя не испортили.
Если же есть смысл/возможность/желание, то действительно, нужно обратиться к вышестоящему начальству с объяснением своей позиции. В худшем случае, тебя уволят. В лучшем - повысят должность/ЗП/нагрузку.
Из ваших слов получается, что если не используется инструмент, который вы считаете необходимым, то это неприемлемо? Для начала стоило бы взять объяснения от лида, почему они отказались от композера, и уже после этого можно делать выводы. Либо доводы были и они не представлены в вопросе.
Видимо во всех проектах компании все на столько не повторимо, задачи такие уникальные, что никто никогда ничего подобного не делал и подтягивать в зависимости просто нечего в 99% случаев, а ради 1% тащить такой тяжелый инструмент бессмысленно.
PS. sarcasm
Чувак:) Ты не поверишь :) Но я на такой компании проработал 3 года :)
Хоть и кохана мне по душе, но приходится писать на laravel на новом месте.
Мне твоя ситуация знакома:)
Лид твой - просто верная собака начальника :), который скорее всего исполнил команду сделать свои наработки на том фреймворке, который очень быстро может выучить даже младенец.
- Ведь там скорее всего работает молодежь 18-22 лет?
- И кадры часто меняются?
- И проекты все +- однообразные?
- А директор, наверное, заказчикам говорит что "команда профессионалов", "перспективная молодежь" и т.д. ломит цены как за работу с прогрессивными веб студиями?
- А вам платит (если платит) по 3 копейки оправдываясь что вы еще юные и учитесь?
- Написанием тестов никто не занимается, так как заказчики за это не хотят платить?
- В лучшем случае проект менеджер в ручном режиме тестирует типичные сценарии поведения пользователя на предмет "а ни отвалилось ли что то после интеграции сделанного не оплачиваемого тестового задания потенциальным сотрудником для уже работающего проекта"?
Блин! Что-то меня понесло воспоминаниями))))
Кохана и композер без напильника ну ни как и не надо! Сама структура фреймворка создана для решений которые поставляются в виде "все в коробке одной самодельной cms и оно будет работать пока в код не полезешь". А composer зависимые фреймоврки - это уже другое.
И так о сути:
Композер - еще в тренде и удобен! Но не везде его можно использовать, в частности - в старых фреймворках!
А вообще вопрос глуповат. Если там php 5.4 и Kohana старенькая, то конечно они не используют композер.
Если нет тестов — не всегда плохо, очень много проектов без тестов работают. Да там ты не научишься хорошему программированию, но не так все ужасно... можно потихоньку их притащить, но не всегда это нужно бизнесу (вообще это задачи тимлидов и гигиены разработчиков)
А вот ответ Тимлида ужасен. Почему это выяснилось не на собеседовании?
Не ужели с вашим подходом к программированию и опытом вас не взяли в компанию получше?
Если нет тестов — не всегда плохо, очень много проектов без тестов работают.
Если какой-то мелкий проектик, то еще возможно. Что-то более-менее серьезно до поры до времени. Мы тестами покрываем даже мелкие проекты и как показывает практика - это экономит уйму времени и избавляет от лишней головной боли.
Camaro67,
Тесты хороши когда за них платят, помоему соотношения кода к тестам 1:4 может даже и больше я же не думаю когда вам выделили на две фичи по 4 часа вы приходите в воскресенье и для успокоения души пишите тесты для них
Композер - это, пожалуй, лучшее что произошло с пхп 5й версии.
Валить или переубеждать тимлида - это по сути одно и тоже, если присмотреться. Просто демонстрация вашей неспособности брать на себя ответственность.
Года 3 назад на моей прошлой работе в команду пришел очень толковый проактивный человек, который никого не стал переубеждать. Он просто стал делать правильные вещи. Без объяснений. И без приглашений. Коммитеть юнит тесты. Подключать линтеры. Деклайнить неудачные пулл-реквесты. В итоге он сам стал тимлидом где-то через год.
Такие дела.
Не у всех, правда, стальные яйца. Но за проактивность никогда еще не увольняли. Если вы уже создали пулл реквест, то "переубеждение" становится задачей тимлида.
Сильный ответ! Но могу предположить, что человек мог уйти до этого с пары других мест, пока не нашел места с адекватными людьми (ну чисто гипотетически :)
Весь профит композера в скорости разработки. Подключить компонент быстрее чем реализовать самому. Если компанию устраивает их текущая скорость разработки - то можно хорошо жить и без него.
Особенно это хорошо если проекты пишутся за один раз и потом не поддерживаются. Много раз видел как composer install в новом окружении собирал не рабочий проект.
Я лично знаю не мало крупных сайтов (миллионы просмотров в день) в которых композера нет.
Композер это не стандарт разработки php. Это инструмент. Который имеет свои плюсы и минусы.
К@Maksclub, Какая бы не была задача у ТC (тест или что угодно другое) - использовать композер, означает выполнить ее быстрее(это плюс). Но и принести кусок чужого(а иногда и излишнего и даже с багами) кода в зависимостях, который останется в проекте на всю жизнь.
Ок -- мы оправдали, почему такое могло произойти. Но мы видим — проект нужно поддерживать. Взяли на него человека явно с хорошей гигиеной разработки. Как ему быть? Делать также?
Максим Федоров, На пальцах показать выигрыш времен от использования композера в разработке. Ведь в разы быстрее с композером. Бизнес это любит. Если не разрешат - тихо искать другую работу. Тут профессионального роста будет очень мало.
Андрей, если компанию устраивает текущая скорость разработки значит, что тимлид дурит бизнес. Это плохо кончится.
И дело не только в скорости разработки, но и в её стоимости. Не приходится тратить ресурсы на актуализацию версии, поддержку и устранение багов. Бизнес любит быстро, дешево, ох*енно.
А то, что composer собирает нерабочий проект, исключительно вина разработчика-профана.
Тот, кто не познал composer, не познает нирвану.
Весь профит композера в скорости разработки. Подключить компонент быстрее чем реализовать самому.
Composer - это не средство подключения чужого кода. Это средство управления зависимостями. Код может быть вашим, но разрабатываться в отдельном репозитории.
У нас с помощью Composer подключается куча своих библиотек, которые мы же и поддерживаем. Это даёт нам во-первых гибкость при управлении версиями зависимостей, во вторых - стабильность. Особенно это показательно когда в компании есть общие компоненты, которые используются на нескольких проектах.
Кроме того, Composer приносит с собой автолоадер совместимый с PSR-0 и PSR-4, а так же генератор оптимизированного автолоадера.
В общем, вы как-то однобоко на него смотрите.
Алексей Скобкин, В этом смысле однобоко. Но я видел проекты с максимум 2(двумя) зависимостями, которые пишутся той же командой или командой рядом. Редкие пулл реквесты в чужой код можно не считать.
Автолоадер - да приносит. И оптимизирует импорт. И гидратация моделек. Вообще все что хотят делать зависимости можно делать через него. Вообще отличный инструмент. Но очень часто избыточный.
Недавно в композере увеличили внутреннюю константу memory_limit с 1Gb до 1.5Gb. И встретить проект на современном фреймворке которому нужно столько памяти для композера - не сложно. Это печально же.
И встретить проект на современном фреймворке которому нужно столько памяти для композера - не сложно. Это печально же.
Может быть и печально. А представьте, сколько усилий в таком крупном проекте понадобится чтобы поддерживать это всё без Composer. Полтора гигабайта памяти - это копейки. Это пара-тройка часов работы недорогого разработчика. Да, конечно, хотелось бы чтобы съедало меньше и работало быстрее, но тогда придётся писать на другом языке.
Пока проект на старте, то никто не пишет тесты, ибо это долго, а стартовые инвестиции имеют свойство кончаться. Да и о рефакторинге особо никто не задумывается. Позже, когда проект уже выходит на самоокупаемость или даже прибыль, то встаёт вопрос стоимости внесения изменения.
Судя по тому что используется Кохана, то проект не месяц назад начался. А значит стоимость внесения изменений уже высокая и тимлид даёт вам понять что именно такая стоимость всех устраивает. А то пришёл тут выскочка, который сейчас всё в порядок приведёт и половина штата программистов окажется не нужна. Вдруг ещё его уволят :)
Если тимлид не ставил задач по подключению композера и настройки тестов, то получается, что вместо реальных задач вы занимались самодеятельностью и потратили на это ресурсы компании (свое рабочее время).
Junior-вакансия это прощает, но если хотите работать в команде, нужно понимать, что в работе важен результат, а не самолюбование.
Кроме того, исходя из того, что проект старый, высок риск того, что вы подключив композер что-то сломали. Например, кто-то когда-то "пофиксил" код в копипастенной библиотеке (как бы это дико не звучало), а вы выкачали ее исходную версию из репозитория и т.д. - моментов, на самом деле много.
Может это разовая задача по внешнему проекту на 3 рубля и какой смысл в ней городить огород, если ее нужно сделать за пару часов, отдать клиенту и забыть.
Конечно, тимлид хоть и динозавр, но будет обоснованно не доволен. Странно, что он не контролировал ход работы - такую самодеятельность в процессе работы нужно пресекать на корню.
Композер, конечно желательно использовать. Тесты (и непрерывная интеграция, и код-ревью и т.д...) - замечательно, но многие в реальном мире, в котором приходится поддерживать проекты с историей (в которой композера не было и в помине), замечательно живут и без них.
Рефакторинг проекта и модернизация процесса разработки - замечательные, но отдельные задачи, которые требуют предварительного обсуждения и согласования.
Сделай поставленную задачу, предложи вариант развития (композер и тесты), обсудите с командой и тимлидом, запланируйте внедрение - все будут довольны.
Звучит очень правильно, но лично мой опыт в нескольких компаниях похожего состояния кода, как у Максима, показывает, что на предложения об улучшении кода, внедрении новых фич в лучшем случае скажут - хорошо, как будет время надо будет сделать. А времени не будет никогда, потому, что поддержка легаси хавает 24/7 и еще чуть чуть.
Валить или нет - зависит от целей. Надо думать самому.
Если команда не хочет развиваться, то и разработчик не будет развиваться.
Категоричное желание оставаться в прошлом веке - право команды, если у нее нет понимания вектора развития технологий, то это ее проблемы.
А "как будет время" - время всегда можно найти - после работы или вместо хабрахабра/контакта.
Нормальная команда оценит и, уверен, что поощрит.
Если нет, то и тянуть такую команду нет смысла.
Либо пойти к начальству выше, рассказать что они все некомпетентны, уволить их, стать самому лидом и набрать нормальную команду. Но тут можно услышать штуки про "бизнес", "всё работает, не трогай" итд.
Antonio Solo, не надо никакой аргументации. Неиспользование composer в наше время - это, очень мягко говоря, глупость. Давайте в других языках npm, gradle/maven, cargo не будем использовать..
Mikhail Osher, организуй контору, наладь бизнес-процесс, заполучи постоянных клиентов , серьезные проекты на поддержку. а потом я посмотрю на скорость вылета из твоей организации подобных "рационализаторов".
работника нанимают на то что бы он выполнял конкретные задачи, которые ему поручили выполнять. если он не может это делать (вне зависимости от причин) - это плохой работник. а тс- фрилансер, то есть по определению "плохой работник" я бы такого даже на собеседование не позвал бы. его уволят, скорее всего.
p.s. "плохой работник" не значит "плохой специалист".
"Ух, эти ваши композеры доморощеные. Напридумывали."
Беги оттуда как Форест Гамп. Беги пока этот тимлид со своим легаси тебя не доканал.
От "жизни" не думаю, что ты отстал. Альтернативы пока нет. Могу ошибаться, но скорее всего поменять процесс, вправить мозг не получится, они там сидят в своём мирке и сами ничего не хотят. Надеюсь хоть git используют.
Я бы не хотел работать в компании где composer бесполезен. У них это так, он бесполезен. Но мне страшно представлять что там за проект, мне точно не было бы интересно работать в проекте, который не использует самые лучшие мировые библиотеки и стандарты. Я не люблю эти все самописы потому что они почти всегда ужасного качества, ведь устоявшиеся проверенные временем библиотеки делают лучшие программисты и тратят на них огромное количество времени совершенствуя их, не представляю себе бизнес кроме mail.ru или яндекса который может себе позволить потратить столько же много времени на собственную библиотеку. Конечно этот тимлид приведёт 100 аргументов почему это круто делать свой самопис, но мне без разницы, я просто не хочу ковыряться в бесконечных самописах, я хочу прийти на следующую работу и сказать что у меня есть опыт работы с этим и этим, а они скажут, о это хорошо, мы это тоже используем.
Такое случается бывает если закрыться от внешнего мира и надолго засесть в тёплом, уютном месте. Технологии как раз обычно толкает тимлид который сам желает двигаться вперёд и тянет за собой команду вынуждая менять версии на новые, применять всё более новые фреймворки и всё самое продвинутое.
Вам вероятно всё же придётся найти себе более продвинутую команду. Обязательно используйте composer и тесты, вы делаете всё правильно.
Если они до сих пор на 5.4, то сдается мне, что как библиотеки, так и окружение там просто не меняют "пока работает". Скорость обновления библиотек не важна, пока ты их не обновляешь. Походу, тут это делается редко и да, копипостом. Не знаю, какие там задачи, вот хрен его знает, может и не нужен.
Сабмодули гит? Тоже вариант, так-то ))
вопрос работать там или нет зависит от денег которые там платят. если ты можешь выполнять работу и получать за нее хорошую оплату - почему бы не делать ее? То что ты несогласен с требованиями - всегда будет что-то что тебя раздражает.