«Принципу Анны Карениной» посвящено немало научных публикаций и даже отдельная статья в Википедии. Применим к ИТ и программированию? А может он уже работает против вашего проекта?
Первый вариант этой статьи я опубликовал в моём англоязычном блоге и поместил ссылки в несколько узкоспециализированных форумов. Состоявшиеся там обсуждения мотивировали меня предложить её вариант на русском языке читателям Хабра.
В статье обсуждается один из философских принципов, который с точки зрения автора:
а) обьективно существует
б) релевантен для ИТ-проектов и программирования.
Если Вам, дорогой читатель, такие темы не интересны, вряд ли Вам стоит читать эту статью дальше.
Недавно я перечитал великий роман Льва Толстого «Анна Каренина».
Первый раз я прочитал его в школьные годы, поскольку того требовала от нас учительница литературы. Но чтобы понять такие книги, их надо читать в зрелом возрасте, накопив достаточно своего личного жизненного опыта и понимания людских характеров.
От главы к главе Лев Толстой описывает происходящие события, как бы наблюдая их глазами того или иного участника событий. И поступки некоторых героев романа, которые до этого воспринимались легкомысленными выходками или проявлениями их злой воли, рассмотренные с другой перспективы, кажутся глубоко логичными и даже единственно возможными.
А по прочтению романа остается впечатление, что иначе и не могло быть. Легкий флирт между замужней женщиной и молодым блестящим аристократом-офицером переходит в страстную любовь, затем – в моральный надлом отношений между влюблёнными и, в финале – самоубийством героини под колесами поезда.
И каждое звено в этой ужасной цепи событий в момент прочтения представляется понятным и логичным.
Прочитав роман, каждый может сам для себя решить, что означает это загадочное, самое первое предложение романа:
„Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему.“
Одно из возможных объяснений состоит в том, что Лев Толстой в этом предложении сформулировал куда более общий философский принцип, который проявляется в медицине, социологии, биологии, глобальных геофизических явлениях и, по моему мнению — в ИТ в целом и в программировании в частности.
Что означает Принцип Анны Карениной?
Интерпретациям этого принципа, получившего имя «Принцип Анны Карениной», посвящено немало научных публикаций и даже отдельная статья в Википедии.
Что означает этот принцип? Очень сложные химические, физические, биологические, психологические, социальные и т.п. системы могут долго и успешно существовать и развиваться только если их части хорошо подходят друг к другу и к внешней среде.
Если бы мы были в состоянии описать такие системы каким-то количеством параметров, то заметили бы, что для каждого класса систем существует совсем немного «успешных» комбинаций этих параметров.
Замечание: Для придания нашим параметризованным моделям большей реальности мы должны говорить не об отдельных значениях параметров, а об классах эквивалентности параметров. Но это не меняет сути.
Как это ни парадоксально, но чем сложнее класс систем, тем меньше у него «успешных» комбинаций.
Кофеварки различных производителей отличаются друг от друга по используемым техническим решениям и даже по внешнему виду сильнее, чем легковые автомобили, а те — сильнее чем пассажирские самолёты.
Принцип Анны Карениной и одомашнивание животных или ограниченность и вторичность параметров отбора
Британский ученый Фрэнсис Гальтон, живший одновременно с Толстым, сформулировал похожий на Принцип Анны Карениной принцип, рассматривая одомашнивание животных:
Складывается впечатление, что все дикие животные имели шанс сделаться домашними. При этом немногие… были одомашнены давным-давно, а огромное число остальных, когда-то не использовавших свой шанс из-за какой-то мелкой особенности, так и обрекли себя на вечное дикое состояние.
Дальнейшие интересные рассуждения о том, как сработал этот принцип можно найти в увлекательно написанной книге Джареда Даймонда «Ружья, микробы и сталь».
Глава 9. Зебры, несчастливые браки и принцип «Анны Карениной» этой книги начинается такой фразой (в переводе на русский):
Все одомашниваемые животные похожи друг на друга, каждое неодомашниваемое животное неодомашниваемо по-своему.
Если вам показалось, что где-то вы уже читали нечто подобное, вы не ошиблись. Поменяйте несколько слов, и получится знаменитое первое предложение «Анны Карениной», великого романа Льва Толстого: «Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему». Этой фразой Толстой хотел сказать, что счастливым может быть только брак, состоявшийся во множестве разных аспектов: между супругами есть обоюдное сексуальное притяжение, налажены отношения с родней друг друга, нет разногласий по поводу финансов, воспитания детей, религии и остальных жизненно важных вопросов. Неудача на одном из этих важнейших направлений способна погубить брачный союз, даже если у него есть все остальные компоненты для счастья.
Далее автор называет факторы, которые не позволили, несмотря на многочисленные и продолжающиеся до сих пор попытки одомашнить диких животных. Их немного: рацион питания, скорость роста, проблемы с размножением в неволе, «дикость» характера, склонность к панике, социальное устройство.
Интересно отметить тот факт, что все перечисленные автором факторы — «вторичные». Например, человечество выращивает и забивает на мясо не носорогов (3 тонны мяса) а куда более мелких животных — коров, свиней и овец.
Другими словами, если бы мы программировали алгоритм отбора животных для одомашнивания, нам в качестве параметров пришлось бы использовать не первичные атрибуты этого вида животных (вес, рост, продолжительность жизни и т.д.), а вторичные, вычисляемые с помощью специальных функций. И уже на них мы бы накладывали весьма жесткие ограничения.
Если вам это интересно, то найдите и почитайте книгу.
Но автор объясняет действие принципа в конкретной предметной области. Имеется его более широкая интерпретация?
Принцип хрупкости хорошего
Взглянуть на проблему с более широких и в тоже время чисто математических позиций попытался гениальный математик Владимир Арнольд в своей книге «Теория катастроф»
Там он описывает т.н. «Принцип хрупкости хорошего».
Он пишет:
… для системы, принадлежащей особой части границы устойчивости, при малом изменении параметров более вероятно попадание в область неустойчивости, чем в область устойчивости. Это проявление общего принципа, согласно которому всё хорошее (например, устойчивость) более хрупко, чем плохое. По-видимому, все хорошие объекты удовлетворяют нескольким требованиям одновременно, плохим же считается объект, обладающий хотя бы одним из ряда недостатков.
В рассматриваемом им контексте Владимир Арнольд возможно был и прав. Но в более широком контексте можно видеть, что на самом деле он говорит о хрупкости, а точнее — о редкости устойчивости, а не «хорошести».
Не все неустойчивое плохо и не все устойчивое хорошо.
Кто хоть раз в жизни переходил лужу или канаву по бревнышку, меня понимает. Неустойчиво двигаться по бревнышку лучше, чем свалиться вниз и принять в канаве устойчивое положение.
С другой стороны -любое движение скорее неустойчивость. Деревья и цветы хороши пока они живы и растут, а засохнувшие — как правило нет.
И в то же время, про дерево, растущее сотни лет, интуитивно хочется сказать, что оно стабильно (устойчиво) растет.
Подведем промежуточный итог: Устойчивость (стабильность) и «хорошесть» — показатели скорее независимые друг от друга и зависят от того, что же мы измеряем или моделируем. При этом следует добавить, что устойчивость — это скорее объективный, измеряемый параметр. Что такое хорошо и что такое плохо — это субъективное решение наблюдателя.
Принцип Анны Карениной и аттракторы
Размышляя о динамической неустойчивости, мы почти неизбежно придем к понятию хаоса.
Теория хаоса — сравнительно молодая наука. О её становлении и первых шагах увлекательно рассказывает книга "Хаос. Создание новой науки" Джеймса Глейка. Один из самых увлекательных сюжетов в этой книге — открытие такого явления как аттракторы.
Согласно определению Википедии -Аттра?ктор (англ. attract — привлекать, притягивать) — компактное подмножество фазового пространства динамической системы, все траектории из некоторой окрестности которого стремятся к нему при времени, стремящемся к бесконечности. Аттрактором может являться притягивающая неподвижная точка (к примеру, в задаче о маятнике с трением о воздух), периодическая траектория (пример — самовозбуждающиеся колебания в контуре с положительной обратной связью), или некоторая ограниченная область с неустойчивыми траекториями внутри (как у странного аттрактора).
Внизу изображен один из вариантов Аттрактора Лоренца.
Какое отношение имеют аттракторы к Принципу Анны Карениной?
Я думаю, с философской точки зрения аттракторы представляют в мире хаоса «одинаковые счастливые семьи» в то время как остальные точки фазового пространства — «несчастливые семьи, несчастливые по-своему».
В колоде мало козырей...
Вы наверняка слышали о долгих спорах Эйнштейна и Бора о фундаментальных основах квантовой физики. Дискуссия велась вокруг вопроса, какая модель определяет траекторию отдельной элементарной частицы: детерминистская или вероятностная. Два великих физика абстрагировали суть спора до полушутливого вопроса: Играет ли Бог в кости, управляя движением частиц, составляющих наш мир?
За прошедшее столетие модели описания мира невероятно умножились и усложнились. Продолжая линию Эйнштейна и Бора применительно к нынешней ситуации мы можем сказать, что для управления миром Богу необходимы инструменты посложнее, чем игральная кость. Например — колода карт.
Тогда, с учетом Принципа Анны Карениной можно сказать, что колоды карт, которые Бог выбирает для управления природными и социальными феноменами, как правило, не очень хороши. В них слишком мало козырей…
Ну а сами феномены делятся на устойчивые и неустойчивые. При этом «очень» неустойчивые со временем часто «скатываются» на аттракторы.
Как мы поделим их на хорошие и плохие — зависит от нас. Но похоже, в нынешнем мире больше неустойчивого, чем устойчивого. А плохого больше чем хорошего.
Другими словами, мир выглядит так, как на моей картинке внизу.
Принцип Анны Карениной в ИТ
Все это может и похоже на правду, возможно уже подумал про себя кто-то из читателей. Но где обещанные в заголовке ИТ и программирование? Действует Принцип Анны Карениной в этих областях человеческой деятельности?
Уверен, действует. Хотя бы потому, что этот общий принцип просто должен действовать и в этой конкретной предметной области. По крайней мере для тех программно-аппаратных и чисто программных систем, которые достаточно сложны и динамичны. А многие из них действительно таковы.
Синдром Анны Карениной
Если Принцип Анны Карениной (ПАК) в ИТ присутствует, как его заметить?
Во-первых, если ваша система работает стабильно и позволяет себя безболезненно расширять и конфигурировать, вам не стоит особенно беспокоиться. Ваша система находится в устойчиво-хорошей части (см. картинку вверху).
Если ваша система не совсем хороша или совсем нехороша, но устойчива и делает своё дело (находится в неустойчиво-хорошей части мира), вам следует хорошенько подумать, а стоит ли рисковать и что-то радикально менять.
ПАК начинает показывать себя со своей негативной стороны, если попытки исправить конкретные ошибки только ухудшают ситуацию. Ошибки действительно исправляются, патчи инсталлируются, но «ниоткуда» появляются новые, более каверзные ошибки. В подобных случаях можно говорить о Синдроме Анны Карениной (САК).
Вспомним, что синдром представляет собой комплекс органически связанных между собой признаков (симптомов), объединенных единым механизмом возникновения и развития.
В зависимости от размеров системы САК показывает себя по-разному. Но большинство проявлений сводятся к определённым «скандалам».
Внизу я попытался привести списки (далеко неполные) характерных симптомов, принадлежащих САК в зависимости от размера системы.
В энтерпрайзе скандалят люди
В больших энтерпрайз-системах программные и аппаратные проблемы ИТ-компонент быстро трансформируются в скандалы менеджеров и психологические войны подразделений между собой. Если попытаться отфильтровать субъективно-психологические аспекты, то часто остаются объективно регистрируемые феномены:
- Приходится делать всё больше и больше workarounds.
- В workflows самозарождаются фантом-инстанции процессов.
- Инстанции workflow-процессов расщепляются или не заканчиваются корректным образом и начинают блуждать по workflows. В силу их непонятности персонал вольно или невольно проталкивает их дальше и дальше.
- Автоматика workflows подменяется ручными операциями.
- Данные правятся с помощью скриптов, запускаемых по ночам.
- Работающую систему приходится все чаще останавливать и перезапускать.
В больших клиент-серверных системах скандалят компоненты
На уровне отдельных систем входящих в большой энтерпрайз, либо независимых больших систем с клиент-сервер архитектурой САК проявляется нередко таким образом:
- В Банках Данных неожиданно появляются «зомби» (Неполные записи с некорректными внешними ссылками, которые вроде бы не могут быть созданы регулярным скриптами и программами обработки. В немецком ИТ-жаргоне их называют Leichen — трупы).
- Учащаются торможения системы, когда она «ползает на четвереньках», а порой она просто «падает».
- Появляются «гиблые места» — группы web-страниц или формуляров ввода данных, пользоваться которыми отваживаются только немногие пользователи.
- Появляются «заповедные места» — группы масок, доступ к которым без внятных причин организационно или технически закрыт.
- Учащаются странные ошибки при конвертировании данных, например при посылке их партнер-системам.
В небольших системах скандалят модули и классы
На уровне небольших систем (например — Десктоп-Приложений) САК проявляет себя в том что:
- Теряется идемпотентность операций (например, вычисления, которые в теории не должны менять состояния системы, повторенные несколько раз дают разные результаты.
- Пользователи жалуются на феномены, которые не удается воспроизвести.
- Линейные расширения (добавление в систему функциональности основного профиля, например новой бизнес-функции) приводит к ошибкам или отказам в работавших до этого модулях.
- Вторичные изменения (например, смена цвета в GUI) приводят к ошибкам или отказам в основной функциональности.
Можно ли поменять квадрант?
Можно ли для нашей системы, очутившейся в левом нижнем квадранте, поменять его на другой?
Думаю, не всегда. Иногда систему проще заменить, чем пробовать вылечить. Благо средний срок жизни современных ИТ систем недолог — около 10 лет. (Эта цифра — результат моих наблюдений, а не официальной статистики. Поразительно, что примерно столько же времени требуется для полного обновления клеток нашего организма.)
Откуда берутся наши проблемы? Как правило, большинство проблем зарождается при неверном выборе или программировании отдельных компонент либо использовании элементов базовых frameworks.
Например, в своей профессиональной карьере я наблюдал развитие нескольких проектов, которые зарождались на базе реализации предположительно гениальных алгоритмов. Эти алгоритмы были реализованы на устарелых языках программирования. Важность этих изначальных точек роста (ядер)представлялась в начале проекта огромной. Поэтому заказчики настаивали на том, чтобы эти ядра непременно остались в системе.
Под эти ядра подстраивалась архитектура и даже пользовательский интерфейс систем. В конце-концов стоимость этих прилад в десятки раз превосходила стоимость реализации самих ядер (если бы их реализовали заново). Прилады получались хлипкими и у готовых системы можно было однозначно диагностировать САК.
Что делать?
Энтерпрайз часто может позволить себе радикальное решение — замену одной компоненты на другую. Часто это действительно единственно приемлемое, хотя и очень болезненное решение.
Если же система уникальна, слишком заточена на ваш бизнес, или миграция и стоимость лицензий новой системы слишком велики, надо пробовать справиться с САК на месте. Тогда возникает естественный вопрос:
Что у нас не так?
Вот это ключевой вопрос. Почему конкурирующая или схожая система не падает в этом месте, а ваша падает?
Часто потому, что в вашей системе есть несколько компонент, которые спрограммированы или сконфигурированы «не по правилам» — не соответствуют зарекомендовавшим себя best practicies или просто здравому техническому смыслу.
Если их найти и системно исправить, заменить, правильно сконфигурировать — то может быть, ваша система станет менее уникальной, экзотичной, эзотерической, загадочной, но зато перестанет вас мучить. Но повторюсь — задача не в том, чтобы исправить накопившиеся ошибки, а в том, чтобы провести системный анализ и по его итогам сделать рефакторинг или реинжениринг вашей системы.
Но тогда ...- она станет более похожа на другие удачные системы. Так же, как "… Все счастливые семьи похожи друг на друга."
Под конец позволю себе предложить специализированную формулировку Принципа Анны Карениной применительно к ИТ-системам и программированию:
Все удачные системы одной и той же предметной области похожи друг на друга, каждое проблемная система проблематична по-своему.
Проблемы возникают из-за использования нестандартных, неопробованных, другими словами — «экзотических» решений и компонент. «Экзотические» решения и компоненты «проникают» в систему из-за низкой квалификации или неоправданного энтузиазма разработчиков, менеджеров или заказчиков.
Если экономические и технические показатели системы плохие, исправление одних ошибок в ней приводит к появлению новых — то скорее всего это проявления Синдрома Анны Карениной. Как правило, в этом случае требуется радикальный рефакторинг системы либо замена её некоторых частей на другие либо всей системы в целом.
Думаю Ваше мнение, уважаемый читатель, будет интересно и другим читателям Хабра. Поэтому я буду Вам очень признателен, если Вы примете участие в опросе.
Иллюстрации:
- Кадр из классической экранизации романа «Анна Каренина» Мосфильм. 1967.
- Лев Николаевич Толстой. Источник: Википедия
- Фрэнсис Гальтон. Источник: Википедия
- Арнольд, Владимир Игоревич. Источник: Википедия
- Аттрактора Лоренца. Источник: Newcastle Engineering Design Centre — Newcastle University
Комментарии (34)
andreyverbin
03.01.2018 03:46Кажется, что корень всех зол в том, что мы (разработчики ПО) не умеем произвольно взятую задачу «правильно» декомпозировать на модули. Всякие умные подходы вроде ООП, MVC, DDD, Viper и т.п. не особо в этом помогают. Если представить все варианты реализаций требований как множество, то похоже, в этом множестве лишь немногие точки отвечают «хорошей» системе. В итоге три варианта:
1. Разработчики уже знают как делать правильно, это называется «опыт в предметной области»;
2. Приходят к хорошей системе путем непрерывного рефакторинга, стоит это бешеных денег и времени. Раза 3-4 всю системы нужно будет переписать. На практике такое возможно только в своих собственных проектах. Поэтому свои, домашние, проекты, лучше растят скилл по сравнению с коммерческой разработкой.
3. Делают как показалось вначале правильным, судорожно пытаются найти время на рефакторинг и оказываются в итоге там же, где и большинство — в левой части вашего квадрата.
Исправить такое незавидное положение можно если придумать некую алгебраическую структуру на множестве требований. Тогда «правильную» архитектуру мы сможем вычислять, с некоторой точностью. Но такого даже на горизонте нет. А пока нужно рассчитывать на опытных коллег, сообщество, общение и передачу знаний о том, что работает, а что нет.VolCh
03.01.2018 12:00«правильность» она тоже разная бывает, что порождает как минимум четвёртый вариант: система создана «правильной» в краткосрочной перспективе, но потенциала развития в долгосрочной нет или он сильно ограничен.
ivanbolhovitinov
03.01.2018 05:54Все здоровые люди похожи друг на друга, каждый больной человек болен по-своему?
visirok Автор
03.01.2018 13:24С точки зрения медицинского страхования все здоровые (на данный момент) принадлежат к одному кластеру, а больные разбиваются в кластеры в зависимости от диагноза и небольшого ряда других параметров.
В статьях из области биологии и медицины много упоминаний о Принципе Анны Карениной.
user4000
03.01.2018 08:01Я для себя давно ещё так сформулировал (на примере хранимых процедур сервера БД):
Процедура может вернуть различные коды возврата (не равные нулю) в случае каких-либо ошибок, так как причин возникновения ошибок — множество.
В случае успешной отработки (без ошибок) процедура вернёт код возврата равный нулю (т.е. вариант успешной отработки один; а число «ноль» — также уникальное в своём роде).
akhmelev
03.01.2018 08:27Итогом работы программистов является код. Его качество напрямую зависит от "качества" собственно программиста. Следовательно, исследовать нужно причины, а не следствия. Личности, команды и их подготовку, а не их продукты.
В статье же постулируется банальность. Вероятность совпадения двух и более положительных исходов равна произведению вероятностей. А так как отдельные вероятности всегда меньше 1 вывод очевиден… Хоть Карениной, хоть аттрактором это называйте ;)
vadimpl
03.01.2018 09:34(выступлю без аргументации) Очередная модель, рождённая умелым подбором нужных факторов в нужных толкованиях. Что-то где-то подобное слышал, но на другом уровне и с совершенно другими выводами (где — не помню. М.б., в т.ч. у Роберта Сапольского?).
Одни рассуждения про «хорошее/плохое» (я уж думал, что подобные понятия давно остались на уровне детсада, ан нет), «устойчиво/неустойчиво» чего стоят. Как хочу, так верчу. Но зато в конце — какая классная модель!
Данная модель, в числе множества других примитивов, была бы хороша, будь она именно примитивом. Сама по себе модель «неустойчива» или «устойчива», смотря как смотреть/толковать, что уже выбивает основание из-под этой модели.
Но — талантливо, этого не отнять.
TitovVN1974
03.01.2018 09:37{краткое нестрогое ночное замечание от невыспавшегося радиофизика}
Проиллюстрируем поведение диссипативных динамических систем (между людьми есть «притяжение»).
<> Трудно иметь дело с негрубыми динамическими системами. Бесконечно малое изменение
параметров приводит к качественному изменению динамики, к другому аттрактору, другому «результату». Случай «вздорного» супруга, нестабильности психики или соматики. Не будем рассматривать, как предположительно не соответствующий счастливой семье.
<> С грубыми — существенно легче. Параметры можно «немного» изменить, а режим останется качественно неизменным.
<> Если грубая система существенно диссипативна — начальные условия («детали» встречи) и внешние воздействия играют малое значение в в наблюдаемом эксперименте, «быстро забываются», и аттрактор быстро достигается во временной реализации.
<> Если это не так, и степень сжатия элемента объема фазового пространства невелика,
приближение к аттрактору будет медленным.
— — — — — После введения, переформулируем эффект АК:
<> Мы неявно постулируем существование класса подобных семей, которые можно классифицировать как счастливые (единый аттрактор или множество некоторым образом «подобных» аттракторов).
<> {наблюдаемый режим}
Каждая счастливая семья — на неком аттракторе, который занимает малую область фазового пространства. Наблюдаемый режим семьи «ограничен». Несчастливые — в более «объемной» области наблюдаемых переменных, поведение может быть более разнообразным в каждом рассматриваемом случае. Также выше введен постулат о подобии режимов, свойство «счастье».
<> {параметры}
Внутренние характеристики каждой семьи (параметры) принадлежат множеству, соответствующему данному аттрактору «счастливая семья». В соответствии с постулатом «счастья», по-видимому, множества параметров подобны, или принадлежат одному общему множеству.
<> При анализе истории развития отношений счастливых семей, мы возможно, также обнаружим, что есть общность деталей их встречи (в каждом случае начальные условия принадлежат бассейну притяжения. Бассейны притяжения счастливых семей в первом приближении можно считать «подобными» ).
EvilBeaver
03.01.2018 09:44+1Каждый довоенный шаг участников Первой мировой кажется логичным и взвешенным, но в совокупности они привели к большой войне. Теперь я знаю как это называется. Раньше я называл это фразой из Летова (той, где всё летит в область неустойчивости). Ситуация, где любые логичные улучшения в конечном итоге ведут в пропасть. Здоровская статья, спасибо!
savagebk
03.01.2018 12:15Либо действия некоторых участников были недостаточно продуманными, либо война и была целью некоторых, либо в целом ситуация в Европе тех лет наиболее легко могла разрешиться именно войной (по аналогии с термодинамикой — система без притока энергии сама приходит к состоянию термолинамического равновесия)
dyvniy
06.01.2018 18:03Вероятно тут совокупность из всех трёх факторов. С другой стороны, если бы кто-то смог оценить результаты войны, энтузиазм многих зачинщиков поубавился бы.
Vlad_fox
03.01.2018 11:14я бы дополнил принцип Анны К. принципом Шрека (с уточнениями от Ослика):
—ЛюдоедыИТ технологии и решения — как лук.
— Воняют?
— Да нет.
— От них все плачут?
— Нет.
— Если их оставить на солнце, то они темнеют и покрываются пятнами?
— Нет! Я говорю про слои! И у тех и у других есть слои, понятно?
— У тортов тоже есть слои! Значит,тыИТ — как торт? »
Шрек (Shrek)
Seam
03.01.2018 12:17Следуя этой логике, если у систем с САК есть общие признаки, то они одинаково неустойчивы. Это несколько противоречит идее статьи о том, что устойчивость имеет ряд общих признаков, позволяющих ей быть устойчивой. А у неустойчивой системы нет общих признаков, которые позволяли бы ей быть неустойчивой.
TitovVN1974
03.01.2018 12:24Есть общие принципы и устойчивости и неустойчивости. Система одновременно может быть и устойчива и неустойчива (по разным «направлениям»). И можно рассматривать общие характеристики сложной динамики подобных систем.
Управление подобными системами рассматривает направление «управление хаосом»
madkite
03.01.2018 15:48+1Проблемы возникают из-за использования нестандартных, неопробованных, другими словами — «экзотических» решений и компонент.
Именно этим принципом на моей памяти руководствывались все менеджеры, выбирая Oracle (ведь большинство успешных компаний юзает эту СУБД). Других аргументов не было. В итоге мы приходим к некоторому стадному эффекту.
domix32
03.01.2018 17:03Еще можно притянуть к статье принцип оптимальности/эффективности по Парето, когда система как целое не «убыточна» в широком смысле, но улучшение параметров какой-либо из компонент системы может обернуться негативно для остальных элементов.
Vlad_fox
03.01.2018 17:33-1притянуть в статью можно все что угодно,
один автор недавно притянул джеб кличко как новую методологию управления проектом и линейной деятельностью.
для писателя- это полезно, набивает руку писать тексты.
вопрос в том — а какой инструмент дает чтение такой статьи читающему? Какие задачи он после прочтения станет решать по другому? что это дает его мировоззрению?
не заценили выше принцип Шрека, хорошо — есть у меня и еще:
если вам не на чем больше прокрастинировать, как на подобных статьях — то… прокрастинируйте на здоровье. если уж все равно заняться больше нечем достойным.
принцип школьника — необходимо занимать свое мышление ЧЕМ НИБУДЬ, вдруг что-то из этого (тригонометрия или толстый роман Толстого) окажется когда-нибудь полезным. а не окажется — нуи хрен с ниммы не спешим, будем ждать вдруг окажется.
visirok Автор
03.01.2018 21:02Немецкие менаджеры очень любят такую формулировку Принципа Паретто: «80% функциональности можно разработать за 20% бюджета». В соответствии с этим принципом начинают с самых «дешевых но сердитых» фичей. Такая «жадная» стратегия выбора фич часто приводит очень печальным результатам. Берлинский аэропорт и Гамбургская Опера тому примеры. Хотя конечно без коррупции там тоже не обошлось, имхо.
Но всё же это другая тема, имхо.domix32
03.01.2018 23:00Принцип Паретто не имеет отношения к статье. Однако же так называемая «оптимальность по Паретто» вполне
Garruz
03.01.2018 17:56+1Попробую продолжить правильную мысль andreyverbin – и чуть более расширенно описать факторы, благодаря которым, на мой взгляд (цитата) «Все удачные системы одной и той же предметной области похожи друг на друга». Понимаю, что сейчас выступлю в роли Кэпа. Но оно работает. Хотя, к сожалению, об этих простейших вещах часто забывают, что и порождает пресловутый САК…
1) Разработка «сверху вниз». Сначала проектирование «на бумаге» чёткой архитектуры проекта, проработка возможностей масштабирования, выбор инструментария и т.д. Только потом непосредственная разработка.
Этим должны заниматься разные люди. «Стратеги» определяют общий план (не вдаваясь в частности), «тактики» определяют методы его реализации (при необходимости указывая «стратегам» на эти самые частности). Сообща вырабатывают наиболее оптимальные решения, тем самым страхуя друг друга от ошибок проектирования и/или реализации. Поэтому в проекте критически важно наличие специалистов обоих типов.
В противном случае чаще всего получается печально знаменитый «индусский код», в процессе отладки которого ошибки могут множиться как головы Лернейской гидры – на месте одной пофиксенной появляются две новые…
2) В команде обязательно должен быть хотя бы один аналитик с так называемым «негативным мышлением», способный думать на несколько шагов вперёд. Который, конечно же, дико замучает всех своими опасениями – но зато с высокой долей вероятности «предскажет» все возможные риски, подводные камни и прочие слабые места.
Не в обиду (и не в упрёк) будет сказано, но непосредственные разработчики нередко просто физически неспособны на подобный критический анализ всего проекта, будучи полностью загружены решением локальных технических задач.
3) По возможности ограничить использование в крупных проектах сторонних библиотек и компонентов. Согласен, что писать самим нередко дольше и сложнее. Но в своём коде всегда проще разобраться и найти проблемные места. Кроме того, в этом случае можно будет с самого начала «заточить» все необходимые модули конкретно под архитектуру текущего проекта.
Впрочем, этот пункт сугубо ИМХО. Ситуации бывают разные.
4) И, наконец – грамотный менеджмент проекта, с чётко выстроенной иерархией и чётко прописанными должностными обязанностями.
Чтобы разработчики, с одной стороны, не метались между разнородными (и порой противоречащими друг другу) указаниями и комментариями различных начальственных инстанций, а с другой стороны – и не были предоставлены сами себе, действуя «кто в лес, кто по дрова».
Причём, все обсуждения желательно фиксировать в письменном виде – хоть в тех же мессенджерах. Увы, необходимая бюрократия. Но она значительно снижает риск появления «ничейных» ошибок (поиск которых в крупных проектах подобен поиску иголки в стоге сена). Поскольку всегда можно поднять «логи» всех указаний/комментариев – за счёт чего гораздо проще выследить всю цепочку ошибочных решений. На всякий случай, уточню: это не с целью «поиска крайнего», а именно с целью локализации проблемных участков проекта.
Вот как-то так видится…
P.S. К слову, в продолжение темы безвременно усопшей госпожи Карениной (а также в тон статье), многое из вышеперечисленного применимо и наоборот – к человеческим отношениям. Круг замкнулся. ))
PerlPower
03.01.2018 20:24+1Программисты, научные сотрудники, инженеры должны делать обобщения по долгу службы, но иногда это заходит слишком далеко. Проявляется это в желании построения некой единой теории, которая может обобщить если не вселенную в общем, то жизнь индивида или хотя бы род его деятельности. Такие теории бывают двух видов. Первые ввиду чрезмерной абстрактности имеют нулевую предсказательную способность. Вторые имеют предсказательную способность, но не имеют четко обозначенных границ применения, которые все же четко существуют в голове теоретика, но вслух не произносятся.
visirok Автор
03.01.2018 20:47Спасибо за ценное дополнение к статье. Я думаю, общепризнанные философские принципы типа «Переход количества в качество», «Единство и борьба противоположностей» а также менее признанные типа «Принципы Анны Карениной» или упоминавшегося в одном из комментариев «Принципа Паретто» относятся ко второй категории. Они имеют очевидную предсказательную способность, но их границы определения очень трудно определить.
AntonSt
03.01.2018 22:16Причем теория о наличии двух видов теорий относится, по-моему, ко второму виду (шутка)
Время от времени и правда появляется желание все взять и обобщить.
godlatro
03.01.2018 20:31Не все неустойчивое плохо и не все устойчивое хорошо.
Кто хоть раз в жизни переходил лужу или канаву по бревнышку, меня понимает. Неустойчиво двигаться по бревнышку лучше, чем свалиться вниз и принять в канаве устойчивое положение.
Автор статьи немного не понял смысла сказанного в книге.
Арнольд как раз говорил о том что хождение по бревнышку — является пределом устойчивости, за границей которого находится канава. То есть свалиться в канаву с бревна у нас больше шансов, чем пройти по бревну невредимым.visirok Автор
03.01.2018 20:38Сначала я в конце цитируемого предложения поставил смайлик, но потом его удалил, вспомнив что на Хабре они не приветствуются. Так или иначе, это была попытка немного пошутить по ходу повествования. Но и в этой шутке есть доля правды. Я сравниваю на самом деле два состояния: движение по бревну и лежание в канаве. Вы же сравниваете шансы свалиться и не свалиться. Т.е. — наши высказывания друг-другу не протвиворечат, поскольку речь идет о разных сравнениях.
Daddy_Cool
03.01.2018 20:49Прочитал с удовольствием! ИМХО статья есть иллюстрация к понятию энтропии.
potan
04.01.2018 00:14Как раз в ИТ наблюдается обратное — схожие проблемы успешно решаются совершенно разными способами.
System12
04.01.2018 20:37Задумался, а не является ли вариантом «Принципа Анны Карениной» старая сентенция: «Лучшее враг хорошего». Все «хорошее» более однородно чем «лучшее».
visirok Автор
04.01.2018 20:46Я попытался в своей статьи оттолкнутся от филослфской части Принципа Анны Карениной и перейти к его конкретным проявлениям в области программирования и ИТ. Движение в противоположном направлении чревато издишним обощением у которого, как отметил PerlPower очень низкая предсказательная способность. Такие обощения описываются в частности фразами народной мудрости, фольклёром и т.д.
В общем — я думаю в определённом контексте Ваше утверждение верно.
geher
05.01.2018 14:58+2Принцип Анны Карениной верен только при очень упрощенной модели.
Причем, если упрощать "каждая несчастливая семья несчастлива по-своему" тем же способом, которым было получено "все счастливые семьи похожи друг на друга", то получится "все счастливые похожи друг на друга, все несчастливые похожи друг на друга".
Изложение принципа в приложении к одомашниванию тоже некорректно.
Одомашнивались животные очень по разному.
Сравните кошку и собаку и их контракты на жизнь рядом с человеком.
А если упрощать, то не одомашниваемые тоже "одинаковые". Для них просто не нашлось подходящего контракта с человеком (подходящего человеку, конечно).
В реальности же можно говорить об ограниченном количестве приемлемых известных решений (то самое "одинаковое счастье" в терминах принципа Анны Каренниной).
Но однажды находится кто-то, кто находит новое решение и открывает "новый способ быть счастливым", расширяя список решений. Но люди стремятся к упрощению, и принимая новое решение забывают о чем-то старом. А потому новый способ может оказаться как действительно новым, так и давно забытым старым.
А еще хуже, когда следуя принципу Анны Карениной всех загребают под одну гребенку, объявляя что-то одно верным и каноническим, а все остальное ересью, не признавая счастье тех, кто продолжает быть счастливым "неправильно". Но те, кто вроде должен быть одинаково счастливым, частенько оказываются по разному несчастными, пытаясь следовать "единственно правильному решению проблемы счастья".
visirok Автор
06.01.2018 18:26Я не согласен со всеми Вашими заявлениями.
1) Принцип Анны Карениной это по-сути модель. Любая модель проще описываемой реальности. Если речь идёт о динамических системах, интересен аспект предсказательной способности модели. А она может быть и отрицательная и положительная.
2) Термин «одомашнивание животных» я использовал строго в соответствии с цитируемой книгой. Если Вы эту книгу не читали, очень советую прочитать. Если Вы под одомашниванием понимаете что-то другое, чем в книге, то сначала надо договориться о терминах. И только потом заявлять о правильности или неправильности.
3) Принцип Анны Карениной — это инструмент. Им можно пользоваться или не пользоваться. Можно пользоваться неправильно, «загребая всех под одну гребёнку».
VolCh
Кроме предметной области нужно учитывать и другие факторы, например порог входа и масштабируемость. Удачные системы в одной предметной области могут быть совершенно разные, если одна рассчитана на не квалифицированного индивидуального пользователя, а другая на транснациональные корпорации. Первая может вообще не требовать инсталляции и конфигурирования, а вторая — целого штата только для запуска.