---
title: ""Парк юрского периода" глазами разработчика программ"
seoTitle: "Парк юрского периода глазами разработчика программ"
seoDescription: "Перечитывая "Парк юрского периода" Майкла Крайтона, у меня невольно возникли ассоциации с процессами производства программного обеспечения"
datePublished: Thu Jan 26 2023 14:50:41 GMT+0000 (Coordinated Universal Time)
cuid: cldd7pvwl000009l1b1r7hriz
slug: park-yurskogo-perioda-glazami-razrabotchika-programm
cover: https://cdn.hashnode.com/res/hashnode/image/stock/unsplash/G20Xr__6-Gg/upload/ef50f578739fef32b246f3de9d944736.jpeg
tags: books, software-engineering
---
Перечитывая "Парк юрского периода" Майкла Крайтона, у меня невольно возникли ассоциации с процессами производства программного обеспечения (ПО). И на самом деле этому есть причины. Парк с динозаврами обеспечивается комплексом сложных технических и программных средств, об особенностях которого автор очень старательно рассказывает. Давайте рассмотрим несколько моментов, которые мне показались наиболее интересными и характерными с точки зрения разработки ПО.
- Это очень сложная система, - сказал Арнольд. - Такие системы просто обречены на неожиданные поломки. Они в любой момент могут выйти из строя.
Бытует мнение, что разработка программ - это сложно. Более того, говорят, что сами программы и программные системы - это тоже сложно. Не буду спорить.
Стив Макконнелл в своей книге "Совершенный код" уделяет немалое внимание понятию сложности и пишет, что разработка программ по своей сути требует анализа всех деталей крайне сложного набора взаимосвязанных концепций. Именно сложным набором взаимосвязанных концепций и представляется парк юрского периода.
В парке можно выделить несколько концепций или, лучше сказать, систем:
-
Зоопарк. Парк юрского периода имеет все атрибуты зоопарка: животные, их ограниченные места обитания и соответствующая система безопасности.
-
Парк развлечений. Наравне с наблюдением за животными, посетители могут активно проводить время.
-
Научно-исследовательский центр. В парке содержатся животные, о поведении и привычках которых практически ничего не известно. То есть в системе присутствует неизученная область, требующая исследований и тщательной проработки.
Не трудно заметить, что каждая из составляющих парка сама по себе является сложной системой. Это явным образом отражается на сложности всего элемента. Подливает масла в огонь и инновационность парка: такого прежде никто не делал, с таким прежде никто не сталкивался. Опыт разработки сложных программных систем подсказывает, что инновационные системы неизбежно сталкиваются с проблемами и ошибками. Что, кстати, наглядно демонстрирует сюжет книги.
- Значит, хаос - это все случайное и непредсказуемое? Я правильно понимаю? - спросил Дженнаро.
- Нет. На самом деле мы находим скрытые закономерности в совокупности изменений состояния сложных систем.
Один из персонажей произведения, математик, увлекается теорией хаоса и описывает парк как нелинейную систему. Особенность нелинейных систем состоит в том, что такие системы очень сильно зависят от изначальных условий.
Если выстрелить из пушки ядром под определенным углом к горизонту, а потом выстрелить следом таким же ядром еще раз, то второе ядро упадет примерно в том же месте, где и первое. Такую систему в некотором приближении можно назвать линейной.
Теперь возьмем погоду. Если запустить одну погодную систему с определенными начальной температурой, скоростью ветра, влажностью и т.д., а затем запустить вторую с практически такими же параметрами, то с течением времени состояние систем будут расходиться все сильнее и сильнее. Дойдет до того, что в одной погодной системе мы будем наблюдать грозовую активность, а в другой - ясное солнце. Нелинейные системы крайне чувствительны к начальным условиям. Именно поэтому предсказать погоду практически невозможно. До сих пор прогноз погоды - это лишь слабое приближение к истине. И чем дальше делается прогноз, тем сильнее падает его точность.
Рассматривая парк как нелинейную систему, математик считал, что даже незначительное изменение условий его функционирования может привести к катастрофическим, непредсказуемым последствиям.
Нелинейная система является крайне сложной системой, так как невообразимое количество параметров влияют на ее текущее состояние. Увеличение возможностей по изменению состояния системы повышает вероятность появления ошибок и непредсказуемого поведения. Это утверждение применимо не только к сложным системам, но и к единичным программным средствам, их модулям, классам и функциям. Чем больше в классе неконстантных методов, тем он более нестабилен. Чем больше в функции входящих параметров, тем она более нестабильна. Думаю, логика ясна.
- Эти легкие наземные вездеходы с электроприводом были специально построены для нашего парка... Мы надеемся, что со временем можно будет ездить на машинах прямо среди животных, как в национальных парках Африки. Ну, а пока мы можем предложить насладиться только экскурсией по заранее проложенному маршруту.
Когда из-за отключения электричества экскурсионные автомобили замерли рядом с вольером тираннозавра, я подумал, почему инженеры не сохранили возможность перехода в ручной режим управления автомобилем. Поводов для этого несколько: автомобили уезжают достаточно далеко вглубь парка, выходить из автомобилей запрещено правилами, техника "сырая" и не обкатанная. Хотя с последним можно поспорить, мы точно не знаем сколько до этого отработали машины. Было бы неплохо на первых порах иметь подстраховку и отправлять в экскурсию автомобиль с водителем, который при неполадках мог бы сгладить положение.
Если мы говорим об инновационных проектах с высоким уровнем автоматизации, то необходимо обрабатывать ситуации, связанные с отказом или некорректной работой автоматики. Особенно это актуально для реал-тайм систем. Подобные ситуации могут быть решены переходом в ручной режим, либо исключением проблемного участка из рабочего процесса. Хороший пример - привязки курсора в графических редакторах. Иногда из-за активирующейся привязки курсор мыши "прилипает" к какому-то элементу, что мешает позиционированию. Отключение привязок решает проблему.
- Ну... У нас тут некоторые проблемы, кое-какие задержки... Достаточно будет сказать, что у меня здесь определенные затруднения, и я бы хотел, чтобы вы взглянули на мой остров. И высказали свои соображения...
Все мы знаем о важности тщательного и всеобъемлющего тестирования программ. Именно тестирования в тестовом окружении, а не в продакшене. С одной стороны, тесты это дорого. Но с другой - дороже ли это потенциальных издержек. Здесь нужен баланс. Чем выше требования к качественным показателям системы, тем большего внимания требует этап тестирования.
По стечению обстоятельств, катастрофа, произошедшая в парке, имела место до открытия парка, то есть на этапе тестирования, проверок. В парке находились обслуживающий персонал, инженеры, проверяющая комиссия... и внуки генерального. Всё. Случись подобное во время штатной работы парка, масштабы катастрофы были бы совершенно другими.
- Кстати, как там главный компьютер? - поинтересовался Хаммонд и глянул на Денниса Недри, который работал за терминалом в углу комнаты. - Этот чертов компьютер вечно преподносит нам сюрприз за сюрпризом.
- Уже все в порядке, - сообщил Недри.
- Если бы вы с самого начала сделали все нормально... - начал Хаммонд, но Арнольд остановил его.
В разработке ПО под техническим долгом мы понимаем недоработки, накопленные в проекте. Недоработки, зачастую, умышленные. Обычно технический долг возникает в проекте после фразы: "Эта фича нужна нам прямо сейчас, потом зарефакторим". В дальнейшем такие "фичи" могут затруднять или делать невозможным внесение новых правок в код, а процесс "потом зарефакторим" так никогда и не происходит.
Понятно, что технический долг будет всегда. Это неизбежный элемент процессов разработки. Разработчикам важно помнить обо всех долгах и время от времени проводить по ним расчет.
Система парка юрского периода ярко демонстрирует нам примеры технического долга. Один из них - дефект в системе электронных замков. Инженерам давно было известно, что электронные замки дверей работают только от основного источника питания. При переключении на резервный источник замки остаются отключенными - иди кто хочешь и куда хочешь. Это серьезный дефект, учитывая специфику парка и определенную секретность лабораторных разработок. Несмотря на это его так и не потрудились исправить. Видимо, понадеялись на бесперебойность основного источника питания. Так же как и с экскурсионными машинами...
- Это еще что за чертовщина?!
- У нас появился лишний компи...
- Но откуда?!
- Да не знаю я!
Дональд Кнут говорит: "Преждевременная оптимизация — корень всех зол". Как бы нам не хотелось улучшить ресурсоемкость нашей программы, сначала необходимо убедиться, что это действительно нужно здесь и сейчас. Подтверждает вышесказанное и Герб Саттер: "Первое правило оптимизации: не оптимизируйте. Второе правило оптимизации (только для экспертов): не оптимизируйте ни в коем случае. Семь раз отмерь, один раз оптимизируй."
Рассмотрим проблему оптимизации программы в системе мониторинга количества особей динозавров в парке. Задача системы - подсчитывать особей каждые 5 минут. Если вдруг какой-то из динозавров пропадет, система забьет тревогу. Главная проблема системы подсчета оказалась в том, что она была рассчитана только на учет потерь среди динозавров. Когда система находила заданное количество динозавров, то поиск прекращался. Это было сделано для ускорения выполнения программы. Динозавры не могли физически размножаться, поэтому никто и не думал, что их может оказаться больше заданного количества. Опасались только того, что животные могут быть несанкционированно вывезены с острова. И когда при подсчете был задан заведомо высокий порог, программа насчитала несколько десятков “лишних” особей. То есть оптимизации могут приводить к изменению алгоритма работы программы, которое порой сложно обнаружить. Любая оптимизация должна быть взвешенной и тщательно протестированной. Тестировать в таком случае нужно не только ожидаемое поведение, но и крайние случаи.
Только сейчас Арнольд с ужасом обнаружил, что полная программа парка юрского периода содержит более полумиллиона строчек кода, и большая часть из них нигде не задокументирована, а остальные идут без каких-либо пояснений.
Мы, разработчики, любим читать хорошую документацию и ругать проекты со скудными руководствами. При этом в своих проектах мы, разработчики, любим следовать таким советам: хороший код документирует сам себя, хорошие автотесты документируют код и т.п. То есть мы делаем все, лишь бы меньше писать документацию. И не стоит здесь дискутировать о том, что мы, разработчики, должны писать код, а не документацию, для документации есть технические писатели... Речь не об этом.
С документацией, как и с тестами, нужен баланс. Небольшие проекты для внутреннего пользования, реализуемые в течение недели, действительно могут вообще обойтись без документации. Но при росте размеров проекта, при необходимости поддержки проекта, и тем более, при наличии у проекта публичного интерфейса, ценность документации возрастает.
Как выяснилось, документации к программному коду парка юрского периода практически не оказалось. Более того, основной разработчик Недри оставил ряд "пасхалок" с таким именованием сущностей, значение которого известно только ему одному. В итоге, когда Недри не оказалось рядом, разобраться с программным кодом оказалось крайне затруднительно.
По-моему, здесь художественный вымысел представлен во всей красе. Сложно вообразить, что проект такого уровня может страдать от крайнего безобразия с документацией. Но не будем недооценивать творческие способности нас, разработчиков.
Эрик Тополь в одном из своих трудов говорит, что футурологи - это люди, которые, услышав о том, что братья Райт поднялись в воздух, способны предвидеть бюджетные авиарейсы, крупные аэропорты и людей, высадившихся на Луне. Эти историки настоящего начинают свое исследование с того, что происходит сегодня; эти люди спрашивают не о том, как избежать ошибок прошлого, а о том, как приумножить достижения настоящего.
Именно поэтому привлекательна фантастика. Навязчивый вопрос: "А что будет, если... ", всегда беспокоит пытливые умы. Историки настоящего, равно как и историки прошлого, помогут найти подходящие ответы.
Наблюдайте, исследуйте и приумножайте.