Автоматизация разработки ПО: сможет ли «программист» превратиться в «оператора ЭВМ»
Изображение с сайта vse-temu.org
К чему ведет нас прогресс в области производства программного обеспечения? Средства разработки ПО становятся все более совершенными, некоторые этапы разработки полностью или частично автоматизированы. Консерваторы, конечно же, скажут, что программист в настоящее время — уже не торт, что подобная автоматизация ведет к упрощению задач и потере квалификации инженера-программиста. По их мнению, на фоне развития инструментария происходит деградация кадров.
Но если копнуть глубже, возникнут вопросы. О каких именно программистах речь? О тех, кто проектирует ПО? О тех, кто разрабатывает алгоритмы? О ведущих разработчиках или простых «кодерах»? В любом случае, одного мнения здесь быть не может.
Поэтому, прежде чем делать какие-то выводы, стоит хотя бы вспомнить, как мы пришли к этому.
Точка отсчета
Как сказал Михаил Густокашин на лекции в «Яндексе», давайте начнём с самого начала:
В самом начале у компьютеров не было даже клавиатуры! То есть всё было очень плохо — у них не было ни клавиатуры, ни экрана, были перфокарты (это такие штучечки с дырочками или с отсутствием дырочек).
И программы в то время писали с помощью машинных кодов — у каждой операции в компьютере (сложение, умножение, какие-то более сложные операции) был код. Люди сами по табличке выбирали этот код, всякие адреса в памяти, всё это выбивали руками и засовывали в считыватель — и оно всё считалось. Конечно, работа программиста была, наверное, тогда не особо интересной — проделывать дырочки — и с развитием науки и техники, конечно, начали придумывать всякие более «интересные» штуки.
Например, ассемблер (Assembler), который уже несколько облегчал жизнь. Ну, как он облегчал жизнь? Вместо запоминания того, что там какой-то «волшебный» код у команды, использовались всякие слова, похожие на «человеческий» английский язык — какие-нибудь add или mov — ну и затем перечислялись регистры или области памяти, переменные, с которыми нужно эти операции производить. Но понятное дело, что это в общем-то тоже требовало достаточно большого напряжения ума, чтобы держать у себя в голове, в каком регистре у нас что лежит, где какие переменные и что вообще происходит. Почему так происходило? Потому что компьютеры были «глупые» и ничего более «умного» понять не могли.
Изображение с сайта devdelphi.ru
На этом этапе порог вхождения в программирование был чрезвычайно высок.
Производительность программиста в этих командах была предельно низкой — то есть он писал несколько строк в день (осмысленных), и каждая строка ничего особо и не делала — какие-нибудь простые арифметические действия. И людям хотелось сделать языки гораздо более похожими на человеческий язык, на английский в частности, чтобы писать программы было легче и удобнее.
Уровень выше — порог ниже
С появлением языков программирования высокого уровня жизнь программистов становилась легче, а производительность — выше. Программы не нужно было переписывать для каждой машины. Появились компиляторы, среды разработки. Fortran, Algol, а позже BASIC, PASCAL, C действительно были больше похожи на «человеческий» язык.
Конечно, по-прежнему требовалось значительное время на их изучение, но это было более выгодное вложение времени и сил. В процессе работы компилятор указывал программисту на синтаксические ошибки в его коде, что в особенности облегчало разработку начинающим специалистам. С появлением модульности и переносимости кода проекты стали больше, а программисты начали широко использовать в проектах сторонние библиотеки, больше работать в командах. Это избавило их от необходимости подробно разбираться в том, как работает весь проект.
С появлением объектно-ориентированного программирования (С++, Object Pascal и так далее) тенденция повторного использования кода усилилась. Кроме того, со временем среды разработки становились более дружественными, и желающих освоить азы программирования становилось больше.
Программирование — в массы
Постепенно программирование перестало быть прерогативой хардкорных инженеров и математиков. Число проектов стремительно росло, программное обеспечение проникало в разнообразные сферы производства. Этому также способствовало и развитие систем управления базами данных. Появились даже такие специализации как «оператор СУБД».
Постепенно понятие «инженер-программист» стало многогранным: кто-то занимался алгоритмами, кто-то проектировал интерфейсы, кто-то просто занимался кодированием — то есть реализовывал в коде готовые алгоритмы своих коллег. Само программирование стали делить на две крупные группы — системное и прикладное: кто-то разрабатывал операционные системы и драйверы, а кто-то писал приложения для автоматизации бизнес-процессов на овощной базе.
Для каждой из специализаций требовались индивидуальные компетенции, поэтому переход от одной специализации к другой был затруднителен. Но минимальный порог вхождения в разработку ПО стремительно снижался.
Появление языков (Java, C#) и соответствующих фреймворков еще больше способствовало этому снижению, а также дифференциации специалистов по направлениям и уровням подготовки.
В результате у программистов закрепилась градация наподобие [Junior-разработчик, Senior/Middle, Team Lead, Software Architect]. С одной стороны, продвинутый инструментарий разработки позволял менее квалифицированным программистам успешно справляться с относительно простыми задачами, не имея глубоких знаний и серьезных навыков. С другой стороны, с каждой последующей ступенью карьерной лестницы порог вхождения также становился выше.
Изображение с сайта
Но если специалист задерживался в статусе начинающего, он мог заметить одну особенность: бурно развивающиеся технологии разработки ПО еще сильнее снижали порог вхождения, и среднестатистический Junior урожая N-го года знал и умел еще меньше, чем его старший товарищ — Junior (N — k)-го года.
Веб-разработка методом «тяп-ляп»
С развитием веб-разработки программистам потребовалось встать на другие рельсы (ассоциация с Ruby On Rails здесь тоже уместна), чтобы освоить новые языки и стек интернет-технологий разработки в целом.
После того как веб-разработка, начавшая набирать обороты только в 90-х годах, совершила огромный скачок в развитии, Михаил Густокашин может свободно пускаться в подобные рассуждения:
Допустим, вы хотите написать новый Facebook (социальную сеть). На чем вы будете это писать? HTML, CSS — это дизайн, а мы хотим, чтобы там можно было фотографии добавлять, друзей, комментарии оставлять.
Для скриптовой части — то есть то, что будет происходит на стороне клиента, — это JavaScript.
На удивление, он написан на PHP — и Facebook, и многие другие большие проекты. Пришлось, конечно, написать свои какие-то вещи, чтобы это всё-таки работало нормально, а не так как «тяп-ляп» было сделано, но они справились.
Здесь и сейчас, понятное дело, с нуля уже для веба никто ничего не пишет. Все ищут какой-нибудь фреймворк или ещё чего-то. Интернет-магазин? Скачали фреймворк для интернет-магазина — ну и всё, написали интернет-магазин.
Стоит отметить, что и поначалу порог вхождения в веб-разработку был ниже, чем в Desktop. После появления фреймворков он снизился еще сильнее.
На волне автоматизации
Получается, что раньше сайты писали «руками», а теперь это стало необязательно во многих случаях. Более того, для создания тех же интернет-магазинов уже нет надобности даже в использовании фреймворков: теперь есть конструкторы сайтов. Теперь веб-программисты, не обремененные квалификацией, которые раньше получали легкие деньги, создавая однотипные сайты, могут превратиться в операторов-конфигураторов.
Все потому, что в чьи-то светлые головы пришла идея автоматизировать процесс веб-разработки. Хотя, на самом деле, идея не нова, так как она уже частично была реализована во многих инструментах разработки ПО под Desktop-платформы в виде автогенерации форм и целых слоев приложения — например, генерация классов по структуре базы данных.
Если индустрия будет развиваться в том же русле, то все больше кодеров (программистов, находящихся в начале пути либо имеющих невысокую квалификацию) получат возможность превратиться в операторов-конфигураторов. Использовать такую возможность или нет, каждый решит для себя сам.
Мы выяснили, что по этому поводу думают эксперты, представители ИТ-индустрии:
Алексей Бычко, старший релиз-менеджер (Percona), разработчик проектов Percona Server for MySQL, Percona XtraDB Cluster, Percona XtraBackup, Percona Server for MongoDB, PQuery, преподаватель курса «Системное администрирование» в ИТ- Академии Алексея Сухорукова:
Появляется всё больше и больше сред для автоматизации рутинных вещей — это помогает лишний раз не писать что-то вручную, не изобретать велосипедов. Многое уже предусмотрено в интегрированных средах разработки, из которых можно вызывать нужные библиотеки и так решать стандартные задачи. Для тех, кто умеет и привык думать, это хорошо — можно сконцентрироваться на основном, на логике приложения. (Это люди «старой школы», которым для написания качественного кода хватит и простейшего текстового редактора).
Плохо, что растёт число быдлокодеров, которые, в принципе, могут решить поставленную задачу, собрать что-то из имеющихся «кубиков», но не представляют, как что работает внутри, и не могут оценить, насколько оптимален чужой готовый код. По этой причине я бы хорошего программиста именно «кодером» называть не стал — код сейчас пишут даже младшие школьники, его и машина сгенерировать может. Программист думает, изобретает, устанавливает зависимости, задаёт пути, проектирует архитектуру –, а потом он всё это может отдать кодеру на реализацию.
По сути, это два подхода, которые выросли из факта наличия проективных Unix-подобных систем и процедурных Windows-подобных. Огромной корпорации, где всё разбито на мельчайшие подзадачки, важна воспроизводимость результата, а не оптимальное решение — если оператор ушёл, нужно, чтобы новый по инструкции делал то же самое и не хуже.
Но если у нас есть задача, которая конкретной процедурной системой, библиотекой или средой решается плохо или не решается вовсе (коллеги постарше помнят, что бывает, когда в написанный в C++ Builder или Delphi текстовый редактор попадает большой файл — ничего не листается и всё тормозит, и это никак не поправить), то нам нужно взять «чистую» систему, которая даёт больше свободы, и позвать программиста, который согласен не просто гуглить, а писать адекватное решение самостоятельно с нуля.
Олег Бунин, основатель компании «Онтико», организатор конференций Highload++, РИТ, FrontendConf, RootConf, WhaleRider, AppConf, Backend Conf.
Как организатор крупнейших в России конференций для разработчиков я вижу специализацию, упрощение рутинных процедур, но мозги и глубокое понимание происходящего востребованы не меньше, а даже больше, чем раньше.
С появлением автоматизирующих разработку инструментов ценность людей, которые понимают, что происходит под капотом таких инструментов, растёт. Требования, которые к ним предъявляются, растут. Объём знаний, который нужно освоить, растёт.
Конечно, речь идёт не о создании лендингов, а о разработке мало-мальски серьёзного проекта.
Макс Лапшин, создатель ErlyVideo, создатель Flussonic, разработчик многих известных решений в области стриминга видео.
Первый раз сообщения о том, что всё, что надо было написать, уже в целом написали, и теперь программисты просто будут собирать кубики из готовых компонент, и вообще, наверное, программировать мышкой, я услышал году примерно в 1995. Как несложно догадаться, с 1995 года по сегодня было написано безумное количество адского хардкорного системного кода, и возникло и умерло немало больших бизнес-платформ, на которых даже что-то было напрогано «мышкой».
Честно говоря, я даже ни разу не встречался с задачей, которую можно было бы напрогать «мышкой», не влезая до дна, но я не имею ровным счетом никакой связи с энтерпрайзной аутсорс-разработкой в стиле «Люксофта», поэтому не знаю, как оно у «них».
Всё дело в том, что индустрия идет вперед. Да, на компьютерах больше не 640 КБ памяти, и программисту под Windows больше можно не волноваться о памяти вообще. Но на замену большим компьютерам пришли маленькие, и их много.
Сегодня всё равно приходится думать, как записать на прошивку IP-камеры софт, упихнувшись в 200 КБ на диске. Приходится думать, как упихнуть код в маленький IOT-сенсор, который должен на своей крохотной батареечке прожить год с радиообменом.
Индустрия очень стремительно расширяется, и в ней появляется место людям, которые не очень глубоко разбираются в деталях работы ЭВМ, но безусловно: сегодня людей, которые знают, как работает, например, DMA, нужно больше, чем 10 лет назад просто потому, что индустрия до сих пор растет.
Александр Лямин, основатель и CEO компании Qrator Labs, одного из ведущих мировых поставщиков в области защиты от DDoS-атак.
Есть такая шутка: отдел программирования — это такой завод по производству холодильников, в котором работает 10 человек, один из которых может делать звездолёты, а остальные девять человек умеют клепать скворечники.
Так вот, программисты нужны в компаниях совершенно разного толка. Какие-то компании производят холодильники, какие-то — клепают скворечники, а некоторые, как SpaceX, действительно разрабатывают звездолёты. Поэтому пропорция 1:9, естественно, не догма, она везде будет своя. Где-то, действительно, достаточно нескольких кодеров в штате. Где-то нужны уже хорошие прикладные программисты — люди, обладающие алгоритмическим багажом и способные грамотно его применять.
В ряде случаев требуется уже даже не столько программист, сколько computer scientist — человек способный не только, как минимум, грамотно модифицировать алгоритмы под нужды конкретной ситуации и задачи. Следующий уровень — это data scientist, хороший прикладной математик. Продолжая аналогию, скворечник можно склепать из общедоступных стройматериалов, но сплавы для ракеты на строительном рынке уже не купишь. На этом уровне задача уже начинает выглядеть примерно так: вот проблема, вот массив данных, нужны гипотезы-алгоритмы-PoC и, как следствие, постановка задачи для реализации. И в процессе создания действительно хороших продуктов — рано или поздно, так или иначе — задачи нетривиальной обработки данных возникают неизбежно.
То есть человек-«кодер» решает лишь часть проблем, стоящих перед разработкой.
Естественно, действительно высококлассных программистов на рынке труда мало, а задач для них много, поэтому очень давно возникла идея: разработать инструментарий, с помощью которого специально обученный оператор ЭВМ сможет справиться с задачами высокой сложности. Но все попытки сделать это, можно сказать, провалились. Язык SQL был разработан изначально для того, чтобы им мог воспользоваться любой пользователь, даже не имеющий навыков программирования. Сейчас этим языком пользуются программисты, а операторы ЭВМ даже после тренингов не в состоянии написать даже более-менее простой запрос.
Другой пример — всевозможные среды визуального программирования, предназначенные, грубо говоря, для того, чтобы оператор мог не писать код, а нарисовать адекватную задаче блок-схему, на основе которой компилятор выберет нужные алгоритмы. Ни одна из таких сред (а их было много) в конечном счёте не получила распространения. Это говорит о том, что изначальная задача, возможно, поставлена неправильно или не имеет решения в такой постановке.
Закон дырявых абстракций свидетельствует: рано или поздно в процессе добросовестного решения прикладной задачи приходится опускаться на уровень ниже, чем позволяет практически любой прикладной инструмент.
Поэтому вряд ли когда-нибудь кому-нибудь удастся превратить программиста в оператора ЭВМ окончательно.
