МнениеПочему программисты снова становятся инженерами

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

По мере того как течёт время, порог входа становится ниже. Например, в Microsoft сейчас нет такой роли, как «тестер» — у них есть developer in test (Специалист, который пишет программы, тестирующие другие программы. — Прим. ред.). При этом всех людей, которые занимаются разработкой, называют инженерами программного обеспечения (software engineers), просто они задействованы в немного разных сферах. Сейчас освоить инструменты стало настолько просто, что границы между конкретными специализациями стираются. В будущем вряд ли останется разделение, скажем, на JavaScript-программиста, Python-программиста и .NET-программиста — как и разделение между фронтэндом и бэкэндом.

Правда, пока что остаётся проблема со средствами выражения. На фронтэнде есть только JavaScript, а на бэкэнде удобнее выбрать другой язык. Из этой мысли возник весь тренд с Node.js (Платформа, превращающая JavaScript из узкоспециализированного языка в язык общего назначения. — Прим. ред.). Благодаря этому упрощаются стандартизация и формирование команды, знание и экспертиза которой будут примерно равны. Да, у Node.js сейчас есть проблемы, но куда важнее, что мы получаем тот же набор инструментов во фронтэнде и бэкэнде.

всё Важнее становится понимание технологического стэка — технологий, которые лежат в основе того, что использует человек. Встречаются люди, которые программируют на JavaScript, и на вопрос, как работает протокол TCP, они отвечают, что это слишком низкоуровневое и они не хотят с таким разбираться. Вот это страшно: исходя из моего опыта, понимание базовых принципов, которые лежат под тем, что ты используешь, очень важно. До поры до времени это может не сказываться, но, как правило, зашоренность в одной технологии не позволяет делать нормальные решения по всему технологическому стэку.

Вот пример того, что я имею в виду под технологическим стэком в случае с браузером. Есть JavaScript, есть представление о том, что такое HTML, протокол HTTP. JavaScript-программисту никуда от этого не деться, он должен его понимать — как и то, откуда взялись правила изоляции и кроссдоменной безопасности, как работает протокол SSL, как работает безопасность, основанная на сертификатах. Дальше, если мы идём в бэкэнд, то человек обязательно должен понимать организацию структур данных. В любом более-менее сложном приложении, когда речь заходит о визуальном отображении сложных структур данных, объединении таблиц и организации выборок, интерфейс и бэкэнд становятся непосредственно связаны. Очень сложно сделать эффективное приложение, если люди, которые делают интерфейс, не понимают хотя бы базовых проблем, о которых нужно думать в бэкэнде: шардинг, организация данных, структура запросов. И наоборот: очень сложно сделать правильный API в бэкэнде, правильно предусмотреть возможность шардинга и горизонтального масштабирования, если человек, который пишет бэкэнд, не понимает проблем, которые есть на фронтэнде.

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

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

Сейчас, если я хочу сделать хороший сайт, то, наверное, имеет смысл нанять JavaScript-программиста. С другой стороны, я могу пойти на Wix или другой билдер и сделать там сайт, близкий к тому, что мне нужно. Мне кажется, что этот тренд продолжится. Возможность сделать свой сайт с неплохим динамическим контентом, просто подвигав ползунки и покидав кнопочки, появится у любого человека. Необходимость в людях, которые будут писать такие сайты, сама по себе отомрёт. Скорее всего, JavaScript-программисты не исчезнут — кому-то ведь нужно будет создавать высокоуровневые средства визуального моделирования. Но от специалистов потребуются более глубокие знания.

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

на уровень выше можно выходить бесконечно. Когда-то были средства низкоуровневого программирования: люди писали в байткодах, и их это не очень беспокоило. Потом появились средства того же ассемблера, следом за ними — средства уровнем выше. Если фантазировать, через 50—100 лет всё можно будет автоматизировать и дойти до полуискусственного интеллекта — вопрос во времени и сложности следующего технологического витка. Если посмотреть на историю разработки, то на каждом новом технологическом витке увеличиваются суммарный объём и широта знаний, которые нужно держать в голове, — хотя и доступ к ним упрощается. То, что можно просто взять и изучить JavaScript — это иллюзия. Реально нужно знать JavaScript и всё, что под ним. Переходя на следующий виток, нужно иметь хотя бы основные представления о том, что было до этого.

Чем дальше, тем более сторонними оказываются затрагиваемые сферы. Возьмите хотя бы развитие компании Apple, которое во многом было продиктовано увлечением Стива Джобса и людей, которые его окружали, гуманитарными науками: в частности, маниакальной любовью к красивым шрифтам и иероглифам. Все запоминающиеся изменения в информационных технологиях очень часто происходят на стыке наук. Это почти всегда синтез, потому что IT — просто способ представления и обработки информации, который лишается смысла в вакууме. Так, сложно назвать «программистами» людей, которые придумали графический пользовательский интерфейс, — это как сказать, что iPhone стал успешен благодаря только «железу» или только «софту».

Ещё 10 лет назад фронтэнд-разработчику казалась бы дикой мысль о том, что нужно прочитать книги о восприятии и психологии людей. Сейчас это уже само собой разумеющееся: если человек разрабатывает сайты, то он прочитал все возможные книги по UX, UI, тому, какой объём информации люди способны воспринимать, как её лучше подавать. И это ведь смежная технология, пришедшая к нам чуть ли не из медицины — и то же самое будет касаться физики, химии и биологии.

Сегодня много говорят о квантовых компьютерах, но мало кто понимает, что это такое. Когда удастся создать первый действующий квантовый компьютер, готовый к запуску в массы, это радикально поменяет весь технологический стэк. При этом выбрасывать всё не придётся. Люди будут искать средства совместимости: условно, как Parallels Desktop решает задачу совместимости между Windows и Mac, но в гораздо большем объёме.

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

Рассматривают и возможность построить биологические вычислительные машины. Когда это получится, они радикальным образом поменяют не только вычислительные технологии, но и устройство медицины и всего общества. Сейчас массовая медицина отслеживает здоровье людей всего по нескольким показателям: грубо говоря, это пульс, давление, биохимический анализ крови. А что, если создадут устройство, которое будет «жить» в организме человека и выдавать все эти данные в реальном времени по каждому человеку на Земле? Представьте последствия, которые это повлечёт за собой: продолжительность жизни увеличится не на жалкие проценты, а на очень заметные цифры.

Я предполагаю, что поэтапный рост пойдёт и вширь. Чтобы создавать новые средства разработки и новые платформы, потребуются знания не только в IT. Тот же Илон Маск создаёт эффективные способы транспортировки и консервации энергии. Всё это предполагает очень широкий набор технологий и знаний. Если удастся сделать батарейку, которая будет помещаться в некое маленькое устройство, и её не нужно будет перезаряжать хотя бы год, то это будет безумная точка роста, которая вызовет следующую технологическую волну. В каждой сфере есть пограничные районы, где неминуемо появится такая точка роста — вопрос только, когда и кому это удастся. Есть и те, кто во время очередного перехода остаются в прошлом: они не вымирают, но там уже нет такого роста, денег и чего-то интересного.

Что бы вы ни начинали учить сейчас, через 5–10 лет оно устареет. А потому, как бы глупо это ни звучало, нужно учиться учиться. Если есть запас времени, лучше посвятить его тому, как работает то, чем вы собираетесь пользоваться, — начиная от курса физики и математики. Без базовых знаний пресловутым умением учиться сложно воспользоваться. Фазовый переход на следующий уровень всегда намного проще для людей, которые понимают, как работают компьютеры на физическом уровне, — пускай они даже этим не пользуются и работают на гораздо более высокоуровневых языках. Они не просто пользуются автомобилем и включают передачи, а понимают, как автомобиль работает. Когда эта штука становится чем-то вроде электромобиля, им сделать этот переход намного проще.

Если мы ставим на стратегию долгосрочного развития и роста, то важнее не прикладные, а фундаментальные знания. Не банальное представление, как послать GET-запрос, а понимание HTTP-протокола: почему он был так сделан, какие идеи в него были заложены. Когда мы перейдём на условный SPDY (Разработанный Google протокол, предлагаемый как замена частей HTTP. — Прим. ред.), вы сможете понять, как произошло это изменение. Нужно общее понимание того, когда эти запросы посланы на сервер, как работает процессор, который делает эти вычисления на сервере. Слишком углубляться во всё не надо, но для широты знаний нужно понимать, как это всё работает.