Когда команда блога Browser попросила меня написать пост о тенденциях цифрового развития на рубеже 2022 года, я сначала не был уверен. Я попытался объяснить, что большинство макроэкономических тенденций развития, которые появляются в течение длительного периода времени, не просто удачно исчезают в январе — эволюция, а не революция, если использовать шаблонную фразу, — и любая статья должна быть более глубокой и далеко идущей.

Звучит здорово! — был ответ (хотя в конце концов они уговорили коллегу написать ту статью, посвященную 2022 году, которая здесь). Итак, здесь мы с некоторыми из моих мыслей о долгосрочном направлении развития профессии. В частности, я вижу большое влияние того, как легко настраиваемые продукты SaaS будут влиять на роли в проекте, и необходимость того, чтобы разработчики были открыты для изменений.

Вкратце: программирование больше не только для разработчиков. Мы будем кодировать намного меньше; и тот код, который мы пишем, будет специфичным для предметной области.

Роли развития начинают размываться

Традиционный менталитет, пронизывающий мир программного обеспечения, часто представлял собой структуру того, кто за что отвечает: разработчики и не-разработчики, бэкендеры и фронтендеры. Но я чувствую, что мы переходим от этого мышления к более гибкому подходу, ориентированному на результат. Все чаще встречаются дизайнеры, в портфолио которых есть работы разработчиков, и которые хотят реализовать свои собственные идеи, а также свежие выпускники программы MBA, приходящие в организацию и пишущие собственные скрипты на Python для получения нужных им данных. Помните, мы говорили: «Каждый должен научиться программировать»? Что ж, они сделали.

Решения с низким кодом и без кода также влияют на тенденции макроцифрового развития. Варианты конфигурации на таких веб-платформах, как Wix и Squarespace, действительно сильны. В то время как сегодняшние менеджеры по маркетингу могут учиться кодировать, сегодняшние разработчики могут выбрать настройку существующих сервисов, а не код для наиболее практичных и устойчивых результатов. Мы с коллегой недавно запустили клиентский проект для общественности в течение 5 недель после получения предложения. Единственный код, который я написал, — это около 15 строк CSS для правильного брендинга, остальное — просто подключение нескольких сервисов.

Для небольших проектов клиенты больше ожидают, что каждый разработчик достаточно полнофункционален, чтобы справиться как с фронтендом, так и с бэкендом. Также существует некоторое размытие между ролями дизайнера и фронтенд-разработчика, особенно в отношении результатов, которых можно достичь с помощью настройки. Я вижу, как некоторые из этих барьеров разрушаются, и определение того, что такое профессиональный разработчик, становится все более расплывчатым.

Я бы посоветовал разработчикам не дорожить своими ролями и обязанностями. Здесь критическим элементом будет обеспечение того, чтобы независимо от ролей, задействованных в вашем проекте, ваши заинтересованные стороны находились в центре. Успех проекта – самый важный результат. Ваше эго не должно быть фактором. Постарайтесь не волноваться о том, в чьей должности есть слово «разработчик».

Для этого есть продукт SaaS

Закон Конвея гласит, что когда организация пытается разработать систему, она в конечном итоге будет отражать коммуникационную структуру этой организации. Несмотря на то, что этот закон существует уже более пятидесяти лет, я думаю, что он очень актуален для того, что, как я вижу, все чаще происходит в сфере CMS и веб-разработки. Эти большие, монолитные и сложные CMS или платформы цифрового взаимодействия начинают не соответствовать той гибкости, оперативности и удобству, в которых нуждаются специалисты по маркетингу и ИТ.

Если вы чувствуете, что боретесь со своей CMS, то ее дни должны быть сочтены. Более точный и полезный продукт, обычно доступный под какой-либо торговой маркой SaaS, лучше восполнит пробел и уменьшит любые трения; для сообщества разработчиков это будет означать меньше кода и больше настроек. Закон Конвея может быть обвинением в том, как мы проектируем программное обеспечение, чтобы оно соответствовало ожиданиям людей, которые не проектируют программное обеспечение, но другое прочтение может состоять в том, чтобы воспринимать его поучительно: Эй, заполните пробел в общении между бухгалтерией и менеджерами проектов, а не Эй, перестройте коммуникационную структуру нашего бизнеса, чтобы она соответствовала тому, что позволяет WordPress.

Продукты SaaS начали убивать каскадные подходы, и эта тенденция только набирает обороты. Качество некоторых из этих продуктов высокое, а это означает, что больше нет причин по умолчанию использовать водопадный проект, в котором у вас есть бэкенд-разработчик, фронтенд-разработчик, двухмесячный график и значительный бюджет. Вместо этого у вас может быть готовый сильный MVP за две недели, и даже если он сразу не делает всего, что вам нужно, вы впоследствии дорабатываете его. Возможно, обещание методологии AGILE заключалось в управлении решениями, а не в разработке программного обеспечения?

Я думаю, что как разработчики мы должны быть гибкими и сосредоточиться на том, что лучше для веб-сайта, контента, опыта и бюджета. Иногда это будет означать отказ от работы с CMS или подходом, к которому мы привыкли. Это может показаться очевидным, но речь идет о правильном инструменте для правильной работы и правильном продукте для правильного проекта. В будущем мы все будем работать с гораздо более широким спектром различных продуктов SaaS.

Языки программирования меняются

Итак, до сих пор я в основном говорил о тенденциях цифрового развития из областей, не связанных с программированием. Но эй, как насчет кодирования? Ну вроде не уходит. Вместо этого он интегрируется в другие дисциплины. Но, возможно, «веб-разработчик» может уйти. Я знаю, что перестал использовать термин «веб-разработчик» для описания себя, за исключением тех случаев, когда на званых обедах мне нужно сокращение для «Я создаю код, который используют люди в Интернете». В 2014 году веб-разработчик была горячая работа. К 2024 году в LinkedIn резюме «веб-разработчик» будет означать просто «по состоянию на неопределенный стажер, специализирующийся на коде, начинающий работать в какой-то отрасли». Но как мы сюда попали?

Побалуйте меня ностальгией: помните Web 2.0?

Макротренды имеют полуциклический характер. Или, может быть, это своего рода приливы и отливы? Некоторое изменение (например, появление смартфонов) вызывает смену парадигмы на рынке, появляются все конкуренты в новом пространстве, затем происходит своего рода эволюция, и рынок стабилизируется на победителей и проигравших, затем парадигма снова меняется, и все повторяется.

Имея это в виду, если мы хотим понять первую половину этого десятилетия, важно подумать о первой половине последнего. Мы только что оставили своего рода кембрийский взрыв веб-технологий в конце нулевых. Появлялись новые фреймворки, такие как Ruby on Rails, и ходили слухи о серверном JavaScript; новые цели, такие как ОС Android и iPhone, а также какой-то новый браузер, сделанный Google; и новые потребности бизнеса, такие как приложения для мобильных устройств (или только для мобильных устройств?!). Масштабы каждого нового веб-приложения — а почти все веб-приложения были новыми — стремительно расширялись, а интерфейсные фреймворки, такие как Bootstrap и Foundation, должны были позволить каждому обслуживать их все одновременно. везде» », как обещала Java в 90-х.

Что случилось? Куда делся горячий новый JS-фреймворк недели? Ну, сложно сказать наверняка, но я попробую.

Мы живем на острове стабильности

К счастью, хотя и болезненно, это иррациональное изобилие, которое характеризовало предыдущее десятилетие, наткнулось на обыденные реалии разработки программного обеспечения, и рынок неизбежно сократился и стабилизировался в пользу более производительных продуктов. В мире JavaScript VueJS и React родились вместе со своими еще не обреченными конкурентами (Ember, Knockout, Batman, Meteor, AngularJS, Backbone, lodash), а уже в 2014 году Ruby on Rails объявляли мертвым и предсказывали свое существование. неминуемая смерть остается ежегодной традицией. По сути, если ваш фреймворк не удовлетворял потребности достаточного количества компаний, он должен был стать ненужным другим. Это привело к тому, где мы находимся сегодня.

В современном мире развития дела обстоят хорошо™. Под «хорошим™» я имею в виду стабильный, производительный, зрелый и относительно беспроблемный.

Несмотря на свою раннюю репутацию (заслуженную или нет), жизнь в мире JavaScript удалась™. Машинопись, нравится вам это или нет, хороша™. NPM, нравится вам это или нет, хорош™. VueJS и React хороши™ — выберите один и будет вам счастье. Мы больше не видим так много JavaScript-фреймворков de jour, потому что сегодняшний мир JavaScript основан на выборе предпочтений вместо выбора яда.

То же самое можно сказать и о стране PHP, где жизнь тоже хороша™. Laravel и Symfony находятся в очень счастливом положении. Извините за неудачников, но разработчики будут работать там, где есть вакансии, а разделы Drupal и CodeIgnitor на досках вакансий уменьшаются. (Странным исключением здесь всегда будет WordPress в его шреденгеровском состоянии как хорошего™, так и нехорошего™.) Сам PHP больше не испытывает недостатка в предположительно критических функциях, и большинство последних обновлений связаны с улучшением качества жизни.

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

Мы можем поговорить о завтрашнем дне?

Есть кое-что, чего языки сценариев нам не предлагают. Вы заметили это в разговорах с другими разработчиками?

Когда вы в последний раз видели, чтобы язык сценариев, не являющийся устаревшим (т. е. не старая гвардия PHP, Python, Perl, Ruby, JavaScript и т. д.), вышел на рынок с размахом или заинтересовал молодых разработчиков? Несколько лет назад темой, которая доминировала в основных докладах на вашей любимой технической конференции, была парадигма: функциональное программирование против объектно-ориентированного программирования (ООП). Кажется, этот разговор нас больше не интересует. Результат всего этого обсуждения был прост и должен был быть очевиден с самого начала: следуйте той парадигме, для которой ваш язык лучше всего подходит, и принимайте решения, основываясь на том, что лучше всего подходит для вашего продукта. Итак, если разговор не о парадигме, то о чем хочет говорить сообщество?

Если тенденции цифрового развития последнего десятилетия были сосредоточены на фреймворках, то в этом десятилетии они будут сосредоточены на языке. Пока веб-разработчики прыгали с фреймворка на фреймворк, параллельно назревала менее рефлекторная революция нативных языков. Стали появляться новые специально созданные и ориентированные на миссию языки с серьезными сообществами и серьезными сторонниками.

В подавляющем большинстве случаев разговор сместился в сторону строго типизированных языков. Я думаю, что мы приближаемся к четырем или пяти основным многоцелевым языкам со строгой типизацией, достигшим совершеннолетия и зрелости. TypeScript, Rust, Go, Kotlin и Swift, некоторые из которых имеют крупных сторонников, включая Google, Mozilla, Apple и мою учетную запись Patreon, вероятно, станут популярными языками в ближайшие годы, а также некоторые отличные связанные веб-фреймворки, такие как Actix-web от Rust и Vapor от Swift (неизбежный неудачник, как Kitura, но, тем не менее, замечательный проект). Будет интересно следить за годовым обзором разработчиков стека, чтобы увидеть, как будет развиваться популярность языков программирования в течение следующих двух-трех лет.

Языки, за которыми я буду наблюдать, имеют несколько общих черт, несмотря на то, что они пришли из разных мест: Go был создан для сервера; Swift был создан для разработки под iOS; Котлин для Android; Rust для браузера; TypeScript для Интернета. Все строго типизированы. Все они созданы специально. Все они были стабильны и сильны, прежде чем сделать свои маленькие шаги за пределы своего предназначенного пространства, чтобы возвестить новую эру программирования. Мы скоро увидим, как каждый из них попытается стать Vue или React этого десятилетия.

Чтобы понять, каким будет будущее, нам нужно начать представлять, каковы будут условия победы для любого данного языка. Например, у Rust, безусловно, лучшая история, если вы верите, что Web3 (1) — это реальная вещь, и (2) будет существовать после того, как публика окончательно потеряет интерес к мошенничеству с помощью NFT и любых других монет. Гарантии безопасности типов и времени выполнения (например, отсутствие условий гонки) предлагают виды обещаний, которые имеют решающее значение для разработки смарт-контрактов. Наиболее подходящим конкурентом Rust в этой области является TypeScript, который предлагает разработчикам JavaScript некоторую безопасность для быстрого создания своих прототипов. Кто победит: дисциплинированный разработчик Rust или шустрый детишка TypeScript? В любом случае, это будет сильная система типов, которая позволит им использовать их — хотя бы для брендинга. Кто проиграет? Как раз вовремя компиляторы, я полагаю.

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

Что может пойти не так?

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

Apple может осуществлять некоторый контроль над Swift, но IBM и общественность (среди прочих) вносят большой вклад и имеют довольно большое влияние. История, повторяемая на всех языках с любым шансом на успех. Mozilla отказалась от контроля над Rust.

Иногда вы видите фреймворки в кажущейся вечной бета-версии, где частота между версиями слишком велика или направление ставится под сомнение сообществом. Эти фреймворки рискуют зачахнуть и застрять в «стране хобби». Доверие является основой успеха фреймворка, а доверие сообщества может угаснуть на удивление быстро. В то время как Actix-web в Rust преуспевает в этой области (несмотря на небольшие разногласия вокруг версии 2), фреймворк Rust Rocket потерпел полное фиаско, так как никогда не был полностью готов даже к следующей второстепенной версии в своей бета-версии (в настоящее время это 0,5-rc1 в течение почти год).

В итоге

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

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

О браузере

Мы создаем корпоративные веб-приложения для лучшей и более продуктивной работы. Мы помогли таким клиентам, как Shell, British Airways и UK Gov, повысить эффективность и оптимизировать их бизнес. Посетите нас в Browser London.

Первоначально опубликовано на https://www.browserlondon.com 7 марта 2022 г.