Что такое «инженерия» с точки зрения программиста?

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

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

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

Как можно применить такой инженерный подход в разработке ПО?

Я определяю инженерию так: это «применение эмпирического научного похода, чтобы найти эффективные решения практических задач». Упоминание «научности» здесь важно. Необходимо перебирать варианты, так у нас будет больше возможностей учиться. Нам нужно собирать обратную связь, чтобы можно было поразмышлять над результатами. Требуется работать поэтапно, чтобы можно было членить стоящие перед нами задачи и эффективно их исследовать. Нужно организовать нашу работу как цепочку небольших и безопасных экспериментов – так, чтобы можно было нарабатывать знания более продуктивно. Мы должны снимать данные с реальных систем, чтобы можно было эмпирически выяснить, что работает, а что нет.

Это инструменты научного рассуждения. Инструменты настоящей «инженерии».

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

Софтверная индустрия кажется нам примером прогресса, но этот прогресс во многом иллюзорный. В книгах по программированию, изданных в 1970-е, 1980-е и 1990-е зачастую обсуждаются те же самые проблемы, с которыми доводится сталкиваться сегодня, но в иных выражениях. В книге «Мифический человеко-месяц» Фреда Брукса рекомендуется работать поступательно и сообща, объединяясь в небольшие команды – а она вышла в оригинале более 50 лет назад.

Основные парадигмы программирования, включая как объектно-ориентированное программирование, так и модное сегодня функциональное программирование получили признание и в основном были определены ещё ранее. Lisp, первый язык для функционального программирования, был изобретён в 1958 году и до сих пор используется в виде Clojure, Scheme и других диалектов.

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

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

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

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

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

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

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

Как инженерия улучшает софт

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

Разные люди по-разному об этом говорят. Многие называют такой подход DevOps, я же предпочитаю термин «непрерывная доставка», поскольку он точнее описывает ситуацию. Но названия тут не так важны. Это и есть «инженерия для программ».

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

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