Принцип Анны Карениной В Программировании И It



Принцип Анны Карениной в программировании и IT

«Принципу Анны Карениной» посвящено множество научных публикаций и даже отдельная статья в Википедии.

Применимо к ИТ и программированию? А может быть, он уже работает против вашего проекта? Я опубликовал первую версию этой статьи на своем английском языке.

блог и разместил ссылки на несколько узкоспециализированных форумов.

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

В статье рассматривается один из философских принципов, который, с точки зрения автора: а) объективно существует б) актуально для ИТ-проектов и программирования.

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

Недавно я перечитал великий роман Льва Толстого «Анна Каренина».

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

Но чтобы понять такие книги, их необходимо читать в зрелом возрасте, накопив достаточно собственного личного жизненного опыта и понимания человеческих характеров.

От главы к главе Лев Толстой описывает происходящие события, словно наблюдая их глазами того или иного участника событий.

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

И после прочтения романа остается впечатление, что иначе и быть не могло.

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

И каждое звено в этой жуткой цепи событий на момент прочтения кажется понятным и логичным.

Прочитав роман, каждый сможет решить для себя, что означает это загадочное, самое первое предложение романа:

Принцип Анны Карениной в программировании и IT

«Все счастливые семьи похожи друг на друга; каждая несчастливая семья несчастлива по-своему».

Одно из возможных объяснений состоит в том, что Лев Толстой в этом предложении сформулировал гораздо более общий философский принцип, который проявляется в медицине, социологии, биологии, глобальных геофизических явлениях и, на мой взгляд, в информационных технологиях вообще и программировании в частности.



Что означает принцип Анны Карениной?

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

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

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

Примечание.

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

Но это не меняет сути.

Парадоксально, но чем сложнее класс систем, тем меньше у него «успешных» комбинаций.

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



Принцип Анны Карениной и приручение животных, или ограниченные и вторичные параметры отбора

Британский учёный Фрэнсис Гальтон, живший в одно время с Толстым, при рассмотрении приручения животных сформулировал принцип, аналогичный принципу Анны Карениной:

Принцип Анны Карениной в программировании и IT

Кажется, что все дикие животные имели шанс одомашниться.

При этом немногие.

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

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

Джаред Даймонд «Ружья, микробы и сталь».

Глава 9. Зебры, несчастливые браки и принцип Анны Карениной этой книги начинается следующей фразой (в переводе на русский язык):

Все одомашненные животные похожи друг на друга, каждое неодомашненное животное по-своему неодомашненно.

Если вы думали, что где-то уже читали нечто подобное, вы не ошиблись.

Измените несколько слов, и вы получите знаменитое первое предложение из великого романа Льва Толстого «Анна Каренина»: «Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему».

Этой фразой Толстой хотел сказать, что счастливым может быть только тот брак, который состоялся во многих различных аспектах: между супругами имеется взаимное половое влечение, налажены отношения с родственниками друг друга, нет разногласий по поводу финансов, воспитания и воспитания.

дети, религия и другие жизненно важные вопросы.

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

Далее автор называет факторы, не позволившие, несмотря на многочисленные и продолжающиеся попытки, одомашнить диких животных.

Их немного: рацион, скорость роста, проблемы с размножением в неволе, «дикость» характера, склонность к панике, социальная структура.

Интересно отметить тот факт, что все перечисленные автором факторы являются «вторичными».

Например, человечество выращивает и забивает на мясо не носорогов (3 тонны мяса), а гораздо более мелких животных – коров, свиней и овец.

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

И мы бы уже наложили на них очень жесткие ограничения.

Если вам интересно, то найдите и прочитайте книгу.

Но автор объясняет действие принципа в конкретной предметной области.

Есть ли более широкое толкование?

Принцип хрупкости добра

Гениальный математик Владимир Арнольд в своей книге «Теория катастроф» попытался взглянуть на проблему с более широкой и в то же время чисто математической точки зрения.

Там он описывает т. н.

«Принцип хрупкости добра» .

Он пишет:

Принцип Анны Карениной в программировании и IT

.

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

Это проявление общего принципа, согласно которому хорошие вещи (например, устойчивость) более хрупкие, чем плохие.

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

.

В контексте, который он рассматривал, Владимир Арнольд, возможно, был прав.

Но в более широком контексте можно увидеть, что на самом деле он говорит о хрупкости или, точнее, о редкости устойчивости, а не о «доброте».

Не все, что нестабильно, плохо, и не все, что стабильно, хорошо.

Меня поймет тот, кто хоть раз в жизни переходил лужу или канаву на бревне.

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

С другой стороны, любое движение – это скорее нестабильность.

Деревья и цветы хороши, пока они живы и растут, но засушенные обычно нет. И в то же время о дереве, которое растет сотни лет, интуитивно хочется сказать, что оно растет стабильно (устойчиво).

Подведем итог: Устойчивость (стабильность) и «добро» — показатели достаточно независимые друг от друга и зависящие от того, что мы измеряем или моделируем.

Следует добавить, что устойчивость – это скорее объективный, измеримый параметр.

Что хорошо, а что плохо – это субъективное решение наблюдателя.



Принцип Анны Карениной и аттракторы

Размышляя о динамической нестабильности, мы почти неизбежно приходим к понятию хаоса.

Теория хаоса – относительно молодая наука.

Книга рассказывает увлекательную историю о его становлении и первых шагах» Хаос.

Создание новой науки » Джеймса Глейка.

Один из самых увлекательных сюжетов этой книги — открытие такого явления, как аттракторы.

Согласно определению Википедии, Аттрактор (англ.

привлечения — притягивать, притягивать) — это компактное подмножество фазового пространства динамической системы, все траектории из определенной окрестности которой стремятся к нему по мере стремления времени к бесконечности.

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

Ниже представлен один из вариантов Аттрактора Лоренца.



Принцип Анны Карениной в программировании и IT

Какое отношение аттракторы имеют к принципу Анны Карениной? Я думаю, с философской точки зрения аттракторы представляют собой «те же счастливые семьи» в мире хаоса, тогда как остальные точки фазового пространства представляют собой «несчастные семьи, несчастные по-своему».



Козырей в колоде мало.

Вы, наверное, слышали о длительных дебатах между Эйнштейном и Бором о фундаментальных принципах квантовой физики.

Дискуссия вращалась вокруг вопроса о том, какая модель определяет траекторию отдельной элементарной частицы: детерминированная или вероятностная.

Два великих физика свели суть спора к полушутливому вопросу: играет ли Бог в кости, управляя движением частиц, из которых состоит наш мир? За последнее столетие модели описания мира размножились и стали невероятно сложными.

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

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

У них слишком мало козырей.

Ну а сами явления делятся на устойчивые и нестабильные.

В то же время «очень» нестабильные со временем часто «сползают» на аттракторы.

Как мы разделим их на хорошие и плохие, зависит от нас.

Но похоже, что в нынешнем мире больше неустойчивого, чем устойчивого.

И плохого здесь больше, чем хорошего.

Другими словами, мир выглядит так, как показано на моей картинке ниже.



Принцип Анны Карениной в программировании и IT



Принцип Анны Карениной в IT

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

Но где обещанные в названии IT и программирование? Применимо ли «Принцип Анны Карениной» в этих сферах человеческой деятельности? Я уверен, что это работает. Хотя бы потому, что этот общий принцип просто обязан применяться в данной конкретной предметной области.

По крайней мере для тех аппаратно-программных и чисто программных систем, которые достаточно сложны и динамичны.

И многие из них действительно такие.



Синдром Анны Карениной

Если в ИТ присутствует Принцип Анны Карениной (ПАК), как его заметить? Во-первых, если ваша система стабильна и ее можно легко расширить и настроить, вам не стоит слишком беспокоиться.

Ваша система находится в стабильной хорошей части (см.

рисунок выше).

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

и что-то радикально изменилось.

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

Ошибки действительно исправляются, патчи устанавливаются, но ниоткуда появляются новые, более каверзные ошибки.

В таких случаях можно говорить о синдроме Анны Карениной (САК).

Напомним, что синдром – это комплекс органически связанных между собой признаков (симптомов), объединенных единым механизмом возникновения и развития.

В зависимости от размера системы NAC ведет себя по-разному.

Но большинство проявлений сводится к определенным «скандалам».

Ниже я попытался предоставить списки (далеко не полные) характерных симптомов, принадлежащих САК, в зависимости от размера системы.



Люди устраивают скандалы на предприятии

В крупных корпоративных системах программные и аппаратные проблемы ИТ-составляющей быстро трансформируются в скандалы среди руководителей и психологические войны между подразделениями.

Если попытаться отфильтровать субъективные психологические аспекты, то часто остаются объективно зафиксированные явления:

  • Нам приходится искать все больше и больше обходных путей.

  • В рабочих процессах экземпляры фантомных процессов создаются автоматически.

  • Экземпляры рабочих процессов разделяются или завершаются неправильно и начинают перемещаться по рабочим процессам.

    Из-за их непонятности персонал вольно или невольно проталкивает их всё дальше и дальше.

  • Автоматизированные рабочие процессы заменяются ручными операциями.

  • Данные редактируются с помощью скриптов, запускаемых ночью.

  • Работающую систему приходится все чаще останавливать и перезапускать.



В больших клиент-серверных системах компоненты вызывают скандал.

На уровне отдельных систем, входящих в состав крупного предприятия, или самостоятельных крупных систем с клиент-серверной архитектурой SAC часто проявляется следующим образом:
  • В Банках Данных внезапно появляются «Зомби» (Неполные записи с неверными внешними ссылками, которые, видимо, не могут быть созданы штатными скриптами и программами обработки.

    На немецком ИТ-жаргоне их называют Leichen — трупы).

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

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

  • Появляются «зарезервированные места» — группы масок, доступ к которым организационно или технически закрыт по непонятным причинам.

  • Участились странные ошибки при конвертации данных, например при отправке их в партнерские системы.



В небольших системах модули и классы создают проблемы.

На уровне небольших систем (например, настольных приложений) SAC проявляется в следующем:
  • Теряется идемпотентность операций (например, вычисления, которые по идее не должны изменить состояние системы, повторяющиеся несколько раз, дают разные результаты.

  • Пользователи жалуются на явления, которые невозможно воспроизвести.

  • Линейное расширение (добавление в систему основного профильного функционала, например новой бизнес-функции) приводит к ошибкам или сбоям в ранее работавших модулях.

  • Вторичные изменения (например, изменение цвета в GUI) приводят к ошибкам или сбоям в основной функциональности.



Можно ли изменить квадрант?

Возможно ли, чтобы наша система, оказавшаяся в левом нижнем квадранте, сменила ее на другую? Я думаю, не всегда.

Иногда проще заменить систему, чем пытаться ее вылечить.

К счастью, средний срок жизни современных ИТ-систем невелик — около 10 лет. (Эта цифра — результат моих наблюдений, а не официальной статистики.

Удивительно, что для полного обновления клеток нашего организма требуется примерно столько же времени.

) Откуда берутся наши проблемы? Как правило, большинство проблем возникает из-за неправильного выбора или программирования отдельных компонентов или использования элементов базовых фреймворков.

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

Эти алгоритмы были реализованы на устаревших языках программирования.

В начале проекта важность этих начальных точек роста (ядер) казалась огромной.

Поэтому заказчики настояли на том, чтобы эти ядра остались в системе.

Архитектура и даже пользовательский интерфейс систем были адаптированы под эти ядра.

В итоге стоимость этих насадок оказалась в десятки раз выше стоимости продажи самих ядер (если бы они продавались заново).

Насадки оказались хлипкими и в готовых системах можно было однозначно диагностировать САК.



Что делать?

Предприятие зачастую может позволить себе радикальное решение – замену одного компонента другим.

Зачастую это действительно единственно приемлемое, хотя и очень болезненное решение.

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

Тогда возникает закономерный вопрос:

Что с нами не так?

Это ключевой вопрос.

Почему в этом месте не дает сбоя конкурирующая или подобная система, а ваша? Часто потому, что в вашей системе есть несколько компонентов, которые запрограммированы или настроены «из коробки» — не в соответствии с проверенными передовыми практиками или просто здравым техническим смыслом.

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

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

Но потом.

она станет больше похожа на другие успешные системы.

Точно так же, как «.

Все счастливые семьи похожи друг на друга».

В заключение позвольте мне предложить специальную формулировку Принципа Анны Карениной применительно к ИТ-системам и программированию:

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

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

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

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

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

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

Поэтому буду очень признателен, если вы примете участие в опросе.

Иллюстрации: Кадр из классической экранизации романа «Анна Каренина» Мосфильма.

1967. Лев Николаевич Толстой.

Источник: Википедия Фрэнсис Гальтон.

Источник: Википедия Арнольд Владимир Игоревич.

Источник: Аттрактор Лоренца Википедия.

Источник: Центр инженерного проектирования Ньюкасла - Университет Ньюкасла.

В опросе могут участвовать только зарегистрированные пользователи.

Войти , Пожалуйста.

Принцип Анны Карениной и мой проектный опыт 10,73% Скептически отношусь к понятию «ИТ-философия».

ИТ – это оборудование и программы.

Философии там нет места 22 13,17% Я не уверен, что принцип Анны Карениной существует 27 6,83% Принцип Анны Карениной может существовать, но он неактуален для ИТ и программирования 14 17,07% Принцип Анны Карениной, безусловно, применим к ИТ и программированию.

программирование, но нет Не наблюдал в своих или «знакомых» проектах 35 52,2% Наблюдал Принцип Анны Карениной в одном «знакомом» (соседнем) или своем проекте 107 205 пользователей проголосовали.

52 пользователя воздержались.

Теги: #философия развития #аттрактор Лоренца #аттрактор #программирование #Анализ и проектирование систем #Управление развитием #Управление персоналом

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.