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

May 02, 2019
Blog

Перед началом работ над любым проектом, будь то мелкое «домашнее» приложение или монументальное Enterprise-решение, у людей, инициирующих старт разработки, возникает вопрос: «На каком языке будем писать?». Может показаться, что ответить достаточно легко, но не все знают, что начать нужно с вопроса «Что мы будем писать?».

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

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

Предположим, у вас уже есть четкое представление о будущем проекте и ТЗ к нему. Теперь, чтобы не оступиться во время выбора технологий разработки, надо иметь хотя бы базовое представление о том, чем между собой различаются языки программирования. Ответов на этот вопрос огромное количество, но сейчас речь идет о фундаментальных различиях и сферах применения. Только в случае понимания этих различий вы сможете задать осмысленный вопрос: «Какие плюсы и минусы есть у языка программирования N?» и получить при этом на него понятный ответ, который можно будет «приложить» к требованиям своего проекта.

Мы не будем оперировать профессиональными терминами и разделять языки на высокие, низкие, объектно-ориентированные и так далее. В нашем случае понадобится короткий список из пяти позиций, каждая из которых просто и прозрачно соотносится с любым ТЗ:

1. Платформа приложения (область применения языка).
2. Гибкость языка.
3. Продолжительность разработки и «жизни» проекта.
4. Производительность.
5. Сообщество языка.

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

Разным языкам — разные сферы

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

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

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

Давайте вернемся к нашему списку факторов и рассмотрим через него Python:

1. Область применения: почти что угодно и где угодно.
2. Гибкость: внушительная.
3. Продолжительность разработки: быстро.
4. Производительность: в наличии, только если у вас значительные или же неограниченные вычислительные мощности.
5. Сообщество языка: огромная армия девелоперов всех уровней.

Как видите, основная проблема рассматриваемого в качестве примера Python — его прожорливость. Если мы делаем веб-приложение, которое будет «крутиться» где-то на серверах Google, то мы можем позволить себе разработку на этом языке. Но если речь идет о мобильном или вовсе десктопном приложении, когда целевое оборудование может быть весьма маломощным, о Python стоит забыть.

И что самое важное: такие нюансы есть в любом языке программирования. Какие-то из них могут быть для вас не важны, а другие — будут фатальны. И чтобы четко понимать, что повлияет на проект, а что нет, нужно знать, что именно у вас получится после разработки, и кто этим будет пользоваться.

Рассмотрим еще один язык, пусть это будет C++. Порог вхождения в него намного выше, чем в тот же Python, но у него есть ряд достоинств, которыми Python не обладает. Например, C++ позволяет четко контролировать потребление ресурсов нашим программным обеспечением, что делает его отличным выбором для написания производительных приложений, которые должны работать в ограниченной среде. Так, C++ очень любят в области игровой индустрии, когда команде надо «втеснить» весьма солидную по сложности и размерам логику в ограниченное пространство конечной пользовательской конфигурации, далекой по мощностям от сервера. Сюда же можно записать и мобильные приложения и игры, которым и вовсе приходится довольствоваться маломощными процессорами и весьма скромным объемом оперативной памяти, которые, кроме всего прочего, нужно будет делить еще и с другими «жильцами» устройства.

С другой стороны нужно понимать, что C++ — это как меч, состоящий целиком из лезвия, без рукояти. Опытный разработчик будет виртуозно с ним управляться, а вот слабая команда создаст приложение, которое по своему потреблению ресурсов не сильно отличается от проекта на более прожорливом Python, но при этом оно будет еще и медленнее собираться. Также в C++ нет той управляемой среды разработки, которая есть в более «архитектурных» молодых языках, то есть еще и сам процесс создания ПО будет долгим и мучительным, а результат, полученный на выходе, может не обрадовать.

В качестве итога давайте пройдемся по нашему списку факторов, теперь уже в приложении к C++:

1. Область применения: приложения, требующие быстродействия и работы в ограниченной среде.
2. Гибкость: малая.
3. Продолжительность разработки: дольше среднего.
4. Производительность: C++ — это язык про эффективное использование каждого мегабайта памяти. На нем создаются самые эффективные в плане потребления мощностей приложения.
5. Сообщество языка: огромная армия девелоперов, но часть из них «вредители», так как порог вхождения в язык весьма высок.

Приведенные выше примеры немного утрированы, но весьма показательны, а самое главное, отметают ультимативные заявления вида «язык N лучший» или «язык N подходит для чего угодно». Как видите, универсального языка не существует. Любые из них имеют ряд заметных различий, которые либо сделают ваш проект крайне успешным, либо похоронят его под бесконечными циклами исправлений и доработок.

Модные языки программирования и их опасность

Кроме популярных языков программирования, которые у всех на слуху, есть еще и модные в прямом смысле этого слова. Чаще всего — это какие-то новинки, которые предлагают расширенные возможности, которых нет в других языках, либо же они имеют какой-то особый синтаксис. На самом деле это не столь важно. А вот по-настоящему важно то, что выбор модного языка программирования вместо просто популярного — это, скорее всего, прямой путь к пропасти.

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

Фактически это означает, что разработчики еще не нашли или не выработали оптимальных путей решения тех или иных задач с помощью данного языка и, соответственно, экспериментируют. Но эксперименты приемлемы на домашних проектах, а когда речь идет о коммерческой разработке, такие внезапности ни к чему, потому что бизнес любит предсказуемость и конкретику.

Бывает и так, что опытный разработчик на каком-нибудь модном языке у вас уже есть, по списку факторов язык подходит вам идеально, так почему бы не начать разработку?

Проблема в том, что кроме разработки приложения чаще всего нужно еще и поддерживать достаточно длительное время, а для этого нужны человеческие ресурсы. К счастью или сожалению, но экзотические/модные языки программирования редко получают достаточное распространение для того, чтобы их сообщество разрослось до по-настоящему заметных размеров. Это означает, что если вам потребуется второй, третий или десятый девелопер в команду, то вакансию вы будете закрывать месяцами, если закроете ее вовсе. Чаще всего проекты на модных языках в будущем ждет либо поддержка людьми, которые освоили этот самый язык прямо на рабочем месте, либо же полное переписывание под что-то более распространенное и понятное. И тот и другой варианты стоят дополнительного времени, денег и нервных клеток руководства.

Вот пример. Еще 3-4 года назад сотни компаний и проектов искали себе разработчиков на Ruby, конкретно знакомых с фреймворком Ruby on Rails, вместо PHP или JavaScript-девелоперов. «Рельсы» были настолько популярны, а разработчикам на них платили настолько много, что представители этого сообщества позволяли себе высказывания вида:

«Ruby on Rails и PHP — это как Apple Macintosh и PC. Нас мало, но мы элита. Ruby on Rails и PHP — это культура против хаоса».

Казалось, что за RoR будущее, но мода, замешанная на технической необходимости, прошла: для стабильно развивающегося JavaScript выпустили несколько новых библиотек, которые закрывали потребности в функционале Ruby on Rails в разработке, и популярность языка Ruby и его фреймворка начала сходить на нет. Да, Ruby on Rails до сих пор используется на многих проектах, опытные RoR-девелоперы востребованы на рынке, но вакансий стало в разы меньше, чем несколько лет назад. Случилось это в первую очередь по причине того, что конкурирующие с Ruby on Rails языки программирования тоже не стояли на месте и благодаря обновлениям, созданию новых фреймворков и библиотек столь острая необходимость в RoR со временем отпала.

Раз в несколько лет какой-то язык или фреймворк «выстреливают», очень быстро вокруг него выстраивается небольшое сообщество. Например, сейчас популярны Rust или Golang. И никто не знает, закрепятся ли эти языки, либо же их вытеснят более стабильные и зрелые «старожилы». Вообще, влезать в разработку, опираясь на модный язык или технологию весьма опасно, так как в будущем могут возникнуть серьезные проблемы с поддержкой, о которой мы подробно поговорим далее.

Области применения, сроки и поддержка

Крайне важно понимать, в какой области ведется разработка проекта, потому что универсальных языков программирования не существует — все они живут и развиваются в своих собственных специализированных нишах. При этом языки и технологии сегментируются не только по области (веб, мобильная, десктопная и так далее) разработки, но и по сфере применения. Например, ту же веб-разработку можно условно разделить на клиентский фронтэнд и серверный бэкэнд. И для обеих этих частей одного и того же веб-проекта языки и технологии будут разными. То есть для создания веб-проекта недостаточно нанять команду JavaScript или PHP-девелоперов, которые сделают вам фронтэнд часть, вам потребуются еще и специалисты бэкэнда. Часто этот очевидный нюанс ускользает от людей, далеких от программирования, что в лучшем случае выливается в расширение сметы, а в худшем — в реальные потери времени и бюджета.

Еще один аспект, который очень часто игнорируют: цикл жизни проекта. Часто заказчик отталкивается исключительно от сроков разработки с момента получения ТЗ до сдачи работающего проекта. Особенность dev-сферы в том, что после этапа активной разработки наступает менее интенсивный, но чрезвычайно важный период поддержки. Именно о дальнейшую поддержку спотыкается огромное количество компаний.

Классический сценарий выглядит следующим образом: игнорируя необходимость будущей поддержки и советы специалистов, заказчик выбирает самый быстрый и дешевый вариант на не самой подходящей технологии. Неверный выбор и сжатые сроки выливаются в низкое качество кода и работу по принципу «вот тут мы вставим костыль, потому что у нас нет времени». В дальнейшем поддержка подобного кода, внедрение новых фич и просто доработки будут стоить в разы, если не в порядки дороже. При этом проект без хотя бы минимальной поддержки уже через год-два обречен на упадок и стагнацию: IT-сфера постоянно развивается, предлагая все новые и новые решения старых проблем, которые мгновенно становятся «стандартом». За примером далеко ходить не надо — достаточно открыть любой сайт десятилетней давности, поддержка и обновление которого с того момента не осуществлялась, и посмотреть, какие решения в области веб-разработки были в ходу в тот период. Как минимум они вызывают ироничную улыбку, а чаще — негодование и недовольство.

Описанный нами простой и абсолютно прозрачный способ проверки нужен для того, чтобы избежать ситуаций, когда вас убеждают создать что-то на «удобном» для исполнителя или советчика языке. Например, если вас будут уговаривать писать мобильную игру для Android на Python или убеждать, что вместо прозрачного и понятного JavaScript или PHP нужно обязательно внедрять уже немного устаревший и дорогущий в плане зарплат Ruby on Rails, либо попробовать модный на текущий момент язык.

К мнению экспертов и опытных девелоперов все равно нужно прислушиваться, ведь это их территория, но простой список факторов «область, гибкость, время, производительность, сообщество» поможет либо выявить попытку наглого обмана, либо не допустить грубейшую ошибку, игнорируя мнение профессионалов.

Будьте внимательны.

Предыдущая статьяСледующая статья