Как использовать несколько языков программирования и не сойти с ума

Привет! Представляю вашему вниманию перевод статьи «How to use multiple programming languages without losing your mind» ^[1] автора Bart Copeland.

Перевод авторской рекламной статьи о каком-то Серебряном Пуле.

Преамбула

Это перевод статьи ^[1]. В статье объясняется, почему полиглотство — очень опасный вещь.

Текст статьи

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

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

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

Создание многоязычного окружения часто бывает постепенным и ситуативным. Например, когда предприятие приобретает компанию, оно использует её технологическую платформу, включая языки программирования. Или с изменениями в техническом руководстве новые лидеры могут внедрить разные технологии. Технологии устаревают и выходят из моды, расширяя количество языков программирования и техник, которые организация должна поддерживать с течением времени.

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

Запутанные технические скороговорки

Там, где существует множество различных технологий — языков программирования, унаследованных инструментов и многообещающих технологических стеков (tech stacks), есть сложность. Инженерные команды проводят больше времени, чтобы перестроить языки программирования с лицензиями, безопасностью и зависимостями. В то же время руководству не достаёт надзора за соответствием кода и оно не может оценить риск.

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

Трудности только увеличиваются с добавлением большего количества языков программирования, что приводит к цифровой Вавилонской башне.
(Прим. перев.: видео Вавилонской башни из Civilization 3 ^[2].)

Ответ заключается не в том, чтобы отнять инструменты, которые необходимы разработчикам для работы. Добавление новых языков программирования создает их базу навыков и усиливает их правильным оборудованием для выполнения своих задач. Итак, вы хотите сказать «да» своим разработчикам, но по мере того, как в предприятии добавляется все больше языков программирования, они накладывают нагрузку на жизненный цикл разработки программного обеспечения (SDLC). В масштабе все эти языки и инструменты могут убить предприятие.

Существует три главных проблемы, на которые предприятия должны обращать внимание:

1. Видимость: команды собираются вместе для проекта, а затем распускаются. Приложения выпускаются и никогда не обновляются — зачем чинить то, что не сломано? В результате, когда обнаруживается критическая уязвимость, у предприятия может не быть видимости, какие приложения затронуты, в каких библиотеках находятся эти приложения или на каких языках они были созданы. Это может привести к дорогостоящим «изыскательским проектам», чтобы обеспечить верное нахождение уязвимости.
2. Обновление или написание кода: некоторые предприятия централизуют функцию обновления и исправления в одной команде. Другие требуют, чтобы каждая «кухня» управляла своими инструментами разработки. В любом случае команда разработчиков и руководство оплачивают альтернативные издержки: вместо того, чтобы добавлять новые функции, эти команды постоянно обновляют и исправляют библиотеки в своих инструментах с открытым исходным кодом, потому что они движутся так быстро.
3. Изобретение колеса: поскольку зависимости исходного кода и версии библиотек постоянно обновляются, артефакты, связанные с исходной сборкой приложения, могут быть недоступны при обнаружении уязвимости. В результате многие циклы разработки тратятся на воссоздание среды, в которой уязвимость может быть исправлена.

Умножьте каждый язык программирования в вашей организации на эти три вопроса, и то, что началось как кочка, внезапно станет горой Эверест. И точно так же, как скалолаз, вы не выживете без правильного оборудования и инструментов.

Поиск вашего Розеттского камня

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

Комплексные решения, которые удовлетворяют потребностям предприятия и его отдельных заинтересованных сторон в SDLC, по порядку. Предприятия могут создавать решения с использованием этих лучших практик:

1. Мониторинг кода, выполняемого в процессе производства, и реагирование на основе риска выделенных компонентов (например, общих уязвимостей и компонентов воздействия), используемых в ваших приложениях.
2. Получение регулярных обновлений, чтобы сохранить код актуальным и безошибочным.
3. Используйте коммерческую поддержку открытого исходного кода, чтобы получать помощь по версиям языков и платформам, которые близки к концу жизненного цикла и не поддерживаются сообществом.
4. Стандартизируйте определенные сборки языков программирования на своем предприятии, чтобы обеспечить согласованную среду между командами и уменьшить количество зависимостей.
5. Установите границу, когда запускать обновления, сигнал тревоги, или другие события, основанные на зависимостях.
6. Создайте единый источник истинности для управления пакетами; это может потребовать помощи знающего поставщика технологий.
7. Стройте небольшие дистрибутивы только с необходимыми пакетами, основываясь на ваших личных критериях.

Используя эти лучшие практики, разработчики могут максимизировать свое время, чтобы создать больше ценного для предприятия, а не выполнять основные задачи по оснащению или сборке. Это обеспечит согласованность кода во всех средах жизненного цикла разработки программного обеспечения (SDLC). Это также увеличит эффективность и экономию средств, поскольку для поддержания языков программирования и сборки пакетов потребуется меньше ресурсов. Этот новый образ действий облегчит жизнь как технического, так и управленческого персонала.

Об авторе

Барт Коупленд ^[3] является генеральным директором и президентом ActiveState, которая заново изобретает конструкцию с платформой предприятия, которая позволяет разработчикам создавать, сертифицировать и разрешать связи любых языков с открытым исходным кодом для любой платформы и любой среды. ActiveState помогает предприятиям безопасно масштабироваться с использованием языков с открытым исходным кодом и предоставляет разработчикам такие инструменты, которые они любят использовать. Барт имеет степень магистра делового администрирования в области управления технологиями в Университете Финикса.

Автор: Настоящее имя

Источник ^[4]