Но прежде, чем что-то выбирать, давайте посмотрим, какие технологии бывают, чем они отличаются и в каких случаях какую технологию выбрать.
Как чаще всего выбирают технологию сейчас:
- Она мне нравится
- Знакомый посоветовал
- Прочитал в Интернете
- На этой технологии сделан аналогичный сайт
В чем тут проблема:
- Нравится. Очень субъективно. А что, если по требованиям она не подходит? Или на ней работают очень дорогие и редкие специалисты? Или она вообще умирает?
- Знакомый. Обычно это тот знакомый, который «чуть лучше» разбирается в ИТ, чем тот, кому он советует. И даже если он программист с опытом, он не может знать всех решений на всех популярных языках. Ведь никто не спрашивает, по каким критериям выбирал этот знакомый. Если этот знакомый не CTO Google, я бы так просто не доверял такой рекомендации.
- Прочитал. Тут уже лучше: можно найти разные сравнения и аргументацию. Но опять же, чтобы разобраться во всех решениях человеку, пусть даже с крепкими знаниями в разработке, нужно время. А без знаний в разработке все прочитанные технические обзоры ничего не стоят.
- Аналог. Большинство популярных сайтов написаны на тех или иных технологиях, потому что так «исторически сложилось». Если бы Facebook сейчас выбирал технологию для себя, я сомневаюсь, что он взял бы за основу PHP. А еще может быть, что технология уже устарела, её продавили на основе прошлых 3-х пунктов, выбрали какую-то разрекламированную технологию, а не действительно эффективную и т.д. Вы вряд ли можете знать реальные причины выбор технологий в других проектах. Оптимальные технологии используются крайне редко в аналогичных проектах.
Таким образом, ни один из вышеперечисленных методов выбора технологий разработки не отвечает критериям объективности. Поэтому стоит сначала определить эти критерии, а уже потом подбирать по ним техническую платформу. Ниже я попытаюсь выделить действительно важные для проекта критерии, на которым мы и будем основываться.
Важные критерии при выборе технологий:
- Размер и тип проекта
- Сложность проекта
- Скорость разработки
- Стоимость специалистов
- Доступность специалистов
- Доступные инструменты разработки
- Наличие готовых решений
- Гибкость решения
- Наличие широкого сообщества
- Отказоустойчивость решения
- Тренд его развития
- Наличие подробной документации
- Стоимость поддержки
- Требования к нагрузкам
- Требования к безопасности
- Кроссплатформенность
- Возможности интеграции с другими решениями
Выбирая технологию по таким критериям, мы сможем добиться объективного выбора и тем самым сэкономить себе время и деньги.
Какие бывают проекты
К технологиям мы еще вернемся, а пока давайте разберемся, какие бывают проекты. Часто тип проекта говорит сам за себя, и можно сразу сказать, что подойдет: либо уже готовое решение, либо хотя бы в какую сторону нужно двигаться.
По сложности проекты делятся:
- Простые (визитки, лендинги, простые интернет-магазины, простые приложения) — такие решения обычно делаются на тематических коробочных решениях, CMS или шаблонах.
- Средние (сложные интернет-магазины и маркетплейсы, порталы национального масштаба, разнообразные сервисы, продвинутые приложения) — такие решения обычно делаются на фреимворках.
- Сложные (огромные порталы, социальные сети, инновационные и нетиповые решения) — ядро таких проектов обычно разрабатывается на чистом (нативном) языке программирования.
По тематике: интернет-магазины, доски объявлений, социальные сети и т.д. Для большинства популярных тематических решений уже давно есть коробочные продукты, и, если мы не пытаемся сделать какого-то монстра, то правильнее будет выбрать именно их. Решений очень много, все в одной статье описать невозможно.
Языки программирования
В технологиях я бы выделил 3 уровня абстракции:
- Чистый язык — это материал, из которого можно сделать все, что угодно. Ограничивают нас только возможности языка. На чистом языке сделаны все крупнейшие сайты мира с посещаемостью в сотни миллионов и миллиардов пользователей, такие как: Instagram, YouTube, Pinterest, Tumblr, Dropbox, Twitter, Facebook, Amazon, Digg, LinkedIn и другие. Более того, крупнейшие проекты в мире даже создают новые технологии для себя, так как уже существующие их не устраивают.
- Фреимворк — это некая среда разработки для программиста с готовыми правилами и инструментами. Фреимворк, с одной стороны, помогает и ускоряет разработку, а с другой, накладывает определенные ограничения. На фреимворках делаются проекты средней сложности с посещаемостью в миллионы.
- CMS — это уже готовое решение, конструктор, в котором мы по частям собираем нужный проект. Его скорее не программируют, а настраивают. Ограничений тут огромное количество, выйти за границы коробки сложно и неэффективно. На CMS делаются простые сайты с посещаемостью до миллиона пользователей в месяц.
Чаще всего один уровень абстракции базируется на другом. То есть на чистом языке делают фреимворки, а на фреимворках делают CMS. Для каждого популярного языка есть много разных фреимворков и CMS, но об этом позже.
Сегодня есть огромное количество разных языков программирования, на которых делают сайты. И, более того, на всех популярных языках есть примеры огромных сайтов. Если 10 лет назад, говоря о технологиях больших сайтов, все говорили преимущественно о Java, то сегодня это может быть почти любой язык, и утверждать, что сайты делаются на каком-то конкретном языке, — стереотип. Это связанно с развитием самих языков, за последнее десятилетие многие сильно продвинулись в развитии и получили широкие возможности. Конечно, каждый язык чем-то отличается, и выбирая мы опять же должны руководствоваться объективными критериями с оглядкой на задачи проекта.
На чистом языке, без использования фреимворков и коробочных решений, пишутся огромные проекты с повышенными требованиями по гибкости, нагрузкам и безопасности. Для таких огромных проектов часто бюджет не играет такого значения, как эффективность. Чем больше проект, тем больше будет требований по гибкости и нагрузкам, а значит, проще писать все с нуля, выделяя на это лучших специалистов, чем если брать какие-то готовые решения, которые непонятно кем писались и непонятно какие проблемы в них скрыты. К примеру, когда речь о небольшом проекте с посещаемостью в 10 тыс. человек в день, то нам будет дешевле сделать его на CMS, которая будет потреблять в 3 раза больше ресурсов сервера, поставить дополнительный сервер за 50$ / мес., и он будет работать. Когда же мы говорим о сайте с посещаемостью в 100 млн. пользователей в день, стоимость добавления серверов у нас будет просто космической, поэтому нам проще и дешевле вложить деньги в разработку решения на чистом языке, которое будет оптимальным именно для конкретного проекта.
Чем больше проект, тем больше стек технологий, который в нем используется. В огромных порталах может использоваться сразу несколько языков программирования. Опять же, мы приходим к объективным критериям выбора технологий. Часто один язык может хорошо решать одну задачу, а другой — другую. Такие проекты могут быть настолько огромными, что их части могут работать на разных серверах, с разными доменами (поддоменами) и разными технологиями. Не следует бояться винегрета технологий в большом проекте, хотя и допускать его нужно только, когда это действительно необходимо, а также помнить, что далеко не все технологии совместимы. Самый яркий пример использования разных технологий — Google. Он на столько большой, чтобы разные его части написаны на C/C++, Java, Python, JS и других языках. Более того, Google активно создает новые технологии, как, например, популярный нынче AngularJS.
Попробую дать краткую характеристику каждому из популярных языков:
- PHP — его используют в основном для простых и средних проектов. Очень много коробочных решений. Относительно дешевые программисты. Антитренд последних лет, хотя с выходом последней версии языка под номером 7, он получил действительно мощные возможности.
- Python — современный язык, разработка на нем быстрая и качественная. Используют его для средних и больших проектов. Программистов найти проблематично, и стоят они не дешево.
- Ruby — современный язык, разработка на нем также быстрая. Его используют в основном для разработки простых и средних проектов, часто разрабатывают стартапы. Программистов также мало, и они дорогие.
- Java — разработка на нем очень долгая и дорогая. Его используют в основном для больших проектов со специфическими требованиями.
- C# — аналог Java, также используют для больших проектов, часть в сфере FinTech.
- JS — очень быстро развивается, тренд последних лет. Огромное количество наработок, и можно писать все, что угодно, даже игры. Его используют для средних и больших проектов, но действительно мощные возможности этот язык получил недавно, потому примеров больших проектов пока мало, специалисты самые дорогие, и найти их сложнее всего.
Я описал самые популярные языки, которые сегодня используются под веб. Есть много новых языков, которые очень быстро растут, в частности Scala и некоторые другие. Но пока они довольно молодые и сырые. Я бы не рекомендовал бежать за модой и писать на них, пока они не разовьются во что-то большее.
Примеры больших сайтов:
- PHP: Facebook, Вконтакте, КиноПоиск
- Python: Instagram, Pinterest, Reddit
- Ruby: 500px, Groupon, Airbnb
- Java: Ebay, Amazon, Alibaba
- C#: Guru, Stack Overflow, Bank of America
- JS: LinkedIn, Walmart, PayPal
Эти примеры отлично показывают, что большие сайты могут быть на разных языках, и это нормально. Опять же, приходим к тому, что выбирать технологию нужно под требования, руководствуясь объективными причинами.
Фреймворки и платформы
Это некая среда разработки для программистов, где есть готовая инфраструктура и ряд готовых функций со стандартными решениями типичных задач. Такой себе полуфабрикат, из которого можно сделать конфетку. На каждом языке есть много разных фреймворков. Есть как общие, которые создавались для разработки любых решений, так и специализированные, под узкие задачи. Например, Sylius — специализированный E-commerce фреймворк на основе Symfony. Также есть те, на которых делаются большие и сложные решения, а другие для этого не предназначены. Ниже я опишу популярные фреймворки для каждого из языков, на которых можно писать большие и сложные решения.
На фреймворках разрабатываются довольно большие и сложные сайты с уникальным функционалом. Это значительно быстрее и дешевле, чем на чистом языке, но при этом такое решение позволяет разрабатывать действительно сложные вещи и оптимизировать все это под нагрузки. Кроме того, это почти всегда более безопасно, чем любая коробочная CMS.
Популярные фреймворки и платформы:
- PHP: Symfony, Laravel
- Python: Django
- Ruby: Ruby On Rails
- Java: Spring
- C#: .NET
- JS: Node.js, AngularJS
Больше всего фреймворков на PHP, и на этом языке есть, из чего выбирать, но действительно функциональных не так много. Меньше на других языках, а на некоторых действительно качественных фреймворков вообще всего один, как у языка Ruby. У Java очень много разных фреймворков для разных целей, и не только для сайтов. Все эти фреймворки ежегодно развиваются, выходят все новые и новые версии, одни фреймворки обгоняют другие. Например, Laravel только в последние несколько лет вышел на первое место по популярности, хотя самые сложные сайты до сих пор делаются на Symfony.
.NET и Node.js — это целые самостоятельные платформы, которые базируются на определенных языках, но имеют очень широкие возможности.
Недавно мы проводили исследования по тем фреймворкам, на которых специализируемся. Смотрели в каких больших проектах они используются. В частности огромные сайты на Python / Django и огромные сайты на PHP / Symfony. Также мы писали, как мы разрабатывали социальную сеть на Symfony вместе с API (статья больше про API, самое широкое описание в рунете по этой теме). Такие же огромные сайты есть на каждом из перечисленных фреймворках.
CMS и CMF
Это готовое программное обеспечение, которое нужно только настроить, реже — дописать / переписать какую-то из частей. Таких решений очень много на любом языке, но исторически так сложилось, что в основном все популярные 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:
- WordPress — некогда блоговый движек, сейчас на ней делаются почти любые сайты, включая магазины. Одна из самых популярных CMS в мире, есть примеры довольно посещаемых сайтов. На ней часто делают информационные сайты, в том числе разные СМИ. Система бесплатная.
- Joomla! — CMS общего назначения. Качеством особо не отличается, на ней делают очень маленькие сайты, и обычно дешевле всех других вариантов, так как именно с этой CMS начинают учиться многие начинающие программисты. Система бесплатная.
- Drupal — это уже CMF для общего назначения, с недавнего времени поставляется со встроенных фреймворком Symfony. Довольно мощная, на ней есть известные сайты, например, официальный сайт Белого Дома. Система бесплатная.
- Magento — самая популярная система управления для интернет-магазинов в мире. Довольно мощная и сложная. В рунете используется редко, в основном на западе.
- PrestaShop — одна из самых популярных CMS для магазинов в мире. Тоже довольно мощная, используют в основном на западе. Система бесплатная.
- OpenCart — еще одна популярная система для интернет-магазинов, но её, наоборот, больше используют в рунете, чем на западе. В основном для маленьких и несложных магазинов. Система бесплатная.
- 1С-Битрикс — очень распиаренная CMS общего назначения, номер 1 в рунете. Возможности очень широкие. На ней часто пытаются делать большие и сложные сайты, а после определенного порога в посещаемости переписывают их на других технологиях. Многие считают, что только эта CMS может интегрироваться с 1С, что не является правдой, поскольку все перечисленные CMS из этого списка могут интегрироваться с 1С, для этого у всех CMS есть специальные модули. Система платная.
Со всеми перечисленными CMS я работал. В основном со стороны разработчика. Точно НЕ рекомендую — Joomla, с остальными можно работать. Для магазинов лучше выбирать специализированные, а не общие CMS. Кроме 1С-Битрикс в рунете есть еще аналогичные коммерческие CMS, они во многом схожи. У каждой из систем есть свои особенности, но все они не предназначены для больших и сложных проектов, главное это не забывать.
Ранее, мы проводили исследования, на каких CMS сделаны самые посещаемые сайты рунета: часть 1 и часть 2, крупнейшие интернет-магазины и крупнейшие сайты банков. Эти исследования подтверждают описанные выводы в статье.
Шаблоны
В последние 5 лет очень активно развивают шаблонные решения. Это еще на одну ступеньку выше, чем CMS. Если CMS — это конструктор, и его нужно настраивать, то шаблоны — это уже готовые решения под типовые случаи. Например, в каждом городе есть свои рестораны, такси, клиники и т.д. Для всех этих типов малого бизнеса нужно примерно одно и тоже. Поэтому, можно просто выбрать готовый тематический шаблон, заменить в нем логотип, цвета и контент. При желании такие шаблоны можно дорабатывать по усмотрению владельца.
Преимущества таких решений в том, что они очень дешевые и их можно запускать моментально. Но при этом такие решения не учитывают особенностей бизнеса и конверсия будет не очень высокой.
Есть специальные каталоги шаблонов: TemplateMonster, ThemeForest и др. Часто встречаются онлайн-конструкторы, в том числе тематические: Wix, PageCloud и др.
Мобильные приложения
В мобильных приложениях в последнее время используется два подхода: нативная разработка и кроссплатформенные технологии. Нативная ведется на оригинальных языках программирования, в частности Swift (для iOS, ранее был Objective-C) и Java (для Android). Кроссплатформенных технологий сейчас довольно много, они есть на базе разных языков программирования, в частности: Apache Cordova, React Native и др. Некоторые лучше, некоторые хуже. В любом случае, сложные приложения всегда пишутся на нативных технологиях. С кроссплатформой часто возникают проблемы, вплоть до того, что некоторые функции просто нереализуемы на тех или иных кроссплатформенных технологиях, сильно грузится оперативная память устройства, быстро садится батарея и т.д.
В этих двух подходах люди тоже часто путаются, пытаясь использовать кроссплатформенные технологии на все случаи жизни. Оно и понятно, ведь кроссплатформа позволяет писать код один раз, который сразу работает и на iOS, и на Android, в то время, как на нативных технологиях это выходит минимум в два раза дороже. Однако мало кто знает о возможных дальнейших проблемах в разработке. Я бы рекомендовал очень тщательно выбирать технологии, и кроссплатформу брать только для простых приложений, иначе придется переписывать. Впрочем, кроссплатформенные технологии постепенно развиваются и становятся все лучше, а приложения, написанные на них, все сложнее.
Стек технологий в больших проектах
Выше я описал разные языки и фреймворки, которые используются в больших проектах, однако, если присмотреться к действительно большим проектам, там можно найти целый комплекс языков и технологий. Почти все большие сайты используют один основной язык и несколько дополнительных. Тоже самое с базами данных: для одних задач могут использоваться реляционные, а для других нереляционные базы. И все это органично сочетается в рамках одного проекта.
Выбор технологий зависит от предлагаемой архитектуры проекта. Именно архитектор продумывает основные блоки будущего сайта. Какой язык ляжет к основу, будет ли он нативным или фреймворк, какую систему кэширования выбрать, какие базы данных, как все это будет связано и т.д.
Для примера рассмотрим технологии Instagram (данные Insight IT):
- Ubuntu Server 14.04 LTS — основная серверная операционная система
- Python — основной язык программирования серверной части
- Django — фреймворк
- nginx — второй уровень балансировки входящих HTTP-запросов
- gunicorn — WSGI-сервер
- HAProxy — балансировка нагрузки внутри системы
- PostgreSQL — основное хранилище данных
- postgis — поддержка гео-запросов
- pgfouine — отчеты на основе логов
- pgbouncer — создание пула соединений
- Redis — дополнительное хранилище данных
- Memcached — кэширование
- Gearman — очередь задач
- Solr — гео-поиск
- munin, statsd, pingdom — мониторинг
- Fabric — управление кластером
- xfs — файловая система
И это вполне нормальный стек технологий. Сам Instagram не самый большой и сложный сервис в мире.
Стоимость специалистов
Один из важнейших факторов выбора технологии является стоимость и доступность специалистов, потому что именно это — самая затратная часть в любом проекте. В рунете есть только одна пузомерка по зарплатам: https://jobs.dou.ua/salaries/ — я отфильтровал по Киеву, уровень Senior, опыт 3-5 лет. Сравним средние значения.
Зарплаты:
- C# – 3072$
- Java – 3300$
- JS – 3500$
- PHP – 2780$
- Python – 3000$
- Ruby – 3000$
- Scala – 3900$
В США немного другая картина:
Теперь переведем цифры на человеческий язык. 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. Правда, недавно вышла 7я версия PHP, в которой исправлены многие серьезные недостатки. Так что, я думаю, мы скоро увидим новый виток развития PHP. Также многие большие проекты переписываются с Ruby на другие языки, тоже некий антитренд.
Для иллюстрации посмотрим, каких специалистов не хватает в США:
Именно это можно считать реальной картиной трендов, которые мы видим и у нас.
На чем делались большие проекты за последние 10 лет?
- Airbnb – Ruby
- Instagram – Python
- Pinterest – Python
- Foursquare – Python
- Groupon – Ruby -> JS
- Twitter – Ruby -> Scala
- Uber – JS
Это уже не теоретическая статистика, а реальная практика. Python и JS очень хорошо себя показывают.
Стоимость поддержки
Безусловно, важный критерий выбора технологии — это стоимость поддержки, о которой мало кто задумывается в начале разработки. Обычно все мыслят категориями стоимости часа поддержки, что в корне неправильно. Нам важны несколько параметров: стоимость часа, количество часов, официальная поддержка технологии, доступность специалистов, правильный подход к разработке и некоторые другие.
Стоимость часа зависит от зарплаты специалисты, с этим мы уже разобрались. А вот количество часов зависит от самой технологии и качества написания кода. Если решение коробочное, то часов на него может уходить очень много. То есть, с одной стороны, мы можем сэкономить при разработке первой версии проекта, но после погрязнуть в его постоянной доработке. Хорошо, когда решение популярное, и есть официальная документация. Но часто выбирают малоизвестные коробочные решения без какой-либо документации — в таких решениям стоимость поддержки будет во много раз выше стоимости самой коробки. То же касается некачественной разработки: у нас почему-то полностью отсутствует культура проведения технических аудитов готовых решений или их частей. В среднем за 20-40 часов можно проверить почти любое решение и найти его основные минусы. Чем более качественный код, тем легче, а следовательно, и дешевле его поддерживать.
Также следует смотреть на версию языка, фреимворка, CMS. Нужно всегда использовать самую последнюю стабильную версию, чтобы она не устарела до выхода проекта в продакшн. При появлении новой версии нужно сразу рассматривать возможность перевода проекта на эту версию. Потому что, если пропустить несколько версий, потом будет проблемно сделать резкое обновление.
Так что выбрать?
Подведем итог. Для простых сайтов чаще всего отлично подходят коробочные решения и шаблоны. Сложные сайты делаются только на фреимворках или даже чистых языках программирования. Делать можно на очень разных языках, язык выбирается под проект. Простые мобильные приложения можно делать на кроссплатформенных технологиях, а сложные обычно делаются на родных технологиях. Ну и, выбирая платформу, всегда стоит руководствоваться объективными критериями, которые я описал в статье.
Ниже я сделал опрос по предпочтительному языку программирования для большого проекта. Подразумевается уровень проектов с посещаемостью в 100 млн. пользователей и больше. Если у вас есть опыт разработки больших проектов, хотя бы на несколько миллионов пользователей, прошу не просто проголосовать, но и обосновать свое мнение в комментариях, так как у каждого разные опыт и предпочтения. Разбавим некоторую долю субъективизма статьи мнениями других членов сообщества :)
P.S.. В нашей школе есть несколько интересных курсов по программированию. Чтобы записаться пишите на info@digitov.com
P.P.S. Чтобы получать наши новые статьи раньше других или просто не пропустить новые публикации — подписывайтесь на нас в Facebook, VK и Twitter.
Автор:
Никита Семенов, CEO, Компания «SECL Group»
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (65)
zodiak
21.11.2016 13:30+4Очень уж странным выглядит призыв писать большие проекты на чистом языке без фреймворков. Учитывая какой «дырявый» с точки зрения безопасности WEB (а фреймворки решают хотя бы базовые проблемы безопасности), такой призыв выглядит крайне странно.
SECL
21.11.2016 13:37Я не призывал) Я писал, что так часто делают ;) Дыры есть везде, в фреймворках тоже. Если делать огромный ресурс, то можно купить лучших специалистов в мире и учесть все «дыры». Любой фреймворк — это рамки и ограничения, а любому огромному ресурсу они не нужны. Сейчас еще добавлю в статью ссылки на наших исследования по фреймворкам, которые показывают примеры больших проектов на нескольких популярных фреймах…
saggid
28.11.2016 01:02+1Почему вы считаете фреймворк рамками и ограничениями? Вот это только я понять не могу, если честно. К примеру, если мы будем смотреть на Laravel — то на его основе можно написать абсолютно любое приложение, какие ограничения могут подразумеваться в этом случае? То что мы классы используем вместо простых функций чтоли?) Впрочем, даже на основе функций код можно вполне писать прямо внутри Laravel, я даже пост об этом писал недавно на хабре, который правда заминусовали. Или есть что-то более серьёзное из доводов?
Просто честно, мне кажется довольно странным только этот довод из всей вашей статьи. Если смотреть на Laravel, то это прекрасная основа для написания любого мыслимого проекта. Вся конструкция Laravel выглядит как очень гибкий набор мягко связанных друг с другом компонентов, использующих, к тому же, в большинстве ситуаций контракты для взаимодействия между друг другом. Всё это позволяет заменить, при желании, практически любую подсистему вашего проекта.
К примеру, вы захотели реализовать свою проприетарную систему кеширования. Нет проблем: напишите класс для связи с вашей системой, удовлетворяющий контракту кеш-подсистемы laravel — и используйте его. Об этом и глава отдельная в официальной документации имеется. И так со всеми подсистемами. Вы можете заменить практически всё что угодно.
Мы сейчас работаем над проектом, в котором мы решили использовать шаблонизатор pug. Ничего особенно сложного. Gulp компилирует шаблоны в php файлы, понятные laravel.
Мы захотели разбить весь наш проект на отдельные модули, и хранить контент каждого модуля в отдельной папке. Снова никаких ограничений фреймворк нам не доставил, благо в нём есть такие прекрасные штуки как сервис провайдеры и возможность указать место хранения других шаблонов.
В общем, если честно, то ваше мнение в этом плане, на мой взгляд, довольно субьективное, и оно не отражает реальную ситуацию с фреймворками на нынешний пред-2017-й год. Фреймворки стали более гибкими сегодня. Раньше было примерно так, как вы пишете, это я согласен.
Плюс, конечно, есть ещё такая тонкость, что мой личный опыт довольно узкий. Такой уж я человек: я больше стараюсь углубиться в изучение какой-то конкретной области, чем бегать туда-сюда между различными технологиями. В силу этого, я больше знаю PHP, Кохану и Laravel, и очень мало знаю об остальных фреймворках этого мира. Вполне возможно, что то, что вы говорите, является истиной по отношению к другим фреймворкам. Но и Кохана, кстати, в своё время предоставляла возможность довольно легко расширять и переписывать всю основную логику фреймворка без всякого затрагивания основной системной папки благодаря идее прозрачного расширения классов. Чем я также неоднократно с большим удовольствием пользовался во времена расцвета этого фреймворка)
MikhailMKZ
21.11.2016 14:27+1Почему Go (Golang) не рассматривается как вариант?
SECL
21.11.2016 14:27+1Довольно новый и небольшое сообщество. Не стал его рассматривать. Но со временем все может быть.
MikhailMKZ
21.11.2016 14:40+1Думаю, что у него должно быть большое будущее. Компилируемый, со статической типизацией и относительно простой.
vjjvr
28.11.2016 16:00+2> Довольно новый и небольшое сообщество. Не стал его рассматривать. Но со временем все может быть.
Автор, напишите честно — потому что у вас нет опыта работы с большими проектами, даже рядом не проходили.
Ваше заявление про Go выглядет особенно странно в контексте «Выбор технологий для большого и не очень большого веб-проекта»,
где как раз у Go одни из ведущих позиций
;)
С компетентностью автора все понятно —
в качестве перспективных систем под большой проект он рассматривает CMS.
CMS, Карл!!!
Под большой проект!!!
При этом микросервисы, которые являются нормой для больших проектов — даже не упомянуты.
Видимо, 11-летний опыт автора — это в основном хоумпеджи небольших фирмочек.
А большим он называет проект больше, чем 6 человеко-месяцев.SECL
01.12.2016 16:14+1Друг мой, найди хоть одну фразу в статье, где я рекомендовал CMS для большого проекта? Ты не читал статью, просто пролистал, увидел слово CMS и сделал какие-то выводы. CMS я рекомендовал для МАЛЕНЬКИХ проектов. Еще там есть слово «шаблон», странно, что ты про него не вспомнил.
Если хочешь критиковать, сначала прочитай, а потом пиши комментарии и обоснование к нему.
Впрочем, твой заминусованный рейтинг на Хабре отлично иллюстрируют твой профессиональный уровень. Сообщество его уже оценило)
MOTORIST
21.11.2016 18:50Поддержу Go, для крупных проектов идеально подходит. Не зря Mail и Яндекс его активно внедряют. Много плюсов, а главное простой.
ensom
21.11.2016 14:28+1Несмотря на мое положительное отношение к последним версиям PHP, мне кажется весьма странной его лидирующая позиция в опросе. Либо хайп вокруг PHP на самом деле далек от действительности, либо это своего рода шутка.
SECL
21.11.2016 14:28-1Согласен, меня тоже удивляют результаты опроса) Я будем л лидерах будет Java. Еще JS почему-то отстает, тоже странно.
saggid
21.11.2016 17:05+1Писать всё на JS — банально дороже по затратам, как по мне. Да, круто, модно, молодёжно. Но писать на JS на стороне сервера — это, блин, не на жиквери лапшу лепить) Порог вхождения выше же. Плюс, до сих пор нет какого-то реально сильного фреймворка на ноде с кучей компонентов от сообщества, которые бы ты просто подключал и использовал в своей работе. Что имеется на других языках зачастую.
Если же я не прав — ткните меня в нос подобным фреймворком) Из того что я знаю — только Sails шуть шуть подходит под мои запросы. Да и то я так и не закрепился на нём, хотя было желание написать что-то.
gearbox
21.11.2016 18:38>Плюс, до сих пор нет какого-то реально сильного фреймворка на ноде с кучей компонентов от сообщества
Скорее нет (пока) вменяемого ORM (sails-овый народ тоже ругает, сам не пробовал), а так и express-а хватает для подавляющего большинства. Буржуи активно loopback используют. Для ноды фрейворк не нужен, это надо понять, принять и научится с этим жить. npm — чем не фреймворк? )
SECL
21.11.2016 18:49JS самый молодой, по крайней мере в том виде, в котором он описан тут, для бэк энда. Пройдет несколько лет и все появится. А пока, да, есть серьезные проблемы в его использовании.
LireinCore
21.11.2016 14:42+21) еще мало участников проголосовало
2) php-программистов чисто статистически больше всего
3) php7 весьма неплохazsx
21.11.2016 15:283) php7 весьма неплох
А php 5.* был ужасен и никто и никогда не выбирал его для больших веб-проектов (сарказм).
ps
Часто пишут, что FB для серверной части не использует php, скорее используется С++ и hiphop. Это очень важно отмечать, так как проектов размера мордокнижки очень мало и клиент с горящим взглядом, который делает очередной заказ на супер мега сложную информационную систему, которая круче авито и ОК вместе взятых, вряд ли, при Вашей жизни, достигнет посещаемости при которых php будет тормозить развитие его сайта. Это с учётом, что мы говорим о веб-проекте.
Кстати, ВК при Дурове использовал pure C на сервере. Отмечу, большие и сложные проекты реально сложны именно в серверной части (back end).
Как вывод большой проект надо писать на С, да?
M-A-XG
21.11.2016 14:42Чистый язык на первом месте!
Есть! :)
Мы сделали жалких фреймворщиков. :)
GreenBee
21.11.2016 15:04+1Если Вы имеете ввиду опрос и лидирующий там PHP, то я не понимаю, чем он «чище» остальных языков.
Пока что из результатов опроса можно сделать вывод, что эту статью прочитало больше всего людей, которые кроме PHP ничего другого не знают.M-A-XG
21.11.2016 15:42-1Я имею в виду:
«В технологиях я бы выделил 3 уровня абстракции:
Чистый язык — это материал, из которого можно сделать все, что угодно. На чистом языке сделаны все крупнейшие сайты мира с посещаемостью в сотни миллионов и миллиардов пользователей
Фреимворк — это некая среда разработки для программиста с готовыми правилами и инструментами. Фреимворк, с одной стороны, помогает и ускоряет разработку, а с другой, накладывает определенные ограничения. На фреимворках делаются проекты средней сложности с посещаемостью в миллионы.»
:)GreenBee
21.11.2016 16:10+2Не вижу связи между уровнями абстракции и «Мы сделали жалких фреймворщиков».
Более того, приведенный Вам абзац автора — мягко говоря, вранье.
Практически все крупнейшие сайты в том или ином виде используют фреймворки.
saggid
21.11.2016 16:37+2Большое спасибо за обзор. Внимательно ещё не успел прочитать, но из бегло просмотренного явно видно, что вы в теме, так как большинство ваших умозаключений коррелируют с моим опытом и мыслями на эту тему.
Если у вас есть опыт разработки больших проектов, хотя бы на несколько миллионов пользователей, прошу не просто проголосовать, но и обосновать свое мнение в комментариях, так как у каждого разные опыт и предпочтения
У меня нет опыта разработки проекта с такой большой посещаемостью, но всё равно хочется рассказать о своём опыте :) Самый популярный проект, разработку которого я вёл первые пару лет его жизни (сейчас я уже в другом проекте), имеет в данный момент посещаемость в 300 тысяч человек в месяц, и кол-во просмотров в пол миллиона. Работает он на Kohana фреймворке. Когда мы его начинали писать — Кохана тогда была популярна, а Laravel только набирал популярность :) Это большой медицинский портал с кучей всяких функций для пациентов и врачей, вроде записей на приём, отзывов, медицинских статей, каталога организаций, и так далее. Плюс, он ещё и мультиязычный и развивается сразу для России, Индии, США и может уже и для ещё каких-то стран в дополнение к этим.
В целом, Кохана и здравый котелок решили все возникшие проблемы. Разработку мы вели втроём — если говорить о программистах. Был я, и плюс была пара ребят, которые более-менее умели писать на фреймворках и на джс. На стороне фронтенда сначала мы всё писали на Backbone, так как он тогда был более-менее популярен. А впоследствии я многое переписал на Riot.js, когда узнал про него, так как он всё-таки намного более удобен для сложной JS логики.
Сегодня я всё также продолжаю использовать PHP для бэкенда, и меня всё вполне устраивает. Я снова веду разработку большого мультиязычного проекта, уже с другими людьми, в качестве технологий мы выбрали Laravel 5.1 LTS, Riot.js для сложных JS компонентов, шаблоны на Jade, которые компилируются gulp'ом в .blade.php. И SystemJS в связке с JSPM, которые отвечают за асинхронную подгрузку JS компонентов.
Честно, для веб-проектов, всё-таки, PHP — хорошая штука. В том числе об этом говорят ребята из Slack, к примеру. Я никаким образом не хочу унизить любые другие инструменты для разработки — вполне уверен, что и у них есть сильные стороны. Просто пишу о своём опыте.
Free_ze
21.11.2016 16:42Популярные фреймворки и платформы:
Кажется, если у Java стоит Spring, то для C# должен быть ASP.NET MVC/Core.
TwistedAndy
21.11.2016 16:45+1В том что большинство проголосовало за PHP нет ничего удивительного. Любой большой проект начинается с маленького. Если речь идет о вебе, то маленькие проекты дешевле всего запускать на PHP, поскольку на этом языке написаны многие CMS и существует куча неплохих фреймворков.
boldyrev_gene
21.11.2016 18:15Популярные фреймворки и платформы:
JS: Node.js, AngularJS
Node.js фреймворк?
Других фреймворков, кроме AngularJS типа нет?SECL
21.11.2016 18:29Node.js фреймворк?
Не совсем, это платформа. Я об этом писал.
Кроме AngularJS есть, конечно. В статье не все возможные фреймворки приведены
amaksr
21.11.2016 18:21Если начинать писать большой проект на «Чистом языке», в итоге все равно получится еще один фреймворк, так как по мере написания однотипных списков/форм приходит осознание, что у них всех есть общий код, который приходится копипастить с модификациями.
Кроме того, имеет смысл уточнить, что подразумевается под «большим проектом»:
— «большой в длину» — относительно немного относительно узких, но длинных таблиц (например соцсеть, сайт отзывов или объявлений)
— «большой в ширину» — много широких, но относительно коротких таблиц (например система ERP предприятия)
В первом случае логики обычно немного, но она должна быть очень быстрой и/или масштабируемой.
Во втором случае случае логики много и она сложная, но количество обрабатываемых сущностей не так велико.
Эти особенности тоже влияют на выбор стека. И поэтому, например, в корпорациях бизнес-процессы автоматизируют на Java, а в соцсетях используют PHP.M-A-XG
21.11.2016 18:28+1>Если начинать писать большой проект на «Чистом языке», в итоге все равно получится еще один фреймворк, так как по мере написания однотипных списков/форм приходит осознание, что у них всех есть общий код, который приходится копипастить с модификациями.
Будет написано ровно то, что нужно.
А не куча абстракций на все случаи жизни.
>в корпорациях бизнес-процессы автоматизируют на Java
Это просто глубое предубеждение, что это нужно делать на яве. :)
Fafhrd
21.11.2016 18:24+2PHP: Facebook, Вконтакте, КиноПоиск
А где же любимая бадушечка? Мне за них обидно.
istui
21.11.2016 18:26Много где встречал критику в адрес Joomla!.. А что именно в ней плохого? (я не защищаю систему, просто интересуюсь)
SECL
21.11.2016 18:55Ну само ядро нормально оттестировано. Но вот с модулями беда, архитектура тоже хреновая, в общем все программисты, которые с ней работали, обычно на неё плюются.
alekciy
22.11.2016 09:13+1Отвратительно кастомизируется и дырявое как ведро. Плагины зачастую пишут новички. С точки зрения разработчика работа с ней крайне неудобная. Но она такая потому что удовлетворяет запросы определенного рынка и делает это хорошо.
Poznakomlus
22.11.2016 15:21+1Не можем кастомизировать — кривые руки
Плагины зачастую пишут новички
Так это плюс, что новички могут написать плагин. Значит система легка в освоении.
С точки зрения разработчика работа с ней крайне неудобная
По сути вы сами себе противоречите, так как новички пишут плагины.
volanddd
28.11.2016 00:39+1Общественное мнение и предрассудки, основанные на шаблонах с TemplateMonster, Virtuemart и прочем варезе.
kanstantsin
21.11.2016 18:27+2Из опыта разработки проектов с 1М+ посещений в месяц могу сказать, что очень много факторов нужно учитывать помимо чистой посещаемости. Разные сайты с одинаковой посещаемостью могут создавать совершенно разную нагрузку на сервер, в зависимости от задач, которые сайт решает. Где-то нужны довольно ресурсоемкие вычисления, а где-то только выдача простых страниц из кеша. И каждый раз стоит просчитывать, что тебе будет выгоднее — писать быстрый и оптимизированный под задачи код, либо вкладывать бОльшие деньги в инфраструктуру при росте нагрузки.
Т.е. гворить о том, что CMS подходит для X посещаемости, а фреймворк для Y не совсем корректно.
Что касается «трендов», то думаю, что в большей степени это хипстерство, особенно относительно JS для бэкэнда — в более-менее сложном проекте без какой-никакой типизации, стандартов и т.д. не обойтись, а по опыту, в среде JS-программистов c typescript или flow знакомы единицы. Многие проекты на JS, которые популярны и сейчас на слуху, лучше не отрывать с целью проникнуться чистотой и логикой кода.
mpakep
21.11.2016 19:01+1По поводу пхп в лидерах опроса хорошо сказала бы реклама ваниш
«А если нет разницы зачем платить больше?»
Даже сам факт того, что большая часть не знает ничего кроме одного языка говорит о том, что они нашли в нем что искали и смысла искать дальше не было. Все открытия в том числе и новых языков идут от недостатков старых. Никто не будет искать новую технологию пока считает что старая его полностью удовлетворяет.Free_ze
22.11.2016 11:45+2А может
они банально неосиляторы?для них сложно изучать новое и потому довольствуются малым? Не все стремятся к звездам, это нормально для любого общества и рода деятельности.mpakep
22.11.2016 12:36-1Технологий в наше время слишком много, чтобы их изучать без причины. Изучение чего то просто для саморазвития не является причиной, так как относится ко всем технологиям без исключения. Как минимум нужно ощущение что это вам пригодится в дальнейшей деятельности. У каждого есть ворох нерешенных вопросов чтобы тратить свое время на что то бесцельное. Осознание необходимости это причина — поиск решение и изучение чего то в целях этого поиска — следствие этой причины.
Free_ze
22.11.2016 13:03Согласен с вами, что слепо следовать хипстерской моде — глупо. Но объективные причины имеются, конечно же.
mpakep
23.11.2016 10:11И все таки истинную популярность и массовый исход иным технологиям даст что-то действительно революционное. Только технология решающая большую задачу достойна внимания, а не язык в котором отличае от старого только в синтаксисе объектов и косметическом изменении синтаксиса. К мелочам php достаточно быстро привыкаешь, после чего многие из них кажутся вполне логичными и объяснимыми. А отсутствие прорывов в других языках окончательно сводит на нет желание менять шило на мыло.
holyhope
22.11.2016 00:42+1Классно структурировано и разложено по полочкам.
Но, как я понял, Вы измеряете сложность проекта в количестве будущих пользователей. Я предлагаю добавить вторую ось — функциональная сложность. Ведь может быть проект с огромной посещаемостью и относительно простым функционалом (например, сайт смешных коротких цитат) и проект с малой посещаемостью, но ужасающе сложным функционалом (например, внутренние корпоративные веб-системы — мы создаем узкоспециализированную срм как saas-решение). Можно выделить четыре квадранта, в каждом будут свои языковые лидеры: например, сложный функционал и малая посещаемость (как пример, enterprise-сегмент) — хорошо подходят Java и C#, простой функционал и большая посещаемость — Ruby (условно).SECL
22.11.2016 00:43В целом согласен, посещаемость не единственный критерий. Я выделил 17 критериев в начале статьи, которые важно учитывать при выборе технологии.
holyhope
22.11.2016 01:15Но я полагаю, не все критерии имеют равный вес. Потому что процесс выбора можно свести к двум шагам — возможно, я ошибаюсь, но это неявно сквозит в середине Вашей статьи и я с этим согласен.
Шаг 1 (критический). В зависимости от предполагаемой популярности проекта и функционала делаем выбор в пользу CMS, фреймворка или чистого языка.
Шаг 2 (не слишком критический, потому что Вы сами говорили о том, что большие проекты можно встретить на самых разных языках): в зависимости от остальных 15 критериев выбираем конкретный язык.
Самое важное выбрать: CMS или писать всё самим, а какая CMS и на каком конкретно языке писать — вопрос важный, но второго плана. Нет? В случае CMS мы тратим десятки тысяч рублей, при самостоятельной реализации с фреймворком — сотни тысяч, без фреймворка — ещё большие сотни тысяч :)SECL
22.11.2016 01:50Если грубо, то да, примерно так оно и выглядит) Но это теория, на практике всегда 1000 вопросов…
Scf
22.11.2016 00:55+1Странно, что в качестве метрики выбрали именно посещаемость. Имхо, самый важный критерий — сложность, а на втором месте — эффективность. Просто потому, что медленно работающий сайт можно быстро "починить" вливанием денег в железо, в то время как проект, провалившийся из-за недостаточного качества фреймворка/языка/программистов, починке не подлежит.
С другой стороны, очень мало сложных, посещаемых, эффективных проектов начинались именно такими. Как правило, все начинается со стартапов, где требуется сделать что-то работающее за минимальные деньги, а уже потом как-то чинить и переписывать. Если выстрелит.
Поэтому в интернете всегда будет много мнений, на чем надо писать сайт.
SECL
22.11.2016 01:51Обычно посещаемые сайты со временем обрастают функционалом. Так что это связанные вещи.
remal
22.11.2016 14:47А с чего бы это разработка на Java обязательно долгая?
Scala похожа на Java? Да и с чего бы этому языку быть будущему веб разработки?SECL
22.11.2016 14:55В среднем больше, чем на других язык. Особенно, если сравнить с питоном или руби.
remal
22.11.2016 15:29«В среднем» — это для каких проектов? У каких разработчиков? По каким методологиям/требованиям?
SECL
22.11.2016 15:45У всех разработчиков. Странный вопрос. Сам язык старый. Если не согласны, что питон быстрее джавы — обоснуйте. Но я пока не видел ни одного разработчика, который бы такое мог не то, что обосновать, но и даже сказать.
remal
27.11.2016 14:28А что именно, по вашему, в питоне такого, что делает разработку на нем бвстрее?
Gektorian
22.11.2016 14:53О e-commerce вспомнили, но ни слова про Salesforce Commerce Cloud (Demandware) и Oracle Commerce, которые выбирают для очень больших проектов, а не Magento и прочее на западе.
SECL
22.11.2016 14:55-1Да, еще есть Hybris, IBM Websphere и другие. В статье я не описывал решения для энтерпрайза. Я описывала только популярные CMS, типа Магенты. Коробок очень много и все их описать довольно проблематично.
zikkuratvk
28.11.2016 00:31Поподробней пожалуйста про архитектуру. Очень уж хочется сравнение архитектуру популярных CMS :-)
Пожалуйста с конкретикой, ядро построено так — это имеет следующие преимущества и недостатки, а так получается вы скатываетесь до холивара, типа Windows отстой из-за того, что мой знакомый мне сказал, что это так, он не может ошибаться потому, что использует Mac в повседневной работе.
Всегда любопытно почитать мнение "экспертов".
vjjvr
28.11.2016 13:35> Кто-то спрашивает у нас, как у разработчиков, как правильно, а кто-то приходит и просит сделать на какой-то конкретной технологии
Никакая это не проблема.
Так как уж совсем экзотикой разработчики не владеют.
И если соглашаются на ней делать — то это уже их ответственность.SECL
28.11.2016 13:35Соглашаются, делают говнокод, переписывают его через год нормально. Каждый второй запрос у нас — переписать старое полурабочее решение нормально.
azsx
Хотелось бы ссылку, где об этом пишет (говорит) кто-то из топ менеджеров FB, а не Ваши сомнения.
ps
Вдруг ссылка имеется, я хоть почитаю.
SECL
Согласен, вопрос холиварный. Во времена старта Фейсбука такого выбора, как сейчас прръосто не было, с этим, я думаю, не поспоришь. Но если смотреть крупнейшие сайты мира, то на PHP сайты далеко не самые большие. Я специально искал большие сайты на PHP, более 100 млн. пользователей, но кроме Фесбука, ВК и Кинопоиска особо ничего не нашел. Кроме этого, сам PHP в Фейсбуке не стандартный и они не раз заявляли про проблемы с ним. С другой стороны, сейчас вышел PHP7, который очень даже ничего. Возможно, скоро ситуация изменится.
azsx
А ОК на java и некоторые сотрудники компании, иногда пишут о проблемах в java. И как они их решают.
aleks_raiden
Wikipedia? Wordpress (который хостинг блогов), сайт белого дома, как упоминалось в статье.