Новая реальность положила начало большим изменениям в сфере информационных технологий. Это явление ясно прослеживается в сфере Frontend-разработки. Вчера коллеги спорили о том, где заканчивается разумная оптимизация кода и начинается убыточный перфекционизм. Сегодня этот вопрос уже не стоит так остро — ведь появился риск того, что доступ к зарубежным платформам и фреймфоркам закроют на раз-два. Посмотрим на проблемы отрасли через призму наших дней, чтобы понять, как изменится жизнь российского бизнеса в обозримом будущем.
Проблема № 1: оптимизация производительности кода
Каждому пользователю удобнее и приятнее работать с оптимизированным приложением. Когда всё интуитивно понятно, быстро загружается и не ломается. С другой стороны, оптимизация — дело трудозатратное. Она отнимает много времени и сил специалистов и, как следствие, денег заказчика, поскольку услуги Frontend-разработчика стоят недешево.
Что изменится?
Раньше небольшие и средние компании могли по незнанию потратить лишнее на оптимизацию, но всё равно оставались в выигрыше — с качественным продуктом на руках. Сейчас экономить нужно всем, поэтому любой бизнес будет искать компромисс между ценой и качеством.
Компромисс — дело тонкое. Он может быть как разумным, так и не очень. Чтобы уменьшить затраты на оптимизацию производительности кода, но при этом получить годное приложение на радость пользователям, нужно понять, где и когда можно сэкономить.
Менеджеры проектов будут чаще обращаться к нетленным лазейкам Frontend-разработки:
Экономить «процессорное время». Приложения давно переросли в огромные отрасли ИT-индустрии. В них используются сотни мегабайт данных, которые заполняют так называемое процессорное время. Чем сложнее вычисление, тем больше времени процессору требуется на обработку. Программисты давно стремятся экономить ресурсы компьютера. Существуют паттерны и архитектуры, позволяющие достигнуть максимальной экономии ресурсов. Начав применять их на ранних этапах разработки, можно избавиться от необходимости оптимизировать производительность кода в будущем.
Работает — не трогай. Так же и с программой. Если она выполняет свои задачи, то дополнительно дорабатывать и тем более оптимизировать ее не нужно. К оптимизации необходимо приступать, только если проседает производительность.
Оптимизацию можно отложить на потом. Браузеры в большинстве своем успешно оптимизируют код без участия программиста. Кроме того, современные инструменты разработки включают оптимизацию по умолчанию. Поэтому зачастую грамотно написанное приложение не нуждается в дополнительной оптимизации производительности со стороны разработчика.
Таким образом, в 2022 году бизнес будет стремиться не тратить лишние деньги на оптимизацию производительности кода. При этом умный менеджер, несмотря на экономию средств, сумеет не оставить приложение совсем без нее.
Проблема № 2: оптимизация скорости загрузки
Время ценится высоко, особенно когда дело касается загрузки страницы, ведь пользователи не любят ждать. Скорость загрузки является одним из главных параметров приложения и влияет на то, будут ли люди оставаться на сайте. Косвенно она отражается и на имидже бренда.
Хорошо оптимизированные сайты загружаются в мгновение ока, что положительно влияет и на пользовательский опыт, и на поисковую выдачу. У программистов есть множество инструментов для оптимизации приложения — как на клиентской части, так и на серверной. Они представляют собой алгоритмы действий для быстрой загрузки контента.
Так, разработчики нередко используют шрифт по умолчанию на старте, а затем, когда загрузится основной, незаметно его подменяют. Как правило, большая часть оптимизации загрузки берет на себя количество используемых шрифтов, скриптов и картинок. Чем меньше разновидностей письменных начертаний, тем быстрее пользователь увидит текст и сможет с ним взаимодействовать. Шрифты могут быть очень тяжеловесны, и их передача по сети занимает время, которое поможет сэкономить применение шрифта по умолчанию.
Картинки, в свою очередь, принято сжимать и подгонять под размер особым образом, указывая немного разные картинки для разных параметров экрана. Скрипты и вовсе могут блокировать показ контента, пока какая-то функция не выполнится. Файлы с логикой разделяют по их логической части, и та, которая в данный момент не нужна, подгружается асинхронно.
Также все файлы принято минифицировать, то есть удалять в них пробелы и неиспользуемый код, поскольку любой символ, в том числе и пробел, влияет на итоговый размер загружаемого приложения.
Что изменится?
В этом направлении больших изменений ожидать не приходится: проблема по-прежнему актуальна в современной разработке, а пути ее решения не предполагают больших временных и финансовых затрат. Использование инструментов для оптимизации скорости загрузки — единственно верный путь для создания конкурентного приложения.
Проблема № 3: создание независимого средства разработки
Стартовые платформы (WebStorm, VSCode, Sublime и др.), а также готовые библиотеки и фреймворки (Angular, React, Vue и др.) в какой-то момент стали любимыми средствами разработки для многих ИT-компаний по всему миру. Такие инструменты распространяются в свободном формате и с исходным кодом, позволяя разработчикам создавать продукт по ранее соглашенным правилам.
Компании, использующие эти инструменты, просто действуют по определенным правилам написания кода. Соответственно, они могут нанимать разработчиков, уже знакомых с архитектурой приложения, которое им предстоит делать — потому что они знают выбранную работодателем стартовую платформу. Время на погружение в проект сокращается до минимума.
Появление таких средств разработки ответило сразу на несколько запросов бизнеса:
Увеличение скорости разработки. Стартовые платформы и готовые библиотеки позволяют привлекать новых разработчиков в проект на любом этапе. Причем так, чтобы они сходу погружались в работу.
Создание кросс-платформенных приложений. На рынке существуют мобильные устройства с разными операционными системами. Разработка с нуля под каждую из них невыгодна. Но, зная один инструмент, можно писать код под любую ОС.
Снижение стоимости работ. Уменьшение затрат временных и человеческих ресурсов на разработку экономически выгодно для бизнеса.
Суть открытого исходного кода делает его незаменимой базовой составляющей Frontend-индустрии. Любой разработчик в мире может вносить свой вклад в развитие этого направления. А когда над проектом трудится много людей, то и прогресс не заставляет себя ждать. Вместе с тем благодаря стартовым платформам бизнес имеет возможность создавать качественные кросс-платформенные приложения быстро и сравнительно недорого.
Что изменится?
Сейчас все стартовые платформы принадлежат зарубежным компаниям, а риск того, что они могут в одночасье перекрыть доступ к своему продукту, велик. Проблема усугубляется тем, что некоторые программисты добавили в свой код вредоносное ПО, определяющее IP пользователя из России и способное стереть данные проекта.
Если раньше тема импортозамещения была частью повестки, но не являлась по-настоящему приоритетной для российских ИT-компаний, то сейчас она вышла на передний план. Очень важно в короткий период создать альтернативные российские стартовые платформы, способные обезопасить отечественную Frontend-разработку от возможной стагнации.
Заключение
Рассмотрев проблемы отрасли через призму наших дней, можно сделать прогноз для задач, актуальных для российских компаний. Малый и средний бизнес будет заинтересован в том, чтобы не тратить на оптимизацию лишние средства, создавая при этом конкурентные приложения. Гиганты же с большой вероятностью сосредоточат свое внимание на создании независимого средства разработки.