Всем привет!
В развитие прошлого поста предлагаю поговорить про большие компании и новые языки программирования.
Вопросы, на который я постараюсь дать исчерпывающий ответ:
1) какие риски несет внедрение нового языка в enterprise?
2) нужно ли согласовывать внедрение?
3) кто это должен делать?
Ключевое отличие внедрения нового языка от внедрения нового хранилища или очереди - тут нет противоречия разработка-сопровождение.
Если говорить про JVM или .NET языки - т.е. случай, когда есть виртуальная машина между приложением и ОС - то при смене языка ничего в плане сопровождения не меняется. Случаи, когда новый язык сгенерирует какой-то неработающий или неоптимальный байт-код я рассмотрю далее.
А если даже язык не JVM\.NET - мы живем в мире победившего Docker и тут все еще лучше: сопровождению остается провалидировать базовый образ, который к нам пришел от создателей языка, и\или выставить требования, что там должно быть.
Может возникнуть вопрос - а что делать, если готового базового образа нет? А вот это "звоночек" и потенциальный блокер.
Я бы вопрос расширил - а что, если язык настолько редкий или новый, что его создатели забыли\не доросли до Docker.
Это вопрос к тем, кто занимается наймом. HR или скорее Tech Lead\ИТ лидер. От них нужен анализ рынка для того, чтобы ответить на вопрос: что будет, если разработчик, предложивший новый перспективный язык, уйдет из компании? Насколько такие разработчики дороже? Т.е. первый критерий - распространённость языка.
Кроме анализа рынка тут может помочь https://www.tiobe.com/tiobe-index/, в частности подсказать тренд - растет или падает популярность языка. Получаем второй критерий - растет л использование языка?
И добавим третий - насколько язык сложен для обучения. Тут нужно экспертное мнение Team Lead\Tech Lead. Да, настоящий разработчик освоит любой язык, но обучение и набор опыта - это простой с точки зрения бизнеса, его нужно максимально снижать.
По первому критерию для сферической компании в вакууме я бы отмел, к примеру, Scala. И как ни обидно для Scala - по-третьему тоже. Все же Scala - это немного brainfuck)
Почему для сферической компании в вакууме - есть компании в РФ, где Scala живет давно, для них очевидно этот аргумент не актуален.
Да и по сложности обучения все не так однозначно - если в компании принцип: "Отбираем лучших", - то Scala как раз может быть позитивным фильтром)
По второму критерию можно отфильтровать Ruby, пик его популярности пройден.
Итого - согласовывать переход на новый язык программирования конечно же нужно, но основной вопрос здесь в легкости\стоимости найма разработчиков и простоте обучения для новичков. К сопровождению или корпоративной архитектуре он отношения не имеет.
Да, возвращаясь к вопросу про неработающий байт-код. Если язык на рынке давно, то вероятность такого события пренебрежимо мала. А чтобы ее уменьшить еще сильнее есть древнее правило - не надо обновляться на новые версии в первых рядах, стоит подождать хотя бы месяц-другой.
И чтобы добить эту тему - возражение со стороны платформы- "мы не сможем оказывать вам поддержку (консультации) для языка xyz" - некорректно. Т.к. если язык распространен - поддержку окажет документация, stackoverflow, habr, Yandex\google, или даже ChatGPT. Ответственность на ИТ лиде и команде конкретного подразделения.
#jvm #language #scala
В развитие прошлого поста предлагаю поговорить про большие компании и новые языки программирования.
Вопросы, на который я постараюсь дать исчерпывающий ответ:
1) какие риски несет внедрение нового языка в enterprise?
2) нужно ли согласовывать внедрение?
3) кто это должен делать?
Ключевое отличие внедрения нового языка от внедрения нового хранилища или очереди - тут нет противоречия разработка-сопровождение.
Если говорить про JVM или .NET языки - т.е. случай, когда есть виртуальная машина между приложением и ОС - то при смене языка ничего в плане сопровождения не меняется. Случаи, когда новый язык сгенерирует какой-то неработающий или неоптимальный байт-код я рассмотрю далее.
А если даже язык не JVM\.NET - мы живем в мире победившего Docker и тут все еще лучше: сопровождению остается провалидировать базовый образ, который к нам пришел от создателей языка, и\или выставить требования, что там должно быть.
Может возникнуть вопрос - а что делать, если готового базового образа нет? А вот это "звоночек" и потенциальный блокер.
Я бы вопрос расширил - а что, если язык настолько редкий или новый, что его создатели забыли\не доросли до Docker.
Это вопрос к тем, кто занимается наймом. HR или скорее Tech Lead\ИТ лидер. От них нужен анализ рынка для того, чтобы ответить на вопрос: что будет, если разработчик, предложивший новый перспективный язык, уйдет из компании? Насколько такие разработчики дороже? Т.е. первый критерий - распространённость языка.
Кроме анализа рынка тут может помочь https://www.tiobe.com/tiobe-index/, в частности подсказать тренд - растет или падает популярность языка. Получаем второй критерий - растет л использование языка?
И добавим третий - насколько язык сложен для обучения. Тут нужно экспертное мнение Team Lead\Tech Lead. Да, настоящий разработчик освоит любой язык, но обучение и набор опыта - это простой с точки зрения бизнеса, его нужно максимально снижать.
По первому критерию для сферической компании в вакууме я бы отмел, к примеру, Scala. И как ни обидно для Scala - по-третьему тоже. Все же Scala - это немного brainfuck)
Почему для сферической компании в вакууме - есть компании в РФ, где Scala живет давно, для них очевидно этот аргумент не актуален.
Да и по сложности обучения все не так однозначно - если в компании принцип: "Отбираем лучших", - то Scala как раз может быть позитивным фильтром)
По второму критерию можно отфильтровать Ruby, пик его популярности пройден.
Итого - согласовывать переход на новый язык программирования конечно же нужно, но основной вопрос здесь в легкости\стоимости найма разработчиков и простоте обучения для новичков. К сопровождению или корпоративной архитектуре он отношения не имеет.
Да, возвращаясь к вопросу про неработающий байт-код. Если язык на рынке давно, то вероятность такого события пренебрежимо мала. А чтобы ее уменьшить еще сильнее есть древнее правило - не надо обновляться на новые версии в первых рядах, стоит подождать хотя бы месяц-другой.
И чтобы добить эту тему - возражение со стороны платформы- "мы не сможем оказывать вам поддержку (консультации) для языка xyz" - некорректно. Т.к. если язык распространен - поддержку окажет документация, stackoverflow, habr, Yandex\google, или даже ChatGPT. Ответственность на ИТ лиде и команде конкретного подразделения.
#jvm #language #scala
👍3