В первую очередь нас заботила ТТМ. Мы довольно большие и у нас много сервисов, и средняя скорость разработки в старых PHP монолитах заметно меньше, чем в новых перенесенных на Go. Тут конечно не только стек решает, но и сам рефакторинг. Очень позитивно сказывается на онбординге новичков, тут тоже помогает микросервисная архитектура, а Go для этого и создан. По техническим метрикам разница значительная в некоторых параметрах десятки раз. Память Go из коробки расходует скромнее и стабильнее) Еще одна не маловажная метрика это счастье разработчиков. И 90% перешедших безусловно не хотят возвращаться. И при прочих "равных" тут явный перевес)
Конкретного времени создания нет, обычно его дополняют те кто его проходит и лиды время от времени. Проходят его все новобранцы в OnlineShop за прошлый год примерно 10.
Как правило, мы указываем, что от такого кандидата мы ожидаем «опыт разработки на Go или желание изучать язык", например: job.lamoda.ru/vacancies/senior-go-developer-1
В общем стоит смотреть описания если компания готова к обучению она должна это обозначить.
Я не называл это основной причиной, но да она весома.
Например, PHP код представляет собой набор текстовых файлов, для исполнения которых необходимо: php, php-fpm, nginx, OS … Это уже немалый такой овер, так как Go сервис это исполняемый файл и нужна только OS при этом достаточно малая ее часть. Контейнеры легче и количество их меньше, поддерживать и масштабировать проще. Да можно писать на C или C++ но уровень вхождения в язык по сравнению с Go достаточно высок, а значит вероятность ошибок больше, тут Go выигрывает потому что проще.
Go не идеален и возможно использовать равные подходы и языки для микро сервисов он оптимальнее, по крайней мере для нас)
Go новый инструмент который очень хорошо ложится в парадигму микро сервисной архитектуры. Мы попробовали нам понравилось. Отказались ли мы от PHP и все делаем на Go? Нет. Это просто еще один инструмент.
2 — Стоит помнить, что переход на Go это еще смена парадигмы языка, не достаточно изучить синтаксис и менять foreach на for. Также стоит учитывать наши практики, которые могут отличаться от принятых на stackoverflow =)
3 – Важно понимать, что программисты тоже люди, новое место работы — это стресс. Мы тратим время на комфортную прокачку будущего коллегу без усталости и антидепресантов)
Задачи на «прод» крайне редко охватывают все стороны микросервиса, нам важно чтобы новичок изучил и попробовал как мы делаем сервисы в целом. Знал зачем тот или иной «файлик» присутствует в проекте и на что влияет, имея полную картину проще дополнять и улучшать. Про code review полностью согласен он присутствует на всех этапах и на онбординге тоже, но даже самое крутое ревью может пропустить bug который будет стоить денег простоя.
4 – Да это и есть простенькая статья на внутреннюю вики. Важно, что новичек потрогает это в безопасном режиме и будет знать базу. В будущем на своих первых деплоях он будет увереннее и конечно не один)
«wiki радел для ньюкамеров + code review + ментор» Все так только на тестовом проекте чтобы снять напряжение с новичка и нагрузку с лида.
Тяжело в учении легко в бою.
Отвечу за Ламоду
В первую очередь нас заботила ТТМ. Мы довольно большие и у нас много сервисов, и средняя скорость разработки в старых PHP монолитах заметно меньше, чем в новых перенесенных на Go. Тут конечно не только стек решает, но и сам рефакторинг. Очень позитивно сказывается на онбординге новичков, тут тоже помогает микросервисная архитектура, а Go для этого и создан. По техническим метрикам разница значительная в некоторых параметрах десятки раз. Память Go из коробки расходует скромнее и стабильнее) Еще одна не маловажная метрика это счастье разработчиков. И 90% перешедших безусловно не хотят возвращаться. И при прочих "равных" тут явный перевес)
Буду работать над собой, а то PHPшникам не нравлюсь ;-)
По количеству в штуках 80 Go / 20 PHP, если учитывать размер и сложность 60 Go / 40 PHP.
Все новые системы запускаем без PHP, в основном на Go, но есть немного Java, Kotlin, C# и др.
1 Пофиксим
2 Поправили
3 Поправили
=)
В общем стоит смотреть описания если компания готова к обучению она должна это обозначить.
Например, PHP код представляет собой набор текстовых файлов, для исполнения которых необходимо: php, php-fpm, nginx, OS … Это уже немалый такой овер, так как Go сервис это исполняемый файл и нужна только OS при этом достаточно малая ее часть. Контейнеры легче и количество их меньше, поддерживать и масштабировать проще. Да можно писать на C или C++ но уровень вхождения в язык по сравнению с Go достаточно высок, а значит вероятность ошибок больше, тут Go выигрывает потому что проще.
Go не идеален и возможно использовать равные подходы и языки для микро сервисов он оптимальнее, по крайней мере для нас)
2 — Стоит помнить, что переход на Go это еще смена парадигмы языка, не достаточно изучить синтаксис и менять foreach на for. Также стоит учитывать наши практики, которые могут отличаться от принятых на stackoverflow =)
3 – Важно понимать, что программисты тоже люди, новое место работы — это стресс. Мы тратим время на комфортную прокачку будущего коллегу без усталости и антидепресантов)
Задачи на «прод» крайне редко охватывают все стороны микросервиса, нам важно чтобы новичок изучил и попробовал как мы делаем сервисы в целом. Знал зачем тот или иной «файлик» присутствует в проекте и на что влияет, имея полную картину проще дополнять и улучшать. Про code review полностью согласен он присутствует на всех этапах и на онбординге тоже, но даже самое крутое ревью может пропустить bug который будет стоить денег простоя.
4 – Да это и есть простенькая статья на внутреннюю вики. Важно, что новичек потрогает это в безопасном режиме и будет знать базу. В будущем на своих первых деплоях он будет увереннее и конечно не один)
«wiki радел для ньюкамеров + code review + ментор» Все так только на тестовом проекте чтобы снять напряжение с новичка и нагрузку с лида.
Тяжело в учении легко в бою.