Взяться за световое перо подвигла статья по визуализации, напрямую относящаяся к интерфейсам. habrahabr.ru/blogs/infodesign/139187/
В последний год видна тенденция того, что время активного клиента пришло (это подтверждают и разговоры с коллегами, и тенденции последних разработок), но не во всех проектах осознают, насколько оно пришло и востребовано. Пока что сохраняется положение, что без бекенда нет фронтенда и доля затрат на бекенд типично составляет 90% стоимости всего проекта. Приходит время немного сместить акценты, незначительно упростив бекенд (скажем, на 10%), и за счёт этого иметь возможность построить развитый фронтенд.
Не все ведущие проектов ясно представляют подход к проектированию фронтенд-архитектуры (например, REST, но есть ряд частных случаев просто одностраничных сайтов и сервисов). Все движения, в основном, сводятся к залатыванию дыр через осознание того, какой очередной шаг нужно совершить, чтобы система (сайт, портал, сервис, стартап) стала лучше. В то время как нужны совсем незначительные усилия, чтобы специалисты построили архитектуру фронтенда и затем реализовали её. Большинство потребностей на рынке формируется в виде формулировок текущих задач для залатывания дыр. Не спору, что залатывать дыры нужно, но при этом нет понимания, как устранить источник появления дыр в виде долгой загрузки страниц, сложной системы кеширования запросов к базам, рассеивания решения задач по разделам сайта. Перестройка системы требует времени и сил, а рынок предложения таких систем не сформирован. Если для бекенда разработаны десятки фреймворков, но для фронтенда их нет. Все решения — уникальны, и так будет продолжаться ещё некоторое время, примерно как в 95-98 году в сфере бекенда.
Состояние дел такое, что нужно формировать рынок предложений, чтобы разработчики систем могли осознать свои потребности и корни их существования. Отдельных специалистов может быть недостаточно (что и говорить, на рынке даже отдельных специалистов недостаточно). Но, как известно, дальновидные и хорошо финансируемые проекты строят свои системы, собрав команды специалистов и выработав план построения двух архитектур. Успешными проектами в этом плане можно считать реализованные высокотехнологичные сервисы Гугл-, Яндекс- почт, виджеты социальных кнопок, некоторые активные виджеты, работающие, в основном, для рекламы, в каждом их которых собраны лучшие идеи и видны стили работы будущего, которое пока не наступило.
Предложение?
Пора собраться команде или рынку разработчиков, предоставляющих подход к фронтенду для тех компаний, которые хотят улучшить свой сайт или сервис, средства есть, но неоткуда взять концепцию (которая, например, выработана для GTD — Скрам, Аджайл), не к кому обратиться за реализацией современной архитектуры, а построить её самому и за закрытыми дверями делать продукт, который перевернёт мир — не хватает знания технологий и необходимости собирать команду по крупицам.
Как пример, мне довелось видеть (Москва, крупная компания) задачу на 5-6 человеко-месяцев (начальный этап; понятно, что для крупного сайта внедрение архитектуры — долгий и постоянный процесс), которая не получила признания среди руководителей отделов, потому что на очереди была пара других серьёзных новшеств, а один я решал бы эту задачу довольно долго. Поэтому для таких случаев, а они реальны и происходят в дефолт-сити каждый месяц, если не чаще, нужна стройная система предложений, слаженная команда от 3-5 человек, сработавшаяся в отношениях и способная вникнуть и поднять новый проект.
Срабатываться можно в формате митапов, как этот (был): habrahabr.ru/events/332/ или дистанционным общением и разработкой на примере опенсорсного проекта, неважно какого. После некоторого времени срабатывания мы сможем выработать подход к построению современных архитектур и будет чёткое понимание ролей в команде. Команда может представить проект коммерческого продукта и план по реализации, она будет представлять интерес для заказчиков/инвесторов/работодателей на другом уровне, не к сборке команды по частям, а «покупки» команды с известным портфолио, выполненными проектами (в данном случае достаточно проекта архитектуры и начало его реализации). На любом этапе может возникнуть инвестор, покупающий будущий проект как продукт, рискнувший принять тот или другой план построения своего проекта с точки зрения фронтенда.
Даже если разработчик фронтенда успел «вкусить» нежелание начальства продвинуть фронтенд-архитектуру на своём проекте, думаю, есть смысл участвовать в формировании сообщества, потому что рано или поздно косность начальства закончится, будет новый проект, новая работа и новый заказчик. И тут понадобятся наработанные идеи и портфолио совместной опенсорсной разработки.
На чём строить?
Большинство работающих сайтов уже имеют сервисы по отдаче контента даже в формате JSON, как в моём примере, или почти имеющих, достаточно только перестроить и упростить выдачу. Генерация HTML тоже будет нужна для поисковиков, но есть ряд проектов (соцсети, сервисы услуг, магазины (на 50%) ), которым изначально это не нужно.
Получаемое имеет смысл формировать через легковесную MVVM-библиотеку (backbone, knockout, пару других), формировать классы объектов, с которыми работает сайт и фронтенд, обеспечить чёткую (без новых правил) и простую шаблонизацию, понятную любому верстальщику, который может работать со своей частью на любом этапе.
Удалённое общение тоже, думаю, приветствуется, потому что каждый участник получившегося сообщества фронтендеров может стать лидером в своём городе или принять участие в удалённой разработке некоторых проектов. В общем, коллеги, нужно формировать рынок фронтенд-услуг, а не смотреть, когда закончатся идеи начальства по залатыванию дыр и они сами придут к пониманию более глубоких перемен. Они придут, если будет подтверждённое наработками мнение группы разработчиков, а вы лично принимали в разработках не последнее участие.
Где общаться?
ЛС, комментарии, скайп, джаббер, почта — контакты через ЛС. Примкну к имеющемуся джаббер-каналу на подобную тему.
Автор: spmbt
