1. При выборе языка программирования на проект выбор встает между двумя сторонами — выбрать старый проверенный инструмент или новый, красивый, функциональный, но мало проверенный, а следовательно, ненадежный язык. Как разумнее поступить в этой ситуации? Каковы риски каждого из решений, и как с ними справиться?
Нужно выбирать инструменты по адекватности задаче и по наличию опытной команды, знакомой с выбранными инструментами. Риски при работе с новыми инструментами минимизируются исследованиями, созданием proof of concept, привлечением опытных консультантов. Новые технологии должны изучаться постоянно, но применяться, только если они лучше подходят для решения конкретной задачи.
Для бизнеса понятия «красивого языка» не существует. Сделать ставку на новый непроверенный язык можно только в том случае, если он гарантированно даст проекту какое-то особенное УТП, которое клиенты смогут почувствовать, а главное — захотят за него заплатить. Если это условие выполняется, то выбрать новый язык можно, но при этом придется принять на себя и все связанные с ним риски.
Конечно же, зависит от проекта и зрелости самого языка. Если проект позволяет, или использование языка является необходимым условием, и доступны нужные предметные библиотеки, то вполне можно позволить эксперимент. Риски очевидны: «подводные камни», на которые можно наткнуться на половине пути. Минимизация этих рисков тоже очевидна: по возможности провести исследования до начала проекта и убедиться, что, как минимум, есть активная поддержка языка в форумах или у производителя.
В этом вопросе все зависит от сроков и бюджетов проекта. Если и то, и то сильно ограничено, то любые изыскания не оправданы и способны принести большие проблемы, вплоть до полного провала проекта.
Ответ сильно зависит от того, какова планируемая длительность проекта. Если это небольшой проект на заказ, который надо быстро сделать, сдать и забыть о нем — тогда можно выбирать все, что угодно. Если это большой проект на года — то лучше выбрать проверенные технологии, на которые можно будет нанять нужное вам количество специалистов. Для того, чтобы оценить, сколько в вашем регионе есть специалистов по той или иной технологии, достаточно воспользоваться любым разумным сервисом, например, LinkedIn или HeadHunter. А дальше уже нужно смотреть на нефункциональные требования: нагрузка, безопасность, отказоустойчивость и т. п.
2. Какие существенные факторы дают гарантию, что язык можно и нужно использовать на продакшне?
Гарантии в этом мире не дает никто и ничто. Мы полагаемся на свой опыт и распространенные best practice.
Можно выделить три основных признака, которые говорят о том, что использовать тот или иной язык выгодно и безопасно. Во-первых, наличие у данного языка «живого» комьюнити, во-вторых, наличие успешных кейсов, и в-третьих, поддержка языка крупными вендорами.
Наличие «зрелых» предметных библиотек и фреймворков, активное интернет-сообщество, предлагающее советы в решении проблем, отсутствие негативных отзывов о стабильности и производительности конечного приложения.
Факторами являются комьюнити данного языка, количество реализованных проектов, количество разработчиков и прочее. Выпуск на продакшн продукта на новом и сыром языке скрывает большие проблемы с поддержкой.
Формальная гарантия может быть подкреплена только контрактом. Если есть серьезный вендор (например, Oracle, SAP, IBM), который гарантирует, например, что его технология будет поддерживаться ближайшие 10 лет, и с этим вендором подписан соответствующий Support Contract, то, в принципе, вы можете считать это какой-то гарантией. Проблема в том, что обычно это очень дорого, а качество саппорта у больших вендоров, как правило, отвратительное.
Поэтому в мире в последние годы принята другая практика — open source. Если у вас есть опенсорсный инструмент (язык, фреймворк, база данных или все что угодно) с открытым исходным кодом, то это вам дает некоторую гарантию того, что если в этом инструменте вдруг обнаружится баг, то вы в крайнем случае сможете поправить этот баг своими руками. Именно это свойство opensource-решений я считаю ключевым для сегодняшнего бизнеса.
3. Как действовать, если разработчик или даже несколько разработчиков предлагают изменение языка программирования, но по ситуации видно, что их азарт не подкреплен адекватными бизнес-требованиями к технологии?
Разработчики не предъявляют бизнес-требований. Их предъявляет бизнес. Однако бизнес зависит от качества кода, который пишут разработчики. Поэтому, если разработчики хотят использовать технологию, которая явно не подходит для решения бизнес-задачи, то надо либо убедить разработчиков, либо поменять. Адекватный и опытный разработчик в состоянии понять бизнес-требования и применить наиболее адекватное им решение. У нас подобных проблем не было. В нашей практике чаще происходит наоборот: заказчик вместо того, чтобы формулировать бизнес-требования, влияет на выбор технологии (часто в ущерб реализации собственных требований).
Если переход на новый язык не подкреплен ощутимыми аргументами и не сулит проекту серьезных преимуществ, то он не нужен. Но разработчикам, конечно, это необходимо объяснить, чтобы у команды не складывалось впечатления, что к ней не прислушиваются.
Придерживаться консервативной политики и не менять язык без веских оснований. Всегда будет другой проект, на котором можно будет опробовать новый язык.
Пойти навстречу разработчикам можно только в случае внутреннего проекта, или если он пишется для обучения команды. В этом случае риски неудачи невелики, и при неудаче выносится полезный опыт на будущее. В противном случае бизнес не оценит перфекционизма разработчиков.
Во-первых, следует спросить, чем обоснована идея по смене языка. Что это даст? Каковы плюсы и каковы минусы? Какова стоимость такого перехода и каковы сроки? Каковы риски?
Если полученные ответы вас устраивают с точки зрения бизнеса — вперед. Если не устраивают — нужно постараться донести до разработчиков причины, по которым вы им отказываете.
4. Когда затраты на переход с одного языка на другой стоят того?
Оценить затраты на смену платформы и сопутствующие выгоды невозможно вне контекста проекта. Такое решение может приниматься только на основании осознанного подхода в рамках конкретного проекта, а не на основании каких-либо «универсальных» мнений или правил.
Когда это повлечет за собой ощутимую прибыль, как прямую, так и косвенную вследствие появления у проекта нового УТП, которое сделает продукт конкурентоспособнее.
В случае, когда использование нового языка позволяет существенно оптимизировать всю жизненную цепочку предметной области: от проектирования, разработки и тестирования приложения до внедрения и последующих обновлений и доработок за счет свойств языка и экосистемы вокруг него.
Когда поддержка языка прекращена, а вместе с тем и количество специалистов на рынке стремится к нулю. Или если вы полностью теряете старую команду без возможности сохранить технологии. Когда профит от языка будет больше, чем затраты на его переход.
Когда у вас и ваших коллег есть четкие ответы на обозначенные выше вопросы.
5. Считаете ли вы, что существует устоявшееся разделение применения языков для определенных задач? Если да, то как именно вы его видите? Может ли появиться или уже существует язык, который изменит ситуацию и перетянет на себя большую часть разработчиков?
Конечно же, есть некоторые типовые сферы применения разных платформ (не языков). Например, Java и .NET для относительно крупных бизнес-приложений или сервисов. Node.js для многопоточной обработки и мессенджинга. Все не перечислить. Однако эти границы очень и очень размыты и зависят так же от региона. В США, например, немного другой опыт использования, «мода» и типовые сферы применения платформ, нежели у нас.
С одной стороны, устоявшееся разделение языков по применению существует, но с другой — довольно сильное значение имеют региональные и ценовые факторы: стоимость вхождения в технологию, поддержки и т.п. Что касается появления новых языков, то здесь нужно заметить такую вещь. За последние несколько лет уровень коммуникации вырос значительно, а языки программирования, по сути, все те же. Возможно, именно дальнейшая революция в области коммуникаций повлечет за собой совершенно новые технологии разработки.
В принципе, такое разделение есть: языки C и C++ традиционно используются для низкоуровневой разработки, Java и C# считаются языками общего назначения, подходящими для широкого спектра задач от бизнес-логики до мобильных приложений. Python, Ruby и PHP нацелены, в основном, на веб-разработку, JavaScript — на браузерные приложения. Не думаю, что возможны резкие изменения в этой области, хотя мода на языки и фреймворки иногда меняется — сейчас, например, начинает набирать популярность язык Go.
Да. Некоторые вещи лучше реализуются на разных языках в силу скорости работы и простоты использования, например, в php-проектах в силу «медлительности» языка можно реализовать чат на Node или агрегатор на Java — результат будет лучше.
С каждым годом каждый новый язык получает лавры «лучшего» и перетягивает на себя разработчиков, но пока, наверное, позиции проверенных языков незыблемы. В будущем все может быть.
Большинство известных нам с вами современных языков программирования являются многофункциональными, то есть на них можно делать очень разные решения.
Насчет нового языка — да, такой язык появиться может, но, в силу довольно сильной инертности индустрии, я не думаю, что в ближайшие 5 лет кто-то потеснит Java и С/C++ с пьедестала. Если же и выбирать какую-то «лошадку», то я поставил бы на JavaScript. Сегодня мы видим в индустрии огромный рост всего, связанного c JavaScript. Фреймворки рождаются, как грибы после дождя. Хайп в интернете вокруг этой технологии огромен. Посмотрим, к чему это все приведет.
6. Должен ли программист быть DevOps (обладать навыками программиста и системного администратора)? Что делать с тем, что большинство программистов отказываются развивать компетенции и нести ответственность в этой области?
Для настройки окружения обычно пользуются услугами системного администратора. Но, наверное, есть смысл в том, что человек, который пишет код, должен сам уметь настроить площадку для оптимального исполнения данного кода. Это сэкономит время и затраты.
7. Стоит ли использовать микросервисы в своих проектах?
Однозначного ответа нет, но наш ответ — да. Безусловно, они могут добавить немало проблем, но и помогут решить многие. Например, благодаря микросервисам разные части приложения можно писать на разных языках программирования, есть возможность масштабировать нагруженные части приложения и пр.
8. Должен ли разработчик уметь работать с широким спектром современных веб-технологий и языков?
В последние годы огромный рывок сделал фронтенд, при этом в серверных языках развитие не столь заметное. Разработчик, безусловно, должен знать основы смежных направлений, но быть гуру в серверных языках и в клиентских невозможно, каждый должен заниматься своим делом и быть в нем настоящим профессионалом.
Рейтинг языков программирования 2018 
