За годы работы я часто слышу вопросы о выборе технологий для того или иного веб-проекта. Некоторые спрашивают у нас, как правильно, а кто-то приходит и просит сделать проект на конкретной технологии. Проблема в том, что большинство выбирают технологии по субъективным причинам. Пока я не слышал достойного и понятного рассуждения, которое позволит выбрать технологию объективно, основываясь на фактах, а не желаниях. Даже не все IT-шники делают правильный выбор, ведь для этого нужно: понимать специфику проекта, иметь многолетний опыт разработки на нескольких языках и знать, как устроены подобные проекты.
Прежде чем что-то выбирать, давайте посмотрим, какие технологии бывают, чем они отличаются и в каких случаях какую технологию выбрать.
Как чаще всего выбирают технологию сейчас:
В чем тут проблема:
Таким образом, ни один из вышеперечисленных методов выбора технологий разработки не отвечает критериям объективности. Поэтому стоит сначала определить эти критерии, а уже потом подбирать по ним техническую платформу.
Ниже я попытаюсь выделить важные для проекта критерии, на которых мы и будем основываться.
Важные критерии при выборе технологий:
Выбирая технологию по таким критериям, мы сможем добиться объективного выбора и тем самым сэкономить себе время и деньги.
К технологиям мы еще вернемся, а пока давайте разберемся, какие бывают проекты. Часто тип проекта говорит сам за себя и можно сразу сказать, что подойдет: либо уже готовое решение, либо хотя бы в какую сторону нужно двигаться.
По сложности проекты делятся:
По тематике: интернет-магазины, доски объявлений, социальные сети и так далее. Для большинства популярных тематических решений уже давно есть коробочные продукты и, если мы не пытаемся сделать какого-то монстра, то правильнее будет выбрать именно их. Решений очень много, все в одной статье описать невозможно.
В технологиях я бы выделил 3 уровня абстракции:
Чаще всего один уровень абстракции базируется на другом. То есть на чистом языке делают фреймворки, а на них делают CMS. Для каждого популярного языка есть много разных фреймворков и CMS, но об этом позже.
Если 10 лет назад, говоря о технологиях больших сайтов, все имели в виду преимущественно Java, то сегодня это может быть почти любой язык и утверждать, что сайты делаются на каком-то конкретном языке — стереотип. Это связано с развитием самих языков, за последнее десятилетие многие сильно продвинулись в развитии и получили широкие возможности.
В огромных порталах может использоваться сразу несколько языков программирования. Опять же, мы приходим к объективным критериям выбора. Часто один язык может хорошо делать одну задачу, а другой — другую. Такие проекты могут быть настолько огромными, что их части могут работать на разных серверах, с разными доменами (поддоменами) и разными технологиями.
Не следует бояться винегрета технологий в большом проекте, хотя и допускать его нужно, когда это действительно необходимо, а также помнить, что далеко не все технологии совместимы. Самый яркий пример использования разных технологий — Google.
Он настолько большой, что разные его части написаны на C/C++, Java, Python, JS и других языках. Более того, Google активно создает новые технологии, как, например, популярный нынче AngularJS.
Попробую дать краткую характеристику каждому из популярных языков:
Я описал самые популярные языки, которые сегодня используются под веб. Есть много новых языков, которые очень быстро растут, например, Scala и другие. Но пока они довольно молодые и сырые. Я бы не рекомендовал бежать за модой и писать на них, пока они не разовьются во что-то большее.
Примеры больших сайтов:
Эти примеры отлично показывают, что большие сайты могут быть созданы на разных языках, и это нормально. Опять же, приходим к тому, что выбирать технологию нужно под требования, руководствуясь объективными причинами.
Это некая среда разработки для программистов, где есть готовая инфраструктура и ряд готовых функций со стандартными решениями типичных задач. Такой себе полуфабрикат, из которого можно сделать конфетку. На каждом языке есть много разных фреймворков. Есть как общие, которые создавались для разработки любых решений, так и специализированных, под узкие задачи. Например, Sylius — специализированный E-commerce фреймворк на основе Symfony.
На фреймворках разрабатываются довольно большие и сложные сайты с уникальным функционалом. Это значительно быстрее и дешевле, чем на чистом языке, но при этом такое решение позволяет разрабатывать действительно сложные вещи и оптимизировать все это под нагрузки.
Кроме того, это почти всегда более безопасно, чем любая коробочная CMS.
Популярные фреймворки и платформы:
Больше всего фреймворков на PHP и на этом языке есть из чего выбирать, но действительно функциональных не так много. Меньше на других языках, а на некоторых действительно качественных фреймворков, вообще, один, как у языка Ruby. У Java очень много разных фреймворков для разных целей, и не только для сайтов. Все они ежегодно развиваются, выходят все новые и новые версии, одни обгоняют другие.
Например, Laravel только в последние несколько лет вышел на первое место по популярности, хотя самые сложные сайты до сих пор делаются на Symfony. А .NET и Node.js — это целые самостоятельные платформы, которые базируются на определенных языках, но имеют очень широкие возможности.
Это готовое программное обеспечение, которое нужно только настроить, реже — дописать или переписать какую-то из частей. Таких решений очень много на любом языке, но исторически так сложилось, что в основном все популярные CMS сделаны на PHP. Тут дело в развитие языков, раньше простые сайты, для которых и создавались CMS, писались на PHP.
Я еще застал те времена, когда CMS почти не было, были скрипты — отдельные готовые части разных сайтов. Позже эти скрипты собирали в коробочный продукт, который был призван решить потребности 90% простых сайтов. Так и получилось, что основные CMS сделаны на PHP. Сегодня CMS на других языках развиваются слабо, потому, что уже есть сильные конкуренты на PHP, а простому сайту язык не играет большой роли, поэтому все смотрят на возможности этих готовых продуктов.
CMF — если говорить простым языком, это что-то среднее между CMS и фреймворком по возможностям. Обычно CMF используют для самых сложных сайтов из этой категории. Этот подход позволяет избавится от лишних частей CMS, которые не нужны конкретному проекту.
CMS бывают разные по назначению: общие, для интернет-магазинов, блогов и так далее. Разные по условиям использования: платные и бесплатные. Для каждой популярной CMS есть куча разных платных и бесплатных модулей, которые легко подключать и использовать.
Небольшие сайты, которые в основном нужны для малого бизнеса, почти всегда используют CMS. Это позволяет очень сильно экономить время на разработку.
Именно в работе с CMS возникает больше всего непонимание среди конечных заказчиков таких решений. Любая CMS — это тонны готового программного кода, на все случае жизни. В коробочной поставке идут десятки и сотни модулей. Все это очень сильно ограничивает специалистов. Такие решения сильно тормозят, они негибкие, их очень легко взломать, особенно бесплатные CMS.
Еще часто взламывают CMS через модули сторонних разработчиков, в которых есть критические уязвимости, потому что мы никогда не знаем, какого уровня программист писал тот или иной модуль. То есть любая CMS не рассчитана для большого и сложного сайта. Она не могут выдержать большие нагрузки. Это решение не безопасно, чтобы не говорили разработчики конкретной CMS.
Я видел решения почти на всех популярных CMS. С многими за 10 лет работы пришлось поработать лично. Часть из них популярна в рунете, а часть знают в основном на западе. На используемые в них языки CMS разбивать нет смысла, по причинам, описанным выше.
Лучше сказать несколько слов про каждую популярную CMS:
Со всеми перечисленными CMS я работал. В основном со стороны разработчика. Точно НЕ рекомендую Joomla, с остальными можно работать.
Для магазинов лучше выбирать специализированные, а не общие CMS. Кроме 1С-Битрикс в рунете есть еще аналогичные коммерческие CMS, они во многом схожи. У каждой из систем есть свои особенности, но все они не предназначены для больших и сложных проектов, главное это не забывать.
В последние 5 лет очень активно развивают шаблонные решения. Это еще на одну ступеньку выше, чем CMS. Если CMS — это конструктор и его нужно настраивать, то шаблоны — это уже готовые решения под типовые случаи. Например, в каждом городе есть свои рестораны, такси, клиники. Для всех этих типов малого бизнеса нужно примерно одно и то же. Поэтому можно просто выбрать готовый тематический шаблон, заменить в нем логотип, цвета и контент. При желании такие шаблоны можно дорабатывать по усмотрению владельца.
Преимущества таких решений в том, что они очень дешевые и их можно запускать моментально. Но при этом такие решения не учитывают особенностей бизнеса и конверсия будет не очень высокой.
Есть специальные каталоги шаблонов: TemplateMonster, ThemeForest и др. Часто встречаются онлайн-конструкторы, в том числе тематические: Wix, PageCloud и др.
В мобильных приложениях в последнее время используется два подхода: нативная разработка и кроссплатформенные технологии.
Нативная ведется на оригинальных языках программирования, например, Swift (для iOS, ранее был Objective-C) и Java (для Android). Кроссплатформенных технологий сейчас довольно много, они есть на базе разных языков программирования, в частности: Apache Cordova, React Native и др. Некоторые лучше, некоторые хуже.
В любом случае сложные приложения всегда пишутся на нативных технологиях. С кроссплатформой часто возникают проблемы, вплоть до того, что некоторые функции просто нереализуемы на тех или иных технологиях, сильно грузится оперативная память устройства, быстро садится батарея и так далее.
В этих двух подходах люди тоже часто путаются, пытаясь использовать кроссплатформенные подходы на все случаи жизни. Оно и понятно, ведь кроссплатформа позволяет писать код один раз, который сразу работает и на iOS и на Android, в то время, как на нативных технологиях это минимум в два раза дороже выходит. Однако мало кто знает про возможные дальнейшие проблемы в разработке.
Я бы рекомендовал очень тщательно выбирать технологии и кроссплатформу брать только для простых приложений, иначе придется переписывать. Впрочем, кроссплатформенные технологии постепенно развиваются и становятся все лучше, а приложения, написанные на них все сложнее.
Выше я описал разные языки и фреймворки, которые используются в больших проектах, однако, если присмотреться к действительно большим проектам, там можно найти целый комплекс языков и технологий. Почти все большие сайты используются в основе один язык и еще несколько дополнительных. То же самое с базами данных: для одних задач могут использоваться реляционные, а для других нереляционные базы, и все это органично сочетается в рамках одного проекта.
Выбор технологий зависит от предлагаемой архитектуры проекта. Именно архитектор продумывает основные блоки будущего сайта. Какой язык ляжет в основу, будет ли он нативный или фреймворк, какую систему кэширования выбрать, какие базы данных, как все это связано.
Для примера рассмотрим технологии Instagram (данные Insight IT):
И это вполне нормальный стек технологий. Сам Instagram не самый большой и сложный сервис в мире.
Один из важнейших факторов выбора технологии является стоимость и доступность специалистов, потому что именно это самая затратная часть. В рунете есть только одна пузомерка по зарплатам: https://jobs.dou.ua/salaries/ я отфильтровал по Киеву, уровень Senior, опыт 3–5 лет. Сравним средние значения.
Зарплаты:
В США немного другая картина:
Теперь переведем цифры на человеческий язык. Java хоть и не новый язык, но специалисты на ней всегда были одними из самых дорогих. PHP всегда был самым дешевым, да и специалистов на рынке очень много. В сравнении я внес еще и Scala как один из новейших и трендовых языков, по этой причине он дороже всех. Еще дорогой JS, это связано с его бурным ростом в последние годы и растущей популярностью Node.js, а также AngularJS.
Таким образом, если мы хотим экономить – то лучше смотреть на PHP, специалисты дешевые, а комьюнити большое. А если хотим самое качественное – то смотрим на Scala, который называют будущем веб-разработки, но, правда, на ней найти специалистов почти невозможно и наработок просто нет.
Еще одним важным параметром будет скорость разработки. Ведь важна не только зарплата программистов, но и скорость разработки. Если не учитывать уже существующие наработки, то одним из самых быстрых в разработке будет Python и Ruby, а самый медленный — Java. Кстати, по этой причине за последние 10 лет почти не вышло новых мегапроектов на Java, зато вышло много проектов на Python, о чем я расскажу ниже.
Выбирая технологию, нам нужно смотреть вперед. Особенно если речь о большом проекте. Все технологии очень быстро развиваются, выходят все новые и новые версии. Языки сильно меняются каждые 5–7 лет, фреймворки — каждые 2–3 года, а CMS — каждые 1–2 года. Важно выбрать не просто хорошую технологию сегодня, а предугадать тренды развития так, чтобы остаться на коне через несколько лет. Иначе в конечном счете придется переписывать проект, что всегда очень проблематично.
Есть всевозможные исследования, которые нам могут подсказать некоторые статистические выкладки. Например, исследование TIOBE Index показывает интересную статистику:
По результатам разных исследований можно выделить явных лидеров по росту — это JS (версия ES6 и выше) и мультипарадигмальные языки, например, Scala. Кстати, именно Scala считается преемником языка Java и во многом на него похож. Также не плохо себя показывает Python.
Антитренды держат ряд старых языков и PHP. Правда, недавно вышла седьмая версия PHP, в которой исправлены многие серьезные недостатки. Так что, я думаю, мы скоро увидим новый виток развития PHP. Еще многие большие проекты переписываются с Ruby на другие языки, тоже некий антитренд.
Для иллюстрации посмотрим, каких специалистов не хватает в США:
Именно это можно считать реальной картиной трендов, которые мы видим и у нас.
На чем делались большие проекты за последние 10 лет?
Это уже не теоретическая статистика, а реальная практика. Python и JS очень хорошо себя показывают.
Безусловно, важный критерий выбора технологии — это стоимость поддержки, о которой мало кто задумывается в начале разработки. Обычно все мыслят категориями стоимости часа поддержки, что в корне неправильно. Нам важны несколько параметров: стоимость часа, количество часов, официальная поддержка технологии, доступность специалистов, правильный подход к разработке и некоторые другие.
Стоимость часа зависит от зарплаты специалиста, с этим мы уже разобрались. А вот количество часов зависит от самой технологии и качества написания кода. Если решение коробочное, то часов на него может уходить очень много.
То есть, с одной стороны, мы можем сэкономить при разработке первой версии проекта, но, с другой, после погрязнем в его постоянной доработке. Хорошо, когда решение популярное и есть официальная документация, но часто выбирают малоизвестные коробочные решения без какой-либо документации — в таких решениям стоимость поддержки будет во много раз выше стоимости самой коробки.
То же касается некачественной разработки: у нас почему-то полностью отсутствует культура проведения технических аудитов готовых решений или его частей. В среднем за 20–40 часов можно проверить почти любое решение и найти его основные минусы. Чем более качественный код, тем легче, а следовательно, и дешевле его поддерживать.
Также следует смотреть на версию языка, фреймворка, CMS. Нужно всегда использовать самую последнюю стабильную версию, чтобы она не устарела до выхода проекта в продакшн. При появлении новой версии, нужно сразу рассматривать возможность перевода проекта на эту версию. Потому что, если пропустить несколько версий, потом будут проблемы сделать резкое обновление.
Подведем итог. Для простых сайтов чаще всего отлично подходят коробочные решения и шаблоны. Сложные сайты делаются только на фреймворках или даже чистых языках программирования. Делать можно на очень разных языках, язык выбирается под проект. Простые мобильные приложения можно делать на кроссплатформенных технологиях, а сложные обычно делаются на родных технологиях. Ну и, выбирая платформу, всегда стоит руководствоваться объективными критериями, которые я описал в статье.
Источник: Rusbase
Не секрет, что ежегодно водители должны обновлять свою автостраховку и покупать новый полис, защищающий их…
Кредит готівкою — один з банківських продуктів, який має високий попит серед населення. Він передбачає…
Мир трейдинга часто представляется новичкам как захватывающее приключение с возможностью быстрого обогащения. Однако реальность может…
Відповідно до п. 6 Порядку заповнення податкової накладної, затвердженого наказом Міністерства фінансів України від 31.12.2015 №…
Одеська ДПС надала відповіді на запитання щодо формування стандартного аудиторського файлу (SAF-T UA). 1. Яким чином визначати…
У разі здійснення операцій з постачання товарів у рахунок оплати праці працівників у рядку «Індивідуальний…