Как определить, какой язык лучше всего подойдет для вашего решения? Я работаю облачным инженером в полиглот-проекте и чувствую себя как дома, работая с множеством технологий. Но иногда это заставляет меня задуматься — существует ли последовательный метод выбора правильного инструмента для работы? Проблема многогранна и требует рассмотрения с разных точек зрения.
Я не могу не подчеркнуть, что решения, основанные на молве, вносят много предубеждений. Это может стоить вам много времени — в первую очередь, а в худшем случае — даже работы. В конце концов, никто не знает ваш конкретный вариант использования лучше, чем ВЫ.
Принятие решений на основе данных, основанных на неопровержимых фактах, может значительно улучшить ваши результаты. И поэтому необходимо провести некоторое исследование, прежде чем делать выводы. На протяжении всей статьи я покажу вам различные аспекты, которые следует учитывать. Также хочу поделиться с вами своими личными мыслями, дополненными тем, что есть в интернете.
Размеры
При анализе языков (и стеков в целом) необходимо учитывать множество параллельных аспектов. Некоторые из них могут быть
- Волатильность требований — само собой разумеется, что каждый проект находится в движении. Перспективы меняются… Клиенты меняют свое мнение… Новые технологии дают преимущество другим компаниям и так далее…
- Дорожная карта — что требуется для POC? Что нужно для MVP?
- Показатели состояния языка и экосистемы.статистика, полученная из StackOverflow и GitHub, может многое вам рассказать.
- Адаптивность — это разовый проект или он останется навсегда? Будет ли он высечен на камне или должен развиваться со временем?
- Влияние.не все услуги одинаковы. Некоторые из них имеют решающее значение для функционирования всей компании, другие являются льготами.
- Масштаб — насколько велика будет желаемая кодовая база? Некоторые языки лучше для обслуживания, чем другие.
- Производительность —разные языки имеют разный вес производительности.
- Домен —домен ограничивает набор языков на выбор.
- Талант.чем более нишевый язык, тем больше стоимость привлечения нужных людей. Иногда даже будет трудно найти любой.
- Риск – сколько вы готовы поставить на карту. Вы закончите его любой ценой?
- Целевые устройства —поддерживает ли язык Windows | Линукс | Mac OS X? Это для встроенного или x86?
- Интеграция с другими инструментами — насколько хорошо он интегрируется с другими языками в компании, базами данных, криптографией и т. д.
- Стоимость — сколько денег потребуется для работы в долгосрочной перспективе.
Откуда брать данные
Не было бы неплохо подкрепить свои решения реальными фактами? Статистические панели могут сэкономить вам много времени на выяснение вещей. Хорошее начало это:
Он отлично подходит для получения исторических временных рядов для различных качеств репозитория. Нравиться:
- объемы запросов на слияние с течением времени и их классификация по размеру
- время ответа на вопросы с течением времени
- временной ряд совокупных открытых и закрытых проблем
Он предоставляет различные статические метрики для репозитория GitHub, в частности:
- количество звезд
- количество участников
- ежедневный выпуск/PR/Commit Rate
Наиболее интересен технический раздел. Вы изучаете самые любимые языки и самые популярные в процентах от общего числа.
Здесь вы можете проверить конкретный тег для данных.
- общее количество сообщений по сравнению с количеством сообщений без ответа
- связанные теги для совпадающих технологий
Сочетание этих ресурсов может дать общее представление о том, куда движется экосистема. Затем, после сканирования нескольких кандидатов, следующим шагом будет детализация и чтение дополнительных материалов, таких как сообщения или PR и проблемы.
Планируйте заранее и концептуализируйте
Прошли времена метода водопада. Современный мир заставил нас принять гибкие методы разработки программного обеспечения. Это поможет вам лучше адаптироваться к неизвестному. Но все же, когда дело доходит до технологий, по-прежнему необходимо думать о будущем.
Придумайте дорожную карту минимум на два года. Затем подумайте о компонентах, которые помогут достичь того, что необходимо. Выбери один:
- Проверить метрики фреймворка
- Сканировать верхние посты в StackOverflow на наличие тега
- Читать документацию
- Прогнозировать болевые точки
Затем повторите…
Есть много вещей, чтобы рассмотреть. Являются ли они автономными в одной экосистеме? Возможна ли их замена на что-то другое? Насколько хорошо язык интегрируется с выбранной вами базой данных? Есть ли у него криптография? Нужны ли привязки к C? В Ассамблею? Другие языки вообще? Как насчет написания тестов — это легко?
Мы живем не в идеальном мире, и иногда не все критерии соблюдаются:
- эффективность — инструмент выполняет свою работу только наполовину или охватывает только часть функций.
- согласованность — фреймворк плохо сочетается с существующим кодом, и вам придется приложить усилия для его интеграции.
- эффективность – работает медленно или потребляет слишком много памяти.
- устойчивость — требуется много времени на обучение команды, знания приходится освежать/обновлять
Вы должны обсудить это с заинтересованными сторонами и согласовать компромиссы для каждого фреймворка. Ваша роль состоит в том, чтобы понять варианты на столе и представить их нетехническому персоналу в нескольких вариантах.
Для языков, на которые я рекомендую обратить внимание, в первую очередь, качество поддержки. Когда обнаружена ошибка — как быстро ответят сопровождающие? Я бы также поискал в StackOverflow потенциальные подводные камни.
Во-вторых, стоит учитывать всю функциональность, содержащуюся в языковой экосистеме. Некоторые языки идут рука об руку с некоторыми вариантами использования, и это может сильно сузить ваш выбор. С моей точки зрения, я могу сказать, что большинство проблем находятся на границах между технологиями, поэтому важно, чтобы они хорошо интегрировались.
Другие ключевые моменты, которые следует учитывать:
- если крупный спонсор поддержит технологию
- если его ключевые части стабильны
- сколько обучения требуется
- это поддерживается текущими инструментами
- если это безопасно
- если это ремонтопригодно
- насколько сложно внедрить технологию
Доказательство концепции, затем MVP
Практичность всегда важнее теоретических концепций. Создание модели — единственный способ узнать, подходит ли стек. Когда у вас есть рабочий POC, вы можете начать проект с него. Это творческая часть, после чего дальнейшее развитие событий гораздо более предсказуемо.
Я советую разрабатывать много версий одновременно, исключая некоторые из них, экспериментируя с разными фреймворками. Я бы не стал ставить все на один стек, я бы выбрал 3-4 из них. Каким должен быть временной промежуток, зависит от вас, но лучше не превышать двух недель. Чем дольше вы занимаетесь, тем больше вы устаёте или привязываетесь к той или иной технологии. А на исходе должна быть холодная и просчитанная оценка.
Разработка POC равноценна оценке осуществимости решения. Это время, когда бюджет определяется. Вы также оцениваете риски, которые могут саботировать продукт в долгосрочной перспективе. Помните, что вы должны работать в быстром темпе.
После того, как Proof of Concept стабилизируется, вы начинаете работать над MVP (Minimum Viable Product). Разница в том, что последний должен быть продуктом, готовым к показу заинтересованным сторонам/покупателям. Его основная цель — получить обратную связь и внести исправления, если это необходимо. MVP должен занять максимум пару месяцев. В конце концов, у вас будет готовый UX для демонстрации бизнесу.
Помните, что это только основное подмножество функций. Ошибка — пытаться реализовать слишком много. Решение представлено потребителям, поэтому решения для наблюдения должны быть на месте. Иногда маршрутизация трафика будет необходима для A/B-тестирования.
Для динамичной среды отдавайте предпочтение адаптивности
Некоторым предприятиям необходимо постоянно меняться и приспосабливаться к новым тенденциям. Как правило, это проекты на стыке исследований и инженерии.
Идеальный язык должен:
- обеспечить способ абстрагирования вещей (принцип открытости/закрытости)
- быть многоцелевым с большой экосистемой библиотек
- сделать быстрое развитие легким
- иметь хорошую поддержку со стороны сопровождающих
Новые языки представляют большинство из этих функций, но не новейшие.
- Python — это просто и понятно. Он имеет обширную коллекцию библиотек и сильное сообщество
- JavaScript — хорош для веб-разработки. Он гибкий, с хорошей поддержкой сообщества, позволяет очень быстро развиваться.
- Go — хорош для создания масштабируемых систем из-за своей простоты. Он также очень производительный и предназначен для системного программирования.
- Kotlin — у него сильная экосистема из-за работы на JVM. Он очень универсальный и статически типизированный. Это хорошо для мобильной разработки.
Стабильные инструменты для критических компонентов
Мы должны относиться к языку и фреймворку с долей скептицизма. В наши дни темпы эволюции программного обеспечения довольно высоки. Выживание конкретного инструмента — вопрос пары лет, и по прошествии этого времени я бы считал его безопасным для будущего. Пробыв здесь какое-то время, эти языки оказались «достойными» и набрали обороты. Что более важно, они имеют основные стабильные функции.
Большая часть программного обеспечения имеет многоуровневую архитектуру с ядром посередине. Он не сильно меняется на протяжении всей жизни приложения (если вообще меняется). Так что быстрое развитие — это не то, что нам нужно. Нам скорее нужен язык, который предсказуем и будет существовать в будущем.
Спросите HN: почему Pascal потерпел неудачу? | Хакер Новости
Почему Lisp потерпел неудачу (2010) | Хакер Новости
Как лучше всего пойти? Чтобы остаться в середине. Так что найдите язык программирования в его золотой век, который наступил уже некоторое время. C++, Java и Python — универсальный и отличный выбор. Они также демонстрируют активную поддержку сообщества, имеют общее назначение и адаптируются к новым тенденциям.
Стандартизируйте то, что у вас есть
Некоторые компании устанавливают внутренние стандарты, чтобы способствовать общению и эффективности команд. Стандартизация может включать одни и те же языки, процессы и инструменты. Наиболее заметным является Netflix:
Netflix OSS и Spring Boot — полный круг | от Технологического блога Netflix
который стандартизирован на Java, а затем на Spring.
Вопрос в том, что лучше стек полиглота или стандартизированный? Ответ как всегда — зависит.
Стоимость пропорциональна концептуальному расстоянию между экосистемами. Одно дело — переписать некоторые сервисы с Java на Kotlin. Совсем другое дело — переписать решение нативной сборки под микросервисы на Java.
Кроме того, существует понятие синергии —объединенной силы команд, которая больше, чем их сумма. Чрезмерная коммуникация и отладка проблем на границах не способствуют синергии. И это то, о чем вы просите, когда у вас много стеков. Вот почему стандартизация лучше в глобальном масштабе.
Мое личное мнение таково: у вас должна быть веская причина, чтобы ввести новый язык в стек. А это может быть:
- легче привлекать таланты
- делает работу лучше
- старое решение стало коммерческим / мертво
Выбор скучных языков
Скучные языки не так популярны и востребованы на рынке, в большинстве случаев они делают тяжелую работу. Их ремонтопригодность делает их идеально подходящими для больших систем и длительных проектов.
Год назад я изучил программирование на Go. Перепробовав уже много разных языков, у меня постоянно возникало ощущение, что ему не хватает функций. Но я должен признать, что я никогда не программировал так легко и весело за всю свою жизнь.
Простота использования превосходит лаконичность. Выразительность хорошая, но чем меньше признаков, тем меньше когнитивная нагрузка на мозг. Кто-то сказал, что языки системного программирования должны быть предельно простыми. Это объясняет, почему популярность C не угасла.
Скучные языки обычно являются наиболее масштабируемыми. Каждая функция синтаксиса имеет свою стоимость. Сначала каждый разработчик должен узнать, что он существует. И даже в этом случае могут появиться ошибки. Скука также означает стабильность и небольшое количество причуд, что хорошо.
Есть два типа неизвестных — знаю неизвестное и неизвестное неизвестное. Когда вы выбираете скучный язык, заполнение пробелов не занимает много времени. Но представьте, что вы впервые увидели Scala — страшно, правда? Как говорит нам презентация по ссылке, существует гораздо большая дихотомия между двумя типами неизвестных в языках с пакетом функций.
По возможности используйте старое решение
Разработчики находятся в постоянном искушении переписать. Но иногда в этом просто нет смысла, кроме хорошего маркетинга. Если вы решите переписать приложение, вы выбросите все знания, которые вы накопили за годы, в мусорное ведро. А старую еще надо обслуживать.
Бывают случаи, когда код становится настолько запутанным, что его переписывание становится единственным вариантом. Вы все равно не должны этого делать. Вместо этого следует приложить все усилия, чтобы узнать, что он делает, и реорганизовать его (именно так некоторые компании вышли из бизнеса).
Почему бы не переписать программное обеспечение
Изменение вашего стека стоит. Может быть, даже значительное предприятие. Поскольку компания, в которой вы работаете, не является благотворительной, она должна нести ответственность. Поэтому у вас должна быть веская причина для этого, а преимущества должны перевешивать недостатки.
Новые блестящие инструменты в основном незрелые и обременены высоким риском того, что что-то пойдет не так. Если в этих инструментах есть скрытые ошибки / уязвимости, будьте готовы месяц за месяцем наращивать его версии.
Управляйте рисками
Все, что мы делаем, сопряжено с определенной долей риска, это факт. Но мы не должны сдерживать его, мы должны активно управлять им. Тот же случай с разработкой программного обеспечения.
Возможно, вы знакомы с инновационными токенами. Вы тратите большую часть времени на исправление ошибок и поддержку программного обеспечения. Вы сокращаете технический долг, и, в конце концов, ваша награда — несколько жетонов инноваций. Вы можете использовать их для чего угодно. Это может быть новый фреймворк, переписывание сервиса или что-то еще.
Планируя использовать новый стек, я бы использовал что-то подобное. Давайте назовем это лягушками. Сначала вы садитесь с заинтересованными сторонами и договариваетесь, сколько лягушек вы готовы проглотить. Затем вы договариваетесь о том, сколько риска приходится на одну лягушку.
Затем, когда дело доходит до выбора технологий, вы думаете о том, насколько они рискованны с точки зрения токенов. Примите во внимание сам язык + все зависимости экосистемы и их взаимодействие.
Затем, на последнем этапе, вы отбрасываете те стеки, которые превышают максимальный риск, который вы были готовы потратить в первую очередь. Я не буду глотать лишнее количество лягушек, нет, спасибо!
Заключение
Это оно. В этой статье представлены мои собственные мысли, иногда пересекающиеся с тем, что есть в сети. Точка зрения у всех разная, и вы можете не согласиться с некоторыми утверждениями здесь. Чего я хотел добиться, так это побудить вас провести собственное исследование.
Спасибо за чтение.
