Комментарии 43
Посмотрел и предыдущую статью заодно - в общем вы очень странный путь выбрали и пошли по нему странным способом.
Сейчас если с PHP и переписывают то на Go. Джава это прекрасно но в бэкенде "Run everywhere" абсолютно неактуально - у вас всё будет крутиться в кластере в однотипных контейнерах на линуксе. Нативная компиляция сэкономит изрядное количество денег на инфраструктуре. Java жирная. Go не фонтан конечно, но я сам мигрировал сюда после 10+ лет в Java и пока выглядит так что это не была моя фантазия, а весь энтерпрайз потихоньку движется в этом направлении.
Ну и не говоря уж о том что м.б. вы зря с PHP уходили. Я так понимаю проблема была не в нём а в том что напедалили монстра в котором самим уже страшно было разбираться. Ну и решили что для решения проблем нужно просто махнуть шашкой / серпом / волшебной палочкой и сейчас сразу станет все хорошо. Ждём что вы через 10 лет о чудо-решении на "Java + MACH" напишете :)
Энтерпрайз потому что на джава, кому ты продашь продукт на пыхе, в банк, например?
В Java давно есть компиляция в натив, включая Spring Boot. Что позволяет комплексно отлаживать большие и сложные системы в JVM и компилировать стабильные версии в натив, включая виртуальные потоки.
Переписать с пхп на го - классика ) это самое простое и понятное что можно сделать. Весь вопрос то не только в потреблении ресурсов и "жирности" - а есть еще ряд факторов по которым го не подходит для определенных вещей. Либо подходит, но больно ) Насчет того, что весь ентерпрайз движется в этом направлении - тут очень спорно. Трудно согласиться.
взяли всю свою PHP‑команду и начали переобучать ее на Java.
А в чем заключалась мотивация самой команды? Зачем опытному разрабу переучиваться на джуна, еще и в Java, где не легко и не просто, лет 5-7 потребуется для уровня "уверенный мидл".
Да в принципе все стали понимать что PHP уходит. Есть пара ребят которые ушли по классике в GO. Но Java была неплохой альтернативой. Ребятам было интересно. Ну и насчет 5-7 лет - это не так совсем. Если человек - серьезный senior на PHP - я считаю год-полтора и он в Java как минимум middle+ будет. Сама основа быстро заходит. Инженерный опыт тут больше играет роль.
PHP уходит
Я бы и про Java не сказал, что она куда-то вместо чего-то приходит. Запросто может сдуться за 5-7лет до пенсионеров с не повышающимися зарплатами.
Если человек - серьезный senior на PHP - я считаю год-полтора и он в Java как минимум middle+ будет
Никем он не будет за год-полтора. Чтобы пойти на hh и получить работу с нормальными деньгами, придется очень много зубрить и сильно приврать опыт Java. По одному проекту, переписанному командой джунов, вряд ли прокачаешь актуальный на рынке стек.
в Java нет ничего супер сложного. По мне оно поудобнее и поприятнее пхп в разы. Если специалист хорошо ориентируется в архитектурных подходах и в инфраструктурных делах - ну уровень высокий если в целом, ничего сложного перекатиться в жаву не вижу. Сейчас есть другая проблема конечно с HR и рынком труда. Много волков и вкатышей. Это проблема влияет на всех. Тут вот сложно ответить на вопрос как именно сегодня быть. Зубрить особо ничего не надо, как я уже сказал - подходы везде очень похожие - оно просто должно заходить. Если ты опытный в чем-то - то другое легко зайдет. Это же не переучивание с пилота самолета на капитана корабля.
в Java нет ничего супер сложного
В большинстве ЯП нет ничего сложного, но включиться в разработку весьма не просто. У меня ощущение, что вы переоцениваете свою команду. У меня на прошлой работе был опыт работы с двумя стеками, мне об этом не говорили при найме, но потом оказалось, что проект пишется дважды, каждый исходник сохраняется в два репозитория. Часть клиентов сидела на одной СУБД, а часть на другой.
Так вот я вам скажу, что меня не хватило, чтобы влезть в мир чужой для меня СУБД и там прокачаться хотя бы на уровне мидла. Да, синтаксис и основы учатся за год, но это уровень - джун. А вот дальше уже нужно наступить себе на горло, чтобы разобраться с чем-то, такими темпами я бы лет за 10 вышел на мидла.
Могу сказать следующее. Команда именно разработки - почти 20 человек. Часть команды - это ребята которые всю жизнь работали на java/spring стеке - и проблем с нашими проектами у них нет. Кроме того, мы работаем с крупными интеграторами, где свои команды разработки, которые онли-жава - внедряют наши продукты. Там вся наша кодовая база проходит внутреннюю валидацию. Естественно, мы как вендоры с ними взаимодействуем - и с лидами и с архитекторами и с линейными разработчиками и с тестерами. Получаем обратную связь. Вопросов к нашей архитектуре, коду, подходам и т.д. - не возникает критичных. Кроме того, интеграторы интеграторами - часто у заказчиков своя вообще технологическая база и команда - и с ними мы тоже прекрасно работаем. По крайней мере тьфу тьфу никто не говорил - ой че это вы такое наделали, какой ужос. Насчет СУБД... мм... ну мы поддерживаем например postgres и oracle - ну платформа в смысле. Поддержку oracle конечно не просто было подвозить (клиент захотел) - но опять же ничего ужасного.
Часть команды - это ребята которые всю жизнь работали на java/spring стеке
Это уже малость проясняет ситуацию. А остальные, кто изначально сидел на php, остались в команде джунами для перекладки джейсонов, видимо от безысходности.
но опять же ничего ужасного.
Ничего ужасного, если у вас не стоит вопрос сложности и производительности. А когда у вас раз в неделю на каком-то клиенте выстреливает деградация и нужно немедленно переписывать запросы, то работаешь до нервного истощения.
Нативные жависты к нам пришли уже после того как у нас в прод вышла платформа. Так что тут мимо. Иначе они бы не пошли к нам - т.к. не интересно.
Я уже окончательно запутался в вашей истории, нативные жависты к вам пришли работать на php, а потом вы их переучили обратно?
ахаха. у нас была платформа на пхп. и команда на пхп. мы уперлись в определенные потолки и узкие горлышки и начали смотреть что с этим делать. Сделали MVP на жаве. Пилотным клиентам понравилось - они решили вложиться - вот полтора года мы выпускали пилот. Выпустили, у клиентов поперло все и полетело - они довольны. Мы стали остальную команду переучивать и после этого уже возникла необходимость расширять штат - начали брать целевых спецов.
Все равно не понятно, что было раньше, курица или яйцо. Кто писал MVP на жаве, если была команда на пхп? Кто сопровождал это до момента переучивания и найма нативных спецов.
Мы скоро придем к тому, что никто никого не переучивал, а все занимались своим делом, негодных просто уволили.
MVP делал я, потом подключил пару ребят еще. У меня опыт с Java уже был. Я с ней работал еще с 2005 года.
Ну то есть заголовок "Как мы за 1.5 года переобучили с PHP на Java всех разработчиков" даже не рядом с правдой. В команде из 20 человек, кто-то уволился, кто-то имел опыт с 2005г, а половину нативных и вовсе потом наняли.
Да почему. 20 человек это сегодня. На тот момент было человек 7-8 кажется. Все PHP.
Там mvc, тут mvc, там сервисы и солид, тут так же.
Плюс ллмки сейчас на любой банальный аопрос мгновенно отвечают что и почему.
Ндигственно, жава дурацкая, котлин - вот выбор.
в Java нет ничего супер сложного
Скажите, вот Вы пишете, что менторили РНР разрабов в процессе перехода на джаву. А можно узнать, каков Ваш собственный опыт с ней? Почитали доки, решили, что нет ничего сложного, и тут же начали учить других?
Честно говоря, после прочтения обеих статей складывается впечатление, что вы не сумели разобраться, как готовить РНР, и решили заменить плиту, а не повара. Вероятно, примерно с тем же успехом – просто пока джава код ещё молодой, не успел обрасти костылями, и поэтому пока его обслуживать проще. Представить, что команда, не имеющая никакого представления о джаве, смогла качественно переписать на ней проект энтерпрайс уровня, продолжая при этом обслуживать, и даже развивать прежнюю реализацию на РНР, мне довольно сложно. Равно как и представить себе бизнес, готовый зависнуть на полтора года – просто потому, что разработчикам взбрело в голову поменять технологический стек.
С 2005-го года, даже чуть раньше. Тогда еще апплеты поддерживались браузерами. Ну вы конечно краски сгустили. "Почитал документацию и вперед всех учить" - смешно конечно )))) На самом деле примеров на рынке много, когда команды полностью переписывали свое решение на другой технологии. Это не что-то из ряда вон выходящее. И бизнес так же "не завис" - у нас про это написано же достаточно подробно.
С 2005-го года, даже чуть раньше.
И до какого времени? Практическую разработку я имею в виду. Не думаю, что СТО РНР команды мог успевать параллельно поддерживать экспертный уровень джава-разработчика. Соответственно, и менторить переход на современные джава решения.
На самом деле примеров на рынке много, когда команды полностью переписывали свое решение на другой технологии.
Несомненно, сам таким занимаюсь, прямо сейчас в том числе. Сомнения вызывают мотивация и организация процесса.
Да ерунда :) Пару месяцев на привыкание к синтаксису и в полный рост можно клепать круды, да джейсоны туда-сюда перекладывать. Тем более, примеров как это делается пруд пруди. А там, по ходу дела, постепенно догонят и остальное.
Вот для нагрузок, многопоточки, безопасности и прочих действительно сложных вещей, нужны сильные и опытные специалисты. Но немного. Их и правда, не один год "готовить" надо. Таких лучше нанять
можно клепать круды, да джейсоны туда-сюда перекладывать.
Это стоит 120-150к на рынке труда, еще задолбаешься проходить фильтры эйчаров и собеседования с литкодом. Не понятно, зачем ради этого переучиваться с php.
Нагрузка, многопоточка и сесурити тоже не проблема - если реально работал со сложными системами хоть на пхп, хоть на пайтоне, хоть на чем. Понятное дело что если например всю жизнь на битриксе или на ворпрессе - тогда ой )
Многопоточности ни в пхп, ни в питоне нет. Они там это другими средствами решают (многопроцессность, gil и пр). То есть, сколько бы опыта не была в том же пхп, человек там не узнает про атомики, CAS, memory orderings и happens before.
Аналогичная проблема со структурами данных: ну не научиться человек делать кастомные хешмапы в пхп. Поэтому тоже придётся учиться этому с нуля.
там есть надстройки типа swoole и либы для коллекций. но такое, согласен
Вроде в 3.14 запилили настоящую многопоточность и как-то gil обошли? Или я ошибаюсь?
В PHP разработчик обязан знать про атомарность и тот же cas, как один из вариантов её реализации, в виду того, что один и тот же запрос может быть обработан параллельно дважды (кликнули на кнопку дважды, кулхацкеры и т.д.).
А зачем ему учиться делать кастомные хешмапы, когда у него есть массивы?
Как я понял, вы устали плохо писать на РНР, поэтому решили начать хорошо писать на Java.
Я себе тоже в каждом новом проекте говорю, что уж этот то я точно буду делать чисто и аккуратно...
ну не то что плохо. но легаси поднабралось конечно плотное. там платформа была еще до всяких autoload-ов и namespace-ов сделана и мигрировала потом на новые версии пхп
И в чём проблема была тогда прикрутить рядом новую платформу и постепенно переводить кодовую базу на неё?
А так, рефакторинг ради рефакторинга выходит, плюс бонусом оверхед на смену ЯП.
как понять "прикрутить новую платформу рядом" - на пхп всмысле? мы же в статье написали что нам его начало не хватать в принципе. надоели все эти штуки - то расширение поставь, эту либу подключи, такие настройки, сякие - и это в принципе только для инфраструктурных задач все пляски. и в итоге все равно производительность не очень.
Спасибо за статью
а были те люди которые попробовав джаву не решились с ней работать и остались на пхп проекте ?
Прям на PHP остаться полностью никто не пожелал. Если мы берем для php-проектов PHP разработчика - он на Java команду обычно смотрит какое-то время и перекатывается в итоге ))
Был один сотрудник. Причем он неплохо влился, но решил все же в go уйти впоследствии, года 4 назад. Так же были пара ребят джавистов - один ушел в моб разработку на flutter и один просто перешел в другую компанию.
Ждём через пару лет статью "Как мы за 1.5 года переобучили с Java на Python всех разработчиков" ради выхода в сегмент LLM.
Как мы за 1.5 года переобучили с PHP на Java всех разработчиков