Пять причин, почему PHP иногда лучше Java

1) Легче найти джунов. К сожалению, это парадокс нынешнего состояния дел в IT-индустрии. Пока начинающий Java-программист мечтает о том, какой ногой лучше открывать дверь в отдел кадров перед очередным собеседованием в ООО "Рога и копыта", захлебываясь гордостью по поводу своей супер-мега-востребованности, на его место вероломно нанимаются сразу двое джунов PHP. Причем оба согласны пахать на дядю в сумме за те же деньги, которые попросит одинокий Java-разраб. По опыту скажу, что все трое героев сравнительно паршиво будут работать первый год уж точно, за ними глаз да глаз нужен, по производительности труда разницы особой не заметит никто. А если нет разницы, то... Правильно. Сюда же добавляю подпункт - вообще легче заменить любого программиста в команде, использующей PHP, чем стек Java. Пока джависты будут ломаться и запрашивать астрономические суммы за выполнение обычной работы, наслаждаясь своей "незаменимостью" и "дефицитом специалистов", пхпшники будут просто молча работать. Когда большая конкуренция (а именно - в сфере задач на PHP, не требующих архисложных навыков и over9000 опыта за плечами), то это хорошо ставит обладателя (особенно его мозги) на нужное место.


2) Не насаждается ООП-парадигма. На PHP низок порог входа, новичку можно запросто написать работающий код, нарушающий все мыслимые и немыслимые мечты перфекционистов о "красивом коде". И код будет функционировать в данное время в данном месте. И проект будет со скрипом сдан в требуемые сроки с примлемым уровнем качества, заказчик доволен. И все участники сего процесса получат по граненому советскому стакану, до краев наполненному ароматным клубничным смузи, плюс тульский пряник за старания. А Java-перфекционисты вынуждены будут разбираться, почему не компилируется, обязательно разведут срач об именах классов, паттернах, увязнут в потрохах монструозного фреймворка и прочей лабуде. И останутся с носом. В общем, такой хороший марафон по граблям протяженностью пару ночей гарантирован. Проект застопорился, все недовольны.


3) Разработка на Java медленная. На интерпретируемых языках типа PHP разработка быстрая. Раз-два-три, накидали прототипчик, натянули криво/косо фронтенд. Показали наработки заказчику. Не понравились - выбросили, все переделали с нуля, повторяем цикл. На Java так не получится. Там уже наверняка предусмотрительным джуном, прочитавшим недавно книгу из серии банды четырех, заведены эти ваши интерфейсы, которые жалко выбрасывать, куча абстрактных классов погоняет кучей других, поэтому "из песни слов не выкинешь". Сидит такой ночью и причитает: "вроде выкинул из проекта все ненужное, а не компилируется... Шеф убьет... Стабильного варианта в системе контроля версий нет. Ааааа.."


4) Сама Java тормозит. Ну тут без комментариев, все слышали байки об этой особенности. Как начинаешь делать что-то на самом деле серьезное, никуда не деться без копания в тонкостях настройки виртуальной машины, танцев с бубном для ускорения времени компиляции и т.д. У PHP все нормально из коробки, для любых проектов.


5) Проблема Spring aka "Из пушки по воробьям". На Java де-факто стандарт для разработки проектов является Spring. От него никуда не деться, он забивается все щели, куда не просят, и вышвырнуть все зависимости не представляется возможных. Все равно, что тебе надо, - простой проект, средний, сложный, - приходится везде тащить этот чертов Spring. Это опять-таки замедляет разработку и вносит лишнюю, никому не нужную сложность. В мире PHP тьма фреймворков для веба. Для совсем простеньких - да хоть за день CMS-ку развернуть, Wordpress, Joomla, Drupal, как что-то плохое! Для простеньких - на тебе, пожалуйста, микрофреймворки Lumen, Silex, Slim. Для вещей посерьезнее - Yii, Laravel, Phalcon. Для среднего и даже больше - Zend Framework, Symfony. Никакой монополии, в отличие от Java, для каждой задачи - свои, удобные средства разработки. Переучивание и освежение в памяти особенностей фреймворков не должно занимать слишком много времени, что тоже несомненный плюс.


С радостью услышу ваши отзывы о работе с любым стеком технологий. Причем на backend у комментаторов не обязательно должны быть лишь PHP или Java. C#, Go, Perl, Ruby, Python - тоже приглашаю высказаться. Про JS на backend уж не надо сегодня, извольте, с больной головы на здоровую...

Вы смотрите срез комментариев. Показать все
8
Автор поста оценил этот комментарий

Скажу с точки зрения бизнеса, выступая в роли заказчика. При том, что когда-то сам был разработчиком, потому есть некоторый технический бекграунд. Понимаю перфекционизм некоторых товарищей(есть друзья-разработчики, пошедшие по другому жизненному пути), он похвален, но... Если не брать компании специализирующиеся на разработке ПО и продающие именно своё ПО длительное время, смотрю с точки зрения заказчика. В большинстве задач когда бизнес что-то заказывает ему нужно решение какой-то проблемы. Причем чем быстрее, тем лучше. При этом почти всегда это решение осознается как временное, срок его жизни иногда пол года-год, иногда несколько лет, временами оно может прослужить и 10. И тем не менее востребовано решение уже сейчас, важно понимать что если оно не будет получено сейчас(а это максимум пол года для более-менее сложных задач и уже достаточно крупных компаний), то скорее всего паровоз уедет и идею забросят, или она преобразится до неузнаваемости, что выльется в необходимость начинать всё с нуля. Так вот, нужно решение проблемы "уже вчера". При этом часто не гарантированно то что функционал решения как-то отразится на прибыли. Надо проверять, тестировать. Кто выиграет, компания предлагающая решить вопрос за условные 400к и месяц-два разработки, или компания предлагающая сделать то же самое по функционалу, но за несколько миллионов и за 8 месяцев? Ответ очевиден. Что будет выгоднее, потратить дополнительные несколько месяцев(а зачастую и год) и круглую сумму средств на разработку, или выкатить поскорее и тупо выделить сервер под задачу за сотню-две тысяч рублей? При этом даже если потом всё переиначится железка всё-равно не пропадет и куда-то приспособится. Или вообще просто арендовать где-то за 10к в месяц сервер и даже не покупать Ответ очевиден.


В итоге всё выливается в то, что реально задач, где нужна медленная грамотная разработка довольно мало. Чаще всего требуются разной степени костыльности затычки, которые как-то уже работают и не важно, сколько ресурсов потребляют - работало бы и ладно.


Ну и конечно, чаще всего нужны не решения с нуля, а доработка чего-либо уже готового. И тут выбор платформы обычно даже не рассматривается - дорабатывать надо то, что есть.


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

раскрыть ветку (11)
1
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Решение написано может быть сколь угодно через жопу, при этом если уж если совсем критически не накосячили, то решается вопрос грамотным сис. админом. И тогда и работает достаточно шустро. А сколько там ресурсов ест и сколько стоит сервер - это вопрос, который интересует очень мало кого. Железка не стоит практически ничего, по сравнению со стоимостью разработки. И огромная, немаловажная часть - это когда и как нести расходы. Выкинуть сегодня несколько миллионов на заказ разработки или забить и докинуть в бюджет на железки 20-30к в месяц? Тут чаще всего вопроса даже не стоит.

0
Автор поста оценил этот комментарий

а чем занимаетесь? что за сфера, где костыли и заплатки являются нормой и принимаются заказчиком?

раскрыть ветку (7)
4
Автор поста оценил этот комментарий

Да любая, не важно. Что такое не костыли и заплатки? Я просто смотрю реально на вещи. Есть всегда два варианта - или сделать правильно, или как-то, лишь бы работало. В 99,99% случаев бизнес выберет именно второй вариант. Почему? А как сделать правильно, с точки зрения разработки? Взять всю задачу целиком, описать все бизнес-процессы с которыми она как-то контактирует, спроектировать и реализовать. А как бывает на практике? Обычно, примерно так: у нас есть система А, система B и система C, надо решить задачу D. Надо брать данные из системы A, которая была написано криворуким орангутаном в 2002м году, но довольно долго писалась и в ней куча функционала который переработать будет стоит дорого. Данные брать в том виде в каком она их отдает или напрямую из БД, преобразовывать их дополняя информацией из системы B, работающей в таком-то формате и отдавать результаты помимо прочего в систему C. Система B при этом - условно, 1С, а C - какой-нибудь сервис написанный на php. Работать с этим ПО будут такие и такие сотрудники. То, что я описал - практически стандартная задача в нескольких предложениях. Предложить переделать с нуля систему A, переписав всё с нуля написанное за годы? Про B даже говорить не хочу. А C - это всего-лишь, по сути, интерфейс. Как можно реализовать не костыльно то, что по своей сути является костылём? И вот так и живём. Во многих сферах работал, везде плюс-минус такая ботва. Системы и их функционал меняется, специфика разная, интерфейсы разные, а суть - одна и та же.

раскрыть ветку (6)
Автор поста оценил этот комментарий
Взять всю задачу целиком, описать все бизнес-процессы с которыми она как-то контактирует, спроектировать и реализовать.

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

Без аналитики деятельности лезть в бизнес-процессы и надеяться что все заработает - вы серьезно?

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

раскрыть ветку (5)
1
Автор поста оценил этот комментарий

Чувак пишет про то что есть, вы пишете как должно быть с вашей точки зрения. Пишите тоже как обстоят дела у вас а не у сферического бизнеса в вакууме

раскрыть ветку (4)
Автор поста оценил этот комментарий

Если у бизнеса все так, то в договоре об оказании услуг на первом месте снятие с себя всякой ответственности за последствия. Большими буквами.


Или бежать нахер от такого бизнеса, у которого непонятно, кто и что делает.

раскрыть ветку (3)
1
Автор поста оценил этот комментарий

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

раскрыть ветку (2)
0
Автор поста оценил этот комментарий

зачем про меня вам что-то знать?
каким образом это изменит вашу картину мира?

или сантехник не может указать нечто вполне логичное?


вот вам вопрос, что вы делаете на своей работе, и почему?

отвечу за вас - то, что прописано в должностной инструкции + распоряжения непосредственного руководства


а чем руководствуется ваш начальник? ответ - тем же, но на своем уровне


а кто пишет инструкции? на основании чего? как измеряется достижение целей?

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


а вот если некто пишет, что бизнес выбирает инструмент в виде костылей и не может ответить на вопрос, что ему надо, то смотри мой предыдущий комментарий

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

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

и систем у которых хотя бы было тз вообще лично у нас не так уж и много.


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

Автор поста оценил этот комментарий

Благодарю за столь развернутый комментарий. Ваша точка зрения мне близка

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества