Legacy

С 2004 года мы успели поработать с очень разными платформами и технологиями. И первые 9 лет существования нашей компании мы занимались  разработкой проектов только в экосистеме PHP. Это дало нам много опыта и хорошее понимание внутреннего устройства многих из перечисленных ниже технологий и платформ.

А в 2013 году мы приняли решение обновить наш технологический стек для разработки новых проектов. Цель была достаточно простая — нам нужны были технологии, которые были бы более перспективными с точки зрения возможностей и качества разработки. В результате мы остановились на Ruby для веб-разработки, на Python для анализа данных и машинного обучения, а также на Go для наиболее нагруженных API и веб-сервисов.

Но, разумеется, полностью перейти на новые технологии и забросить все ранее использовавшиеся оказалось невозможным. Многие прежние проекты, даже созданные нами в нулевых годах, до сих пор работают и мы их сопровождаем. Также мы часто ввязываемся в поддержку проектов на прежнем технологическом стеке из-за того, что у нашего Заказчика эти проекты уже были сделаны до начала работы с нами, изначальные разработчики «бесследно пропали», но проекты должны продолжать работать пока не получится их заменить.

Собственно поэтому мы продолжаем работать с этими технологиями, хоть и не столь активно, как ранее.

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

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

Грамотный выбор любых технологий основывается на критериях, которые будут важны в рамках вашего горизонта планирования:

• Нужен простой сайт «вчера» и планов на развитие почти нет — делайте его на SaaS, не тратьте время и ресурсы на заказную разработку, а сэкономленные деньги лучше потратьте на маркетинг. Или используйте бесплатную CMS и минимизируйте затраты на разработку.
• Нужен средний по сложности сайт без серьёзных планов по развитию и без жестких требований к производительности, нагрузкам и безопасности — берите CMS, обычно это экономически наиболее целесообразно. 
• С ростом сложности проекта, при его существенных отличиях от типового или при наличии высоких требований к качеству ПО, CMS обычно начинают уступать веб-фреймворкам по стоимости разработки и уровню достижимого качества.

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