Почему разработчик — не инженер

Когда человеку «с улицы» пытаются объяснить, что такое разработка софта, то часто приводят аналогии с постройкой дома, самолета или другого физического объекта. Эти наглядные примеры, по идее, должны были бы упростить понимание сути разработки. Но получается как с «Hello, world» — вроде просто и доступно, но сути не раскрывает. А то и вовсе вводит в заблуждение.

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

На первый взгляд кажется логичным представить создание программы как постройку физического объекта. Ведь даже сам термин «ООП» подразумевает наличие взаимодействующих объектов. Да и названия некоторых шаблонов проектирования всё так же намекают на аналогию с производством: Bridge, Facade, Decorator, Builder и так далее.

На связь разработки со производством намекают не только традиционные модели производства, которые из физического мира перекочевали в мир виртуальный — как, например, Waterfall и Kanban, но и сленг разработчиков — «запилить», «пофиксить», «поставить патч», «форкнуть». Как будто мы и правда имеем дело с табуреткой или краном, которые можно починить. Добавляет смуты и повсеместное использование термина software engineer. Как здесь не проводить параллели с инженерным искусством, если даже в трудовой пишут «инженер-программист первой категории»? Аки токарь второго разряда.

Но разработка софта — это не инжиниринг.

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

Насколько хорошо изучен мир виртуальный?

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

Тогда как виртуальному миру всего несколько десятков лет. У него нет предыстории, нет накопленного опыта, и он продолжает быстро меняться. Все равно как если бы то появлялся, то исчезал четвертый закон Ньютона, константы прыгали туда-сюда, то и дело добавлялись бы новые измерения. Здесь уж не до Waterfall’а.

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

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

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

Как ходить по минным полям

В разработке всё иначе. Если бы разработчик попытался понять, почему его виртуальный Боинг упал, то вряд ли бы он ограничился механикой и сопроматом. Брать пришлось бы много шире: «Что, если в момент полета выключилась и включилась гравитация?», «Что, если самолет врезался в ледяные облака?», «Что, если один из пилотов уронил на пол чашку кофе, и это вызывало резонанс во всей конструкции самолета?».

В виртуальном мире измерить почти ничего нельзя, зафиксировать — тоже. Каждая поделка уникальна — даже если это сайт-визитка. По этой причине продолжается постоянное наступание на грабли. Хоть это и пытаются исправить авторы книжек «Best Practices», которые больше напоминают руководства в духе «Что делать, чтобы не облажаться» или «Как ходить по минным полям».

Можно ли назвать разработчика инженером?
Жирную точку в этом вопросе ставит Джефф Этвуд из Coding Horror:
Я не думаю, что строительство моста имеет хоть что-то общее с разработкой. Это обманчивое сравнение. Они могли быть похожи только в том случае, если бы мост строили на Юпитере, из только что изобретенных материалов, используя строительное оборудование, которого не существовало пять лет назад.

Развить мысль Джеффа можно этой картинкой:

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

Как себя представлять — дело личное. Лишь бы слово «инженер» не опопсело так же, как «дизайнер» или «менеджер», которые сегодня пихают куда ни попадя, плодя всё больше недоразумений. Когда даже некоторые технари до конца не понимают, кто такой UX designer.

А вы кем себя считаете?

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU