Думаю, что после прочтения статьи Никиты Прокопова «JavaScript Bloat in 2024» (рус. «Насколько потолстел JavaScript к 2024 году?») не я один стал с пессимизмом смотреть на будущее веб-разработки. Хотя тема раздутия JavaScript не нова (одним из первых на эту проблему обратил внимание Эдди Османи в своей статье-отчете «The Cost Of JavaScript» (рус. «Сколько стоит JavaScript?») в 2017 году), но здесь поражает масштаб проблемы, обозначенный автором статьи.

Нечто подобное было с HTML (и в какой-то степени с графикой) на ранних этапах развития Всемирной паутины (далее веб). Проблему раздутия HTML удалось практически полностью решить к середине 00-х за счет внедрения веб-стандартов и совершенствования WYSIWYG-редакторов HTML. Появление технологии AJAX и одностраничных приложений (SPA) сместило акцент на JavaScript, но это не привело к мгновенному утяжелению веб-приложений (например, первые версии Gmail прекрасно работали даже на самых медленных dial-up-соединениях).

Ситуация начала меняться в худшую сторону где-то на рубеже 00-х и 10-х, когда стали появляться первые смартфоны. Разработка ПО стала постепенно усложняться, дорожать и носить более конвеерный характер. Начался массовый найм разработчиков, повсеместное внедрение гибких методологий разработки и стала расти доля работы, отдаваемой на аутсорс. В веб-разработке наступила эпоха фреймворков и инструментов сборки для фронтенда. Со временем подходы, которые были призваны снизить порог входа в профессию, временные и финансовые издержки, стали давать обратный эффект.

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

Джеффри Зельдман

Самый известный веб-дизайнер в мире, король веб-стандартов

Джеффри Зельдман получил магистерскую степень в области литературы в Виргинском университете. В начале своей карьеры он работал репортером в Вашингтон пост, а затем 10 лет копирайтером в рекламной индустрии. Он пришел в веб-дизайн в 1995 году, когда ему уже было 40 лет. Свой первый веб-сайт Зельдман сделал, когда работал в рекламном агентстве Grey Entertainment, вместе со своими коллегами Стивом Маккэрроном и Алеком Поллаком. Это был промо-сайт фильма «Бэтмен навсегда». Сайт пользовался большой популярностью: его посетили примерно 1,5 миллиона человек, т.е. половина тогдашней аудитории веба.

В 1998 году, в самый разгар браузерных войн, он стал со-основателем организации Web Standards Project (сокращенно WaSP), первоначальной целью которой было убедить производителей основных браузеров поддерживать рекомендации W3C. Войны браузеров привели к удорожанию создания веб-сайтов и риску потери доступа к нужному контенту и услугам для некоторой части пользователей. В те годы создание 4 и более несовместимых версий веб-сайта увеличивало стоимость его разработки по меньшей мере на 25%. Когда в 2000 году лопнул пузырь доткомов и бюджеты на поддержку сайтов стали усыхать, WaSP удалось объединить вокруг себя широкие массы веб-дизайнеров. В 2001 году, когда браузерные войны практически закончились, WaSP начала смещать фокус своего внимания. Часть ее членов продолжали работать с производителями браузеров, другие начали сотрудничать с производителями инструментальных средств (например, Macromedia Dreamweaver), а третьи занялись образовательно-просветительской деятельностью среди веб-разработчиков. В 2013 году миссия WaSP была выполнена, и организация была упразднена. Часть ее членов перешла на работу в W3C.

Кроме того, Зельдман получил широкую известность как автор книг и многочисленных статей по веб-дизайну. Он талантливый писатель, умеющий излагать сложные технические вещи на языке, который понятен даже людям далеким от технологий. Его литературный стиль немного резок и в его текстах практически всегда присутствует юмор (кстати, стиль ранних статей Артемия Лебедева во многом похож на стиль Зельдмана). Сначала он публиковал статьи по веб-дизайну на своем личном сайте, а затем стал со-основателем онлайн-журнала A List Apart. Его книгу «Designing with Web Standards» (рус. «Web-дизайн по стандартам») индустрия веб-разработки восприняла как откровение, она выдержала два переиздания и была переведена на 15 языков.

В 2018 году Зельдман написал статью «The Cult of the Complex» (рус. «Культ сложности»), в которой он рассказывает о том, как фронтенд-фреймворки усложнили процесс вертки веб-сайтов, привели к разбуханию кода и даже сравнивает их результирующий код с плохим HTML из середины 90-х. Также он затрагивает болезненную для многих тему найма в IT:

Действительно, многие дизайнеры и разработчики, с которыми я общаюсь, скорее станцуют голышом на публике, чем признаются, что разместили сайт, созданный с помощью закодированного вручную прогрессивно-улучшаемого HTML, CSS и JavaScript, которые они понимают и написали сами. Для них это вопрос гарантии занятости и жизнеспособности. Есть своего рода страх, что если вы не осваиваете дюжину новых фреймворков и инструментов каждый год (а под освоением я подразумеваю использование), то вы отстаете и становитесь ненужным. Люди из HR сферы, которые пишут должностные инструкции с перечислением десятков тысяч наборов инструментов, которые вы должны знать вдоль и поперек, чтобы претендовать на должность junior frontend-разработчика, не помогают ситуации.

Дуглас Крокфорд

Программист, гуру JavaScript

Дуглас Крокфорд получил степень бакалавра в области радио и телевидения в Университете штата Калифорния в Сан-Франциско. Во время учебы он посещал занятия по Фортрану и работал в университетской компьютерной лаборатории. За свою профессиональную карьеру он успел поработать на многих должностях, связанных с IT, в компаниях из различных сфер деятельности: науки, разработки ПО, геймдева, кинематографа и Интернета.

В первую очередь, Крокфорд известен как автор формата JSON и ряда open source-библиотек и инструментов (JSMin, JSLint, json2.js и др.). Как правило, код open source-проектов Крокфорда лаконичен, а их функционал остается актуальным достаточно долгое время. Например, минификатор JSMin теоретически способен сжимать любой C-подобный код, благодаря этому он нечувствителен к изменениям, которые вносятся в JavaScript с появлением новых спецификаций ECMAScript.

В 2008 году вышла книга «JavaScript: The Good Parts» (рус. «JavaScript: сильные стороны»), которую Крокфорд написал во время своей работы в Yahoo!. Эта книга убедила многих разработчиков пересмотреть свое отношение к JavaScript в лучшую сторону. Еще эта книга известна тем, что в июле 2015 года она была запрещена в тюрьмах штата Аризона. Причина запрета не озвучена официальными лицами до сих пор, но есть предположение, что книга была отклонена ИИ из-за часто встречающегося в ней слова «evil» (встречается в тексте 16 раз).

В 2018 году вышла вторая книга Крокфорда «How JavaScript Works» (рус. «Как устроен JavaScript»). В отличии от предыдущей книги, эта книга рассчитана на более подготовленную аудиторию. В ней много программного кода, рассуждений о следующем языке, который должен прийти на смену JavaScript, и юмора. Автор также отмечает, что новые версии стандарта ECMAScript не помогают устранению серьезных проблем в JavaScript, а иногда приводят к появлению новых. Таким образом, за прошедшие 10 лет JavaScript стал более сложным и странным. В то же время Крокфорд не ограничивает тематику книги только языком JavaScript, он попутно затрагивает многие фундаментальные вопросы разработки ПО. Например, раздутость кода и ее взаимосвязь с организацией процесса разработки:

Одна из самых серьезных проблем в разработке программных средств — их тучность, или раздутость. Программы просто становятся слишком большими. Это может быть связано с неразумным выбором функций, но чаще всего становится следствием плохой архитектуры. Популярное средство повторного использования кода — наследование, но его работа оставляет желать лучшего, поэтому вместо него зачастую применяются копирование и вставка кода. Не следует сбрасывать со счетов и чрезмерную зависимость от библиотек, платформ и пакетов, тесно связанных со многими другими библиотеками, платформами и пакетами. Раздутость может быть побочным эффектом приемов гибкой разработки. Чтобы справиться с ней, увеличивают численность команды разработчиков, но это порождает еще большую раздутость.
…
Лучший способ справиться с раздуванием программ — не допускать его. Приоритетом при разработке и реализации программы нужно сделать ее «худобу». Следует избегать внедрения в практику раздутых пакетов и инструментов, способствующих раздуванию. Обходитесь без классов. Нанимайте небольшие квалифицированные команды разработчиков. И активно практикуйте удаление кода. Создайте резерв из нескольких циклов разработки с целью удаления ненужного кода и избавления от проблемных пакетов. Радуйтесь, когда количество строк кода в проекте уменьшается. Придерживайтесь принципа наименьшей раздутости.

Хидео Кодзима

Самый известный геймдизайнер в мире, гений

Хидео Кодзима учился в университете на экономиста. В 1986 году он бросил учебу, чтобы устроиться на работу в компанию Konami, где первое время занимался разработкой игр второго эшелона для семейства компьютеров MSX. На следующий год он стал руководителем и возглавил разработку стелс-экшена Metal Gear. Позже игра была портирована с MSX2 на консоль NES (без участия Кодзимы), где получила коммерческий успех. Успех Metal Gear положил начало одноименной серии игр, которая позволила Кодзиме сделать успешную карьеру в компании. Он проработал в Konami почти 30 лет и даже какое-то время занимал должность вице-президента. В 2015 году он покинул компанию и основал собственную независимую студию.

Всемирная известность пришла к Кодзиме в 1998 году после выхода Metal Gear Solid (3-я игра серии). Это была одна из немногих игр того времени, ход разработки которой активно освещался в прессе. К разработке игры в качестве консультантов было привлечено целое подразделение американского полицейского спецназа. Изначально все уровни проектировались и строились из деталей конструкторов Lego, и только потом попадали в саму игру.

Игра поражала своей кинематографичностью и нелинейностью сюжета. Чтобы шокировать игрока разработчики даже использовали периферийные устройства PlayStation (карта памяти и второй порт для геймпада во время поединка с Психо Мантисом). В 2012 году журнал Time включил Metal Gear Solid в список 100 лучших видеоигр в истории.

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

Вообще, в нашей стране Кодзима стал своего рода символом геймдева. Его имя затмило даже таких известных геймдизайнеров как: Сигэру Миямото, Йосики Окамото, Алексей Пажитнов, Джон Ромеро, Эд Бун и Джон Тобиас.

В 2019 году в Японии вышло 2-е издание книги Кодзимы «Sousakusuru Idenshi: Boku Ga Aishita Meme Tachi» (рус. «Хидео Кодзима. Гены гения» и англ. «The Creative Gen»). Как и в первом издании, автор рассказывает о своих любимых книгах, фильмах, комиксах, аниме и музыке, между делом раскрывая детали своей биографии. При переиздании из книги было убрано предисловие и две главы, но вместо них были добавлены «Введение», «Заключение» и «Диалог с Гэном Хосино». В трех новых разделах Кодзима рассказывает о создании своей собственной студии и процессе разработки игры Death Stranding:

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

P.S.: Годы карантина отодвинули обозначенные проблемы разработки ПО на второй план, а щедрое финансирование IT-отрасли позволило компаниям меньше задумываться об издержках. Но в случае, если наступит очередной экономический спад, то всем нам придется прислушаться к старшему поколению и сделать разработку снова простой!