В курсе системного мышления, в разделе 4, много внимания уделяется вопросу “как именно думать про компьютерные программы как системы”.
Сначала в курсе говорится, что софт в момент работы вполне физичен. Он занимает в оперативной памяти компьютера какое-то место, он меняет свое состояние во время работы, приводит к намагничиванию и размагничиванию каких-то точек физического пространства. Но потом приводятся примеры: целевой системой разработчиков софта для выдачи зарплаты предлагается считать выданную зарплату. Разработчиками софта для расчета моста предлагается думать именно о строящемся мосте.
Понятно, что это упрощенные примеры для иллюстрации, но, по моему мнению, главы про софт создают ложное впечатление, что у большинства разработчиков целевой системой будет какой-то объект реального мира, а не какое-то описание::набор_байт. Мимоходом, одной строкой, в курсе приводится пример издателя книги, которого не волнует, к чему отсылает текст книги, его волнует именно физическое воплощение книги, чтобы каждая молекула чернил, из которых состоят буквы, была на своем месте. Так вот, в моем информационном пузыре, чаще целевой системой разработчика будет именно какой-то физический набор байт, описывающий мост, а не сам мост, я чаще встречаюсь с типографами, что печатают книги, не обращая внимания на их содержание, чем с писателями, пытающимися передать какой-то смысл через текст.
Возьмем пример с мостом. Никто не пишет софт для проектирования конкретного моста. Проектировщики моста берут какой-то существующий софт, например Автокад. Так что будет целевой системой разработчиков Автокада? Нельзя считать их целевой системой конкретный мост, потому что они не могут знать, какой именно конкретный мост будет проектировать каждый из тысяч пользователей Автокада. Иногда даже никакого моста и не предполагается, а Автокад нужен, чтобы сделать и защитить курсовой проект по проектированию мостов. Так как думать об автокаде разработчикам автокада? Как я считаю, их целевой будет некоторая документация::физический_объект в виде байт на диске. То есть Автокад это система для создания описаний::физических_объектов каких-то других систем, не важно каких.
Даже в случае с прикладными разработчиками софта я не считаю, что тянуться мыслью до “непоправимой пользы миру” будет всегда полезно. Пусть я какой-то строительный девелопер. Я хочу построить дом и продать в нем квартиры. Моей целевой системой будет, допустим (тут я могу ошибаться, но мне не кажется сейчас это важным для примера) набор семей, которые въезжают в свое новое жилье. Для своих продаж я нанимаю человека, который сверстает мне лендинг, которым я буду привлекать покупателей. Хочу ли я, чтобы целевой системой этого человека-верстателя лендингов была моя целевая система “счастливые семьи, заезжающие в новое жилье”? Нет, я хочу чтобы он сверстал мне веб-страницу, в точности такую, как в переданном ему дизайне. Я точно не хочу ничего рассказывать ему про дом, который я строю, про свою целевую аудиторию, про то как дом будет оформлен юридически, про ценообразование квартир (хотя меня как девелопера это все очень волнует). Я хочу чтобы целевой системой верстателя лендингов был лендинг::физический_объект в виде сервера::программы, запущенной на каком-то сервере::компьютере, раздающей на устройства пользователей файл html, который браузер пользователя отрендерит в точности так, как было в дизайне лендинга. И я заплачу этому верстателю деньги, когда увижу на своем компьютере свой лендинг, а не когда продам все квартиры. Про строящийся дом и целевую аудиторию я скорее расскажу дизайнеру лендинга, чтобы он учел все это в дизайне, добавил всю информацию, которая может быть интересна клиентам на этапе просмотра лендинга. Но его и его целевой системой я бы назвал “дизайн::документация::физический объект в виде набора байтов”, а не мои продажи, деньги я заплачу ему именно за файлик фигмы/pdf/photoshop.
Это я все к чему? В предыдущей команде я занимался разработкой одной специализированной базы данных. В моей компании было примерно пять других систем, которые хранили свои данные в нашей базе. Прочитав этот раздел курса в первый раз, я решил, что мне нужно “дотянуться мыслью до реального мира” (потому что сложно понять, где физический мир в базе данных. У нас даже своих данных не было, мы храним любые данные), “раскрутить цепочки обеспечения”. Я потратил на это несколько месяцев, пытался вникнуть в то, как работает рекламная сеть яндекса (наш самый большой клиент). Когда составил общую картину, то понял, что я ничего не узнал о своей системе. Полученные знания не помогли бороться со сложностью моей базы (а сложность там очень большая)
Сейчас я работаю в команде мониторинга. Мы собираем данные телеметрии с любых работающих в датацентрах программ и даем возможность понять, что с этими программами происходит в какой-то момент времени. Мне повезло, что клиентов у мониторинга многие сотни и мысль “дотягиваться до реального мира” через клиентов моей системы я отбросил сразу. Пришлось перечитать материал. Пока я решил для себя, что физического мира в виде запущенных на сервере программ и данных в виде байт на диске мне вполне достаточно.
Я пока не смог описать свою целевую систему, пост скорее для таких-же разработчиков-типографов, как и я, которые после прочтения четвертого раздела курса могли почувствовать себя обманщиками, получающими деньги ни за что, потому что не могут точно сказать где же те мосты и зарплаты, которые должны их волновать. Ну, или я ничего не понял и написал глупость, думаю меня поправят в комментариях.