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

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

Со временем сложность программных продуктов росла и возникла необходимость каким-то образом организовывать их структуру, чтобы при разработке не запутаться в десяти тысячах строках кода программы. Появилось объектно ориентированное программирование, деление на модули, организация в библиотеки.

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

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

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

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

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

Ах да, результатом возникшего объема базы кода становиться увеличенная база ошибок из-за человеческого фактора: в сотнях тысяч строк вероятность ошибок возрастает. Как следствие возникает, как класс орда тестировщиков. И образует не существующую до этого профессию.

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

Но эти знания относятся, скажем так, к инновационным продуктам “будущего”. Существует ряд областей в которых этот прогресс умышленно сдерживается. Одна из них это объекты физического мира, управляемые компьютерами: поезда, телевизоры, микроволновки. Цикл их жизни намного больше и выпуская телевизор нужно быть готовым поддерживать его работоспособность как минимум с десяток лет. Срок службы поездов например, полагаю еще больше, но обслуживать поезда произведенные 5 лет назад все еще нужно, несмотря на то что технологии шагнули далеко вперед с тех пор.