Системное мышление 2019

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

Ещё раз подчеркнём: программу следует считать воплощением системы только в тот момент, когда она реально запущена на исполнение и работает, делает то, ради чего она была написана. Это довольно контринтуитивно, но исходный код программы – это не программа, но только описание программы; исходный код программы в системе управления версиями или просто в файле на носителе – это только документация программы. Программа – это то, что отражает состояние программы в момент её исполнения.

Поэтому программисты, которые считают, что их инженерная работа закончена в момент написания исходного кода – эти программисты глубоко неправы, и это типичная ошибка. Из признания этой ошибки появилось целое движение DevOps64 – программисты признали, что они должны выполнять роль не только разработчиков кода программы (Development), но и сопровождением работы программы на рабочих серверах (Operations).

Исходный код – это описание программы (оно делается в классах, как любое проектирование, один исходный код описывает множество возможных экземпляров программы), и перед использованием программы её нужно изготовить: откомпилировать, собрать, разместить в оперативной памяти нужного компьютера (возможно, перед этим оформив в какой-то контейнер) и передать на неё управление.

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

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

Ещё одна ошибка – это считать программу целевой системой, ибо регулярно в корпоративной разработке софта клиенты ожидают не столько корректную работу компьютера, сколько корректную работу той части организации, которую должен этот компьютер поддержать. Люди в организации должны вместе с программой сработать по какому-то организационному алгоритму. Такой совместный поток работы людей и компьютеров называется обычно workflow, хотя сейчас его чаще называют оргпроцессом. Чаще всего программа – это только часть этого оргпроцесса. Но для того, чтобы клиент смог получить результат оргпроцесса, эту программу нужно настроить, дать ей какие-то данные, научить с ней работать сотрудников и проверить не столько работу самой программы, сколько работу всего оргпроцесса в целом. Никого не волнует работа программы начисления зарплаты, волнует начисление зарплаты – и если начисления зарплаты не произойдёт, то программистам трудно будет объяснить, что с их программой всё в порядке, а неправы все остальные. Поэтому в проектах по разработке программ очень часто есть части по работе с людьми (обучение работе с программой: нужно «изготовить» те части людей, которые смогут делать что-то полезное с программой) и данными, с которыми будет работать программа.

Как найти настоящую целевую систему, которую изготавливают программисты в конечном итоге? Ибо даже работающая программа оказывается часто работающей с описаниями и документированием описаний какой-то другой системы, нежели реальной системой, изменяющей физический мир!

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