Привет! Представляю вашему вниманию перевод статьи «How to use multiple programming languages without losing your mind» автора Bart Copeland.
Перевод авторской рекламной статьи о каком-то Серебряном Пуле.
Преамбула
Это перевод статьи. В статье объясняется, почему полиглотство — очень опасный вещь.
Текст статьи
Многоязычная среда — это обоюдоострый меч, дающий преимущества вместе со сложностями, которые могут угрожать организации.
Со всеми различными языками программирования, доступными сегодня, многие организации стали цифровыми полиглотами. Open source открывает мир языков и технологий, которые разработчики могут использовать для выполнения своих задач, включая разработку и поддержку устаревших и современных программных приложений.
Полиглоты могут разговаривать с миллионами людей — больше, чем знающие только родной язык. В программных средах разработчики внедряют новые языки для достижения конкретных целей, а не для лучшего общения. Некоторые языки отлично подходят для одной задачи, но не для других, поэтому работа с несколькими языками программирования позволяет разработчикам использовать правильный инструмент для работы. Таким образом, вся разработка многоязычна; это в природе вещей.
Создание многоязычного окружения часто бывает постепенным и ситуативным. Например, когда предприятие приобретает компанию, оно использует её технологическую платформу, включая языки программирования. Или с изменениями в техническом руководстве новые лидеры могут внедрить разные технологии. Технологии устаревают и выходят из моды, расширяя количество языков программирования и техник, которые организация должна поддерживать с течением времени.
Многоязычная среда — это обоюдоострый меч для предприятий, дающий преимущества, а также сложности и трудности. В конце концов, если ситуация остается без внимания, многоязычность убьёт ваше предприятие.
Запутанные технические скороговорки
Там, где существует множество различных технологий — языков программирования, унаследованных инструментов и многообещающих технологических стеков (tech stacks), есть сложность. Инженерные команды проводят больше времени, чтобы перестроить языки программирования с лицензиями, безопасностью и зависимостями. В то же время руководству не достаёт надзора за соответствием кода и оно не может оценить риск.
Что происходит, так это то, что предприятия имеют различные уровни качества языков и высокую изменчивость в поддержке инструментальных средств. Трудно стать экспертом на одном языке, когда вам нужно работать с дюжиной. Существует большая разница в уровне мастерства между человеком, который свободно говорит на французском и итальянском языках, и человеком, который может связать несколько предложений на восьми языках. То же самое верно и для разработчиков и языков программирования.
Трудности только увеличиваются с добавлением большего количества языков программирования, что приводит к цифровой Вавилонской башне.
(Прим. перев.: видео Вавилонской башни из Civilization 3.)
Ответ заключается не в том, чтобы отнять инструменты, которые необходимы разработчикам для работы. Добавление новых языков программирования создает их базу навыков и усиливает их правильным оборудованием для выполнения своих задач. Итак, вы хотите сказать «да» своим разработчикам, но по мере того, как в предприятии добавляется все больше языков программирования, они накладывают нагрузку на жизненный цикл разработки программного обеспечения (SDLC). В масштабе все эти языки и инструменты могут убить предприятие.
Существует три главных проблемы, на которые предприятия должны обращать внимание:
- Видимость: команды собираются вместе для проекта, а затем распускаются. Приложения выпускаются и никогда не обновляются — зачем чинить то, что не сломано? В результате, когда обнаруживается критическая уязвимость, у предприятия может не быть видимости, какие приложения затронуты, в каких библиотеках находятся эти приложения или на каких языках они были созданы. Это может привести к дорогостоящим «изыскательским проектам», чтобы обеспечить верное нахождение уязвимости.
- Обновление или написание кода: некоторые предприятия централизуют функцию обновления и исправления в одной команде. Другие требуют, чтобы каждая «кухня» управляла своими инструментами разработки. В любом случае команда разработчиков и руководство оплачивают альтернативные издержки: вместо того, чтобы добавлять новые функции, эти команды постоянно обновляют и исправляют библиотеки в своих инструментах с открытым исходным кодом, потому что они движутся так быстро.
- Изобретение колеса: поскольку зависимости исходного кода и версии библиотек постоянно обновляются, артефакты, связанные с исходной сборкой приложения, могут быть недоступны при обнаружении уязвимости. В результате многие циклы разработки тратятся на воссоздание среды, в которой уязвимость может быть исправлена.
Умножьте каждый язык программирования в вашей организации на эти три вопроса, и то, что началось как кочка, внезапно станет горой Эверест. И точно так же, как скалолаз, вы не выживете без правильного оборудования и инструментов.
Поиск вашего Розеттского камня
(Прим. перев.: Розеттский камень содержит на себе записи трёх языков, что позволило с его помощью начать расшифровку египетских иероглифов.)
Комплексные решения, которые удовлетворяют потребностям предприятия и его отдельных заинтересованных сторон в SDLC, по порядку. Предприятия могут создавать решения с использованием этих лучших практик:
- Мониторинг кода, выполняемого в процессе производства, и реагирование на основе риска выделенных компонентов (например, общих уязвимостей и компонентов воздействия), используемых в ваших приложениях.
- Получение регулярных обновлений, чтобы сохранить код актуальным и безошибочным.
- Используйте коммерческую поддержку открытого исходного кода, чтобы получать помощь по версиям языков и платформам, которые близки к концу жизненного цикла и не поддерживаются сообществом.
- Стандартизируйте определенные сборки языков программирования на своем предприятии, чтобы обеспечить согласованную среду между командами и уменьшить количество зависимостей.
- Установите границу, когда запускать обновления, сигнал тревоги, или другие события, основанные на зависимостях.
- Создайте единый источник истинности для управления пакетами; это может потребовать помощи знающего поставщика технологий.
- Стройте небольшие дистрибутивы только с необходимыми пакетами, основываясь на ваших личных критериях.
Используя эти лучшие практики, разработчики могут максимизировать свое время, чтобы создать больше ценного для предприятия, а не выполнять основные задачи по оснащению или сборке. Это обеспечит согласованность кода во всех средах жизненного цикла разработки программного обеспечения (SDLC). Это также увеличит эффективность и экономию средств, поскольку для поддержания языков программирования и сборки пакетов потребуется меньше ресурсов. Этот новый образ действий облегчит жизнь как технического, так и управленческого персонала.
Об авторе
Барт Коупленд является генеральным директором и президентом ActiveState, которая заново изобретает конструкцию с платформой предприятия, которая позволяет разработчикам создавать, сертифицировать и разрешать связи любых языков с открытым исходным кодом для любой платформы и любой среды. ActiveState помогает предприятиям безопасно масштабироваться с использованием языков с открытым исходным кодом и предоставляет разработчикам такие инструменты, которые они любят использовать. Барт имеет степень магистра делового администрирования в области управления технологиями в Университете Финикса.
Автор: Настоящее имя
