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

По большей мере — для них это приятный опыт, так как в моей компании есть бесплатная еда, пинг-понг, и нет никаких домашних заданий.

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

Единственное, что тех. компании не работают на больших скоростях, несмотря на то, что говорят престижные вакансии. Стажеры часто удивлены, или даже насторожены тем, что им дали такой маленький объем работы: «Я тут уже 3 месяца, а вы хотите, чтобы я только сделал эту жалкую панель?». Они начинают мечтать о том, как потрясут всех перевыполнением задач — закончат весь проект за пару недель; а потом, в оставшееся время, сделают что-то стороннее. На деле же выходит так, что спустя 3 месяца, они спешат представить урезанный и кое-как работающий продукт.

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

Тогда почему у них так не получается? Легко обвинить корпоративную бюрократию в неповоротливости: планирования, собрания и другие временные расходы.

Конечно, это играет свою роль, но это половина правды. Большим препятствием являются молодые фантазеры, которые думают о коде вот так:

Это не совсем так — стажеры умны. Они знают, что кодировать в компании, и кодировать в университете — это разные вещи. Они готовы потратить больше времени на то, чтобы прокомментировать свой код, проверить и протестировать его. Тем не менее, они не осознают, на какую глубь уходит этот айсберг.

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

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

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

Даже простые вещи могут трансформироваться в большие начинания.

Например, если вы планируете хранить пользовательские данные на сервере, то перед запуском вам нужно будет:

• Реализовать резервное копирование данных (бэкапы), чтобы не утратить доверие пользователей.
• Разрешить пользователям удалять свои данные в любое время, в том числе из бэкапов.
• Разрешить пользователям загружать их собственные данные и метаданные в соответствии с политикой конфиденциальности.
• Разработать свою систему хранения в соответствии с прочими законами, такими как закон об использовании персональных данных и использовании cookies.
• Для зарубежного рынка нужно соблюдать соответствие таким политикам как: HIPAA (Health Insurance Portability and Accountability Act — закон о мобильности и подотчётности медицинского страхования); FISA (The Foreign Intelligence Surveillance Court — суд США, занимающийся наблюдением и обыском в следственных интересах внешней разведки; EUs Data Locality policy (неформальное локальное хранение данных о гражданах и резидентах стран ЕС).
• Переносить существующих пользовательские данные по мере изменений в схеме базы данных или системах хранения.
• Мониторить бэкапы на предмет сбоев, пользовательских лимитов и брешей в безопасности.
• Контролировать доступ к пользовательским данным со стороны операторов службы поддержки.

Если руководствоваться примером выше, то можно удивиться, если любой стажер может закончить такой проект за один квартал.

Как же тогда это сделать?

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

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

На самом деле, наши величественные айсберги кода можно писать и поддерживать только благодаря невероятным инструментам, доступным современным разработчикам. Таким как:

• Компиляторы, операционные системы, базы данных, библиотеки и API;
• Системы управления версиями, средства отслеживания ошибок, отладчики и IDES (интегрированные среды разработки);
• Генераторы документации, СУБД, приложения для создания блок-схем и сервисы, позволяющие получить помощь по вопросам программирования, вроде StackOverflow;
• Сканеры безопасности, статические анализаторы, скрипты автоматизации, шаблоны;
• А также интерактивные доски, видеозвонки, электронные письма, корпоративные мессенджеры, и даже клавиатуры, мышки и мониторы.

Вот и получается, что под поверхностью нашего айсберга скрывается целый айсберг! У нас получился четырехмерный «мета-айсберг».

Этот новый мета-айсберг по-прежнему состоит из кода, но не персонализированного под ваш проект. Вы можете запускать готовый сервер базы данных или внедрять свою инфраструктуру в облаке, можете писать свой пользовательский интерфейс на React, Angular или Svelte. И такие решения по большей части не повлияют на работу вашего приложения, но определенно повлияют на скорость разработки вашей команды и ее способность оперативно реагировать на проблемы. Плохие или неправильные инструменты, могут дорого вам обойтись.

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

Почему это так много значит?

Что общего у Uber, AirBnb, Tesla, WeWork, Netflix, Betterment, Flexport и Amazon?

Все они позиционируют себя как высокотехнологичные компании — разработчики программного обеспечения, в то время как зарабатывают деньги в таких «старых» отраслях, таких как транспорт, недвижимость, контент и розничная торговля.

Отчасти это хитрость, на которую идут для привлечения венчурного капитала, но дело не только в этом. Все эти компании поставляют программное обеспечение и используют его, чтобы отличаться от общепринятых фирм-конкурентов. Когда эти «дойные» фирмы-конкуренты пытаются выпускать собственное программное обеспечение, они часто терпят неудачу. Ведь компании, ориентированной на программное обеспечение, легче перейти к традиционным отраслям, чем традиционной компании — к программному обеспечению.

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

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

Тем временем, однако, компании, ориентированные на программное обеспечение, вкладывают средства в то, чтобы привнести больше фрагментов кода-айсберга в свои компании.

• AirBnB поддерживает популярную библиотеку анимации;
• Netflix создала собственную CDN с использованием специализированного оборудования;
• Uber открыл исходный код под названием «Гексагональная иерархическая система геопространственного индексирования» в числе других проектов;
• Amazon, гигант розничной торговли, настолько увлекся программным обеспечением, что теперь продает свою инфраструктуру конкурентам. Эти конкуренты, даже имея в своем распоряжении всю мощь AWS, по-прежнему будут бороться за конкуренцию в программно-ориентированном мире. Amazon это знает, иначе они были бы более избирательны по отношению к тому, кто будет использовать их материалы.

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