Совершенно все, начиная отсутствием объектного интерфейса (я вынужден помнить список разрозненных функций вместо использования публичных методов объектов), заканчивая одинаковым порядком аргументов (точнее его отсутствием) в функциях.
Curl же совершенно особая песня, его можно отнести к особым, наиболее неудобным сторонам php.
В качестве контрпримера приведу библиотеки, которые на мой взгляд привносят хорошие, удобные абстракции:
https://github.com/guzzle/guzzle
https://github.com/moment/moment
https://github.com/KnpLabs/Gaufrette
> В этом случае вы добавляете уровень абстракции поверх другого уровня абстракции, который изначально создавался как базовая точка отсчёта.
Это необходимо, особенно если учитывать, насколько неприятен чистый php. Решения таких задач как чтение-запись файла\загрузка данных по http\прослушивание сокета выглядят крайне неопрятно без использования сторонних библиотек, так как php в большинстве случаев не предоставляет удобных абстракций, а просто занимается копированием C функций.
Вполне понял, дело в том, что даже при командной работе совсем непросто выяснить ответы следующие вопросы:
— что мы делаем?
— для чего мы это делаем?
— а нужно ли это делать вообще?
— как это можно сделать иначе\лучше\быстрее?
Чаще всего ответов не знает даже сам постановщик задачи, но их можно найти, разговаривая с командой. Я веду к тому, что fullstack разработчик может экономить время или на максимально понятных\четких задачах (при грамотном постановщике) и на research задачах. Какие-то стратегически значимые решения доверять одному (пусть и достаточно опытному разработчику) я бы наверное не стал.
Вопросы задают все, но правильные вопросы обычно появляются во время командного обсуждения или прямо во время выполнения задачи.
Получается два варианта:
1) фуллстек действует строго по тз, результат — «я его слепила из того что было»
2) фуллстек задает много уточняющх\корректирующих тз вопросов постановщику задачи, результат — отсутствие экономии времени
Как альтернатива этому — коллективное обсуждение, в процессе которого каждый разработчик сможет более глубоко взглянуть на свою часть задачи и задать более правильные вопросы еще до начала её выполнения.
Или вовсе сделает совсем не то, экономия на коммуникации она такая. Если это не research задача, то команда из нескольких человек намного быстрее найдет все подводные камни в тз.
На эти тонкости натыкаются все, как узкие специалисты, как и фуллстек, и тем и тем приходится копаться в issue\гуглить\просматривать сообщества и блоги по используемой платформе. Фуллстеку это немного сложнее (из-за объемов информации), тут вы правы.
Сам почти год назад переключился c BE на FE стек, адаптация заняла примерно 1-2 месяца, каких-то особых проблем не почувствовал. Сложности ожидаемо были не с тем, чтобы изучить очередной фреймворк\сборщик\транспайлер, а с фундаментальными вещами, такими как проектирование приложений.
Такое можно было бы сказать о фундаментальных областях, таких как алгоритмы\проектирование, но никак не о том или ином стеке. В пример можно взять тот же frontend стек, технологии и подходы там сменяются достаточно быстро (от 6 мес. до года), что вполне позволяет не отставать от узких специалистов, если знаешь основы и периодически работаешь в этой области.
А почему fullstack разработчик не может быть специалистом? Чаще всего не смотря на свою fullstack-ость он будет разрабатывать не более одного компонента системы в единицу времени, что вполне позволяет ему совершенствовать навыки как во frontend так и в backend стеках.
В таком случае разработчик выступает не в роли «на-все-руки-мастер», а в качестве бекендера с хорошим знанием фронтенда и наоборот.
Вернемся выше:
> Я даже больше вам скажу, большая часть PHP разработчиков не в состоянии определить, в каком режиме работает PHP. По старинке пишут реврайты, php_value, etc в .htacess, два часа дебажат и в конечном итоге узнают то, что проект поднят на PHP-FPM.
Почему не в состоянии?
1) сервер настраивал нехороший человек, который не утруждался документированием
2) деплой настраивал не менее плохой человек
3) при этом на разработчика повесили задачу, зависящую от окружений, ни о чем не уведомив
Это не является ни проблемой программиста, ни его косяком, и тем более — такое не стоит приводить в пример, как типичную ситуацию.
Совсем нет, придуманы сотни инструментов, ansible, puppet, vagrant, docker, системы непрерывной интеграции и деплоя, если при таком гигантском инструментарии все еще продолжают возникать проблемы — то пенять нужно явно не на квалификацию программистов, а на того, кто организует рабочий процесс.
Bitrix это хорошо, но он находится вне контекста данной статьи, потому что он:
а) не является фреймворком общего назначения
б) не является альтернативной rails
Да, вполне возможно описанные вами проблемы могли возникать, но это другой мир с другими программистами и совершенно иными типами проблем. Для аудитории статьи сложности в вопросах настройки «php-fpm» просто нехарактерны, о чем я и писал выше.
> Он не перенастраивает, а добавляет и проверяет свой функционал, который крутил у себя в dev окружении
Которое должно автоматически развертываться и быть одинаковым для всех разработчиков.
А если на сервере php-fpm? Выше рассматривается именно этот момент.
Если человек пишет какой-то зависящий от окружения код или конфиги — он должен быть в курсе этого окружения. Если рассматривать ваш пример (с админом) — то последний должен был выкатить подробное readme, что делает невозможным вышеописанный случай.
Библиотеки тоже в блокноте писать? Давайте не углубляться в демагогию.
Смысл в том, что у аудитория этой статьи (людей, перед которыми может встать выбор Rails\условный Symfony) в любом случае имеются навыки как работы с консолью, так и настройки окружения, это просто повседневная задача.
Потому меня слегка удивляют утверждения, что человек продолжительное время использующий cli для разработки и деплоя что-то там не может настроить на сервере.
Статья о сравнении Rails с фреймворками из мира PHP, цмс и подобные системы учитывать смысла не имеет — потому что ruby как платформа практически не предоставляет альтернатив. Следовательно композер в предполагаемом php проекте — обязательный элемент.
Относительно деплоя — трогать .htaccess или настраивать проект под окружения должен именно тот — кто конфигурировал CI, остальных разработчиков эта задача не должна затрагивать от слова совсем. Если допустить, что незнакомый с особенностями используемой инфраструктуры человек идет что-то перенастраивать — он как минимум должен внимательно прочитать readme, где будет русским по-белому написано «используется php-fpm».
Другими словами — вы описываете случай, совершенно невозможный при адекватном разделении обязанностей, к качеству php разработчиков это имеет довольно мало отношения.
Как устанавливать\удалять composer пакеты без использования консоли? Почему автоматизицией деплоя и настройкой инфраструктуры\проекта под неё занимаются разные люди?
Расскажите, как это возможно? В данный момент все современные php фреймворки используют composer (пакетный менеджер), что предполагает активное использование консоли, как на этапе разработки, так и на этапе деплоя. Самостоятельно деплоить проект и не знать, как настроено окружение? Что-то тут не сходится, уж простите.
PHP разработчики не в состоянии посмотреть в конфиг вебсервера или в хедеры в ответе сервера? Я не знаю таких людей, которые при этом писали бы с использованием любого php фреймворка.
Curl же совершенно особая песня, его можно отнести к особым, наиболее неудобным сторонам php.
В качестве контрпримера приведу библиотеки, которые на мой взгляд привносят хорошие, удобные абстракции:
https://github.com/guzzle/guzzle
https://github.com/moment/moment
https://github.com/KnpLabs/Gaufrette
Это необходимо, особенно если учитывать, насколько неприятен чистый php. Решения таких задач как чтение-запись файла\загрузка данных по http\прослушивание сокета выглядят крайне неопрятно без использования сторонних библиотек, так как php в большинстве случаев не предоставляет удобных абстракций, а просто занимается копированием C функций.
— что мы делаем?
— для чего мы это делаем?
— а нужно ли это делать вообще?
— как это можно сделать иначе\лучше\быстрее?
Чаще всего ответов не знает даже сам постановщик задачи, но их можно найти, разговаривая с командой. Я веду к тому, что fullstack разработчик может экономить время или на максимально понятных\четких задачах (при грамотном постановщике) и на research задачах. Какие-то стратегически значимые решения доверять одному (пусть и достаточно опытному разработчику) я бы наверное не стал.
Получается два варианта:
1) фуллстек действует строго по тз, результат — «я его слепила из того что было»
2) фуллстек задает много уточняющх\корректирующих тз вопросов постановщику задачи, результат — отсутствие экономии времени
Как альтернатива этому — коллективное обсуждение, в процессе которого каждый разработчик сможет более глубоко взглянуть на свою часть задачи и задать более правильные вопросы еще до начала её выполнения.
Сам почти год назад переключился c BE на FE стек, адаптация заняла примерно 1-2 месяца, каких-то особых проблем не почувствовал. Сложности ожидаемо были не с тем, чтобы изучить очередной фреймворк\сборщик\транспайлер, а с фундаментальными вещами, такими как проектирование приложений.
В таком случае разработчик выступает не в роли «на-все-руки-мастер», а в качестве бекендера с хорошим знанием фронтенда и наоборот.
> Я даже больше вам скажу, большая часть PHP разработчиков не в состоянии определить, в каком режиме работает PHP. По старинке пишут реврайты, php_value, etc в .htacess, два часа дебажат и в конечном итоге узнают то, что проект поднят на PHP-FPM.
Почему не в состоянии?
1) сервер настраивал нехороший человек, который не утруждался документированием
2) деплой настраивал не менее плохой человек
3) при этом на разработчика повесили задачу, зависящую от окружений, ни о чем не уведомив
Это не является ни проблемой программиста, ни его косяком, и тем более — такое не стоит приводить в пример, как типичную ситуацию.
а) не является фреймворком общего назначения
б) не является альтернативной rails
Да, вполне возможно описанные вами проблемы могли возникать, но это другой мир с другими программистами и совершенно иными типами проблем. Для аудитории статьи сложности в вопросах настройки «php-fpm» просто нехарактерны, о чем я и писал выше.
> Он не перенастраивает, а добавляет и проверяет свой функционал, который крутил у себя в dev окружении
Которое должно автоматически развертываться и быть одинаковым для всех разработчиков.
Если человек пишет какой-то зависящий от окружения код или конфиги — он должен быть в курсе этого окружения. Если рассматривать ваш пример (с админом) — то последний должен был выкатить подробное readme, что делает невозможным вышеописанный случай.
Смысл в том, что у аудитория этой статьи (людей, перед которыми может встать выбор Rails\условный Symfony) в любом случае имеются навыки как работы с консолью, так и настройки окружения, это просто повседневная задача.
Потому меня слегка удивляют утверждения, что человек продолжительное время использующий cli для разработки и деплоя что-то там не может настроить на сервере.
Относительно деплоя — трогать .htaccess или настраивать проект под окружения должен именно тот — кто конфигурировал CI, остальных разработчиков эта задача не должна затрагивать от слова совсем. Если допустить, что незнакомый с особенностями используемой инфраструктуры человек идет что-то перенастраивать — он как минимум должен внимательно прочитать readme, где будет русским по-белому написано «используется php-fpm».
Другими словами — вы описываете случай, совершенно невозможный при адекватном разделении обязанностей, к качеству php разработчиков это имеет довольно мало отношения.