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

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

Кажется, что корень всех зол в том, что мы (разработчики ПО) не умеем произвольно взятую задачу «правильно» декомпозировать на модули. Всякие умные подходы вроде ООП, MVC, DDD, Viper и т.п. не особо в этом помогают. Если представить все варианты реализаций требований как множество, то похоже, в этом множестве лишь немногие точки отвечают «хорошей» системе. В итоге три варианта:
1. Разработчики уже знают как делать правильно, это называется «опыт в предметной области»;
2. Приходят к хорошей системе путем непрерывного рефакторинга, стоит это бешеных денег и времени. Раза 3-4 всю системы нужно будет переписать. На практике такое возможно только в своих собственных проектах. Поэтому свои, домашние, проекты, лучше растят скилл по сравнению с коммерческой разработкой.
3. Делают как показалось вначале правильным, судорожно пытаются найти время на рефакторинг и оказываются в итоге там же, где и большинство — в левой части вашего квадрата.

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

Все здоровые люди похожи друг на друга, каждый больной человек болен по-своему?

{краткое нестрогое ночное замечание от невыспавшегося радиофизика}
Проиллюстрируем поведение диссипативных динамических систем (между людьми есть «притяжение»).
<> Трудно иметь дело с негрубыми динамическими системами. Бесконечно малое изменение
параметров приводит к качественному изменению динамики, к другому аттрактору, другому «результату». Случай «вздорного» супруга, нестабильности психики или соматики. Не будем рассматривать, как предположительно не соответствующий счастливой семье.
<> С грубыми — существенно легче. Параметры можно «немного» изменить, а режим останется качественно неизменным.
<> Если грубая система существенно диссипативна — начальные условия («детали» встречи) и внешние воздействия играют малое значение в в наблюдаемом эксперименте, «быстро забываются», и аттрактор быстро достигается во временной реализации.
<> Если это не так, и степень сжатия элемента объема фазового пространства невелика,
приближение к аттрактору будет медленным.
— — — — — После введения, переформулируем эффект АК:
<> Мы неявно постулируем существование класса подобных семей, которые можно классифицировать как счастливые (единый аттрактор или множество некоторым образом «подобных» аттракторов).
<> {наблюдаемый режим}
Каждая счастливая семья — на неком аттракторе, который занимает малую область фазового пространства. Наблюдаемый режим семьи «ограничен». Несчастливые — в более «объемной» области наблюдаемых переменных, поведение может быть более разнообразным в каждом рассматриваемом случае. Также выше введен постулат о подобии режимов, свойство «счастье».
<> {параметры}
Внутренние характеристики каждой семьи (параметры) принадлежат множеству, соответствующему данному аттрактору «счастливая семья». В соответствии с постулатом «счастья», по-видимому, множества параметров подобны, или принадлежат одному общему множеству.
<> При анализе истории развития отношений счастливых семей, мы возможно, также обнаружим, что есть общность деталей их встречи (в каждом случае начальные условия принадлежат бассейну притяжения. Бассейны притяжения счастливых семей в первом приближении можно считать «подобными» ).

я бы дополнил принцип Анны К. принципом Шрека (с уточнениями от Ослика):
— Людоеды ИТ технологии и решения — как лук.
— Воняют?
— Да нет.
— От них все плачут?
— Нет.
— Если их оставить на солнце, то они темнеют и покрываются пятнами?
— Нет! Я говорю про слои! И у тех и у других есть слои, понятно?
— У тортов тоже есть слои! Значит, ты ИТ — как торт? »
Шрек (Shrek)

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

Попробую продолжить правильную мысль andreyverbin – и чуть более расширенно описать факторы, благодаря которым, на мой взгляд (цитата) «Все удачные системы одной и той же предметной области похожи друг на друга». Понимаю, что сейчас выступлю в роли Кэпа. Но оно работает. Хотя, к сожалению, об этих простейших вещах часто забывают, что и порождает пресловутый САК…

1) Разработка «сверху вниз». Сначала проектирование «на бумаге» чёткой архитектуры проекта, проработка возможностей масштабирования, выбор инструментария и т.д. Только потом непосредственная разработка.
Этим должны заниматься разные люди. «Стратеги» определяют общий план (не вдаваясь в частности), «тактики» определяют методы его реализации (при необходимости указывая «стратегам» на эти самые частности). Сообща вырабатывают наиболее оптимальные решения, тем самым страхуя друг друга от ошибок проектирования и/или реализации. Поэтому в проекте критически важно наличие специалистов обоих типов.
В противном случае чаще всего получается печально знаменитый «индусский код», в процессе отладки которого ошибки могут множиться как головы Лернейской гидры – на месте одной пофиксенной появляются две новые…

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

3) По возможности ограничить использование в крупных проектах сторонних библиотек и компонентов. Согласен, что писать самим нередко дольше и сложнее. Но в своём коде всегда проще разобраться и найти проблемные места. Кроме того, в этом случае можно будет с самого начала «заточить» все необходимые модули конкретно под архитектуру текущего проекта.
Впрочем, этот пункт сугубо ИМХО. Ситуации бывают разные.

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

Вот как-то так видится…

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

Не все неустойчивое плохо и не все устойчивое хорошо.

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

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

Прочитал с удовольствием! ИМХО статья есть иллюстрация к понятию энтропии.

Как раз в ИТ наблюдается обратное — схожие проблемы успешно решаются совершенно разными способами.

Задумался, а не является ли вариантом «Принципа Анны Карениной» старая сентенция: «Лучшее враг хорошего». Все «хорошее» более однородно чем «лучшее».

Я попытался в своей статьи оттолкнутся от филослфской части Принципа Анны Карениной и перейти к его конкретным проявлениям в области программирования и ИТ. Движение в противоположном направлении чревато издишним обощением у которого, как отметил PerlPower очень низкая предсказательная способность. Такие обощения описываются в частности фразами народной мудрости, фольклёром и т.д.
В общем — я думаю в определённом контексте Ваше утверждение верно.

С многими тезисами из статьи достаточно часто сталкиваюсь.

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

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

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

Я не согласен со всеми Вашими заявлениями.
1) Принцип Анны Карениной это по-сути модель. Любая модель проще описываемой реальности. Если речь идёт о динамических системах, интересен аспект предсказательной способности модели. А она может быть и отрицательная и положительная.
2) Термин «одомашнивание животных» я использовал строго в соответствии с цитируемой книгой. Если Вы эту книгу не читали, очень советую прочитать. Если Вы под одомашниванием понимаете что-то другое, чем в книге, то сначала надо договориться о терминах. И только потом заявлять о правильности или неправильности.
3) Принцип Анны Карениной — это инструмент. Им можно пользоваться или не пользоваться. Можно пользоваться неправильно, «загребая всех под одну гребёнку».

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

В музыке есть такое понятие как мейнстрим. В отличие от других направлений, мейнстрим, в среднем, не противоречит радикально вкусам большинства, подходит под большинство ситуаций и при этом не вызывает ощущения сильного диссонанса, тогда как андеграунд сцена, классическая или этническая музыка, например, подходят чаще только под конкретные ситуации, и, к тому же, имеют как своих отдельных ценителей, так и ярых противников, для которых большая часть того или иного жанра является явно неприемлимой для восприятия. Всё дело в природе мейнстрима, который постоянно вовлекает в своё звучание и мисседж отдельные элементы, наиболее удачные, с точки зрения восприятия окружающими, из других стилей и жанров. Эти элементы соответствуют конкретному культурному «состоянию», в котором они звучат уместно (современно, модно). Также из мейнстрима удаляются «устаревшие» элементы, по тем же критериям, соответственно. Что характерно, другие стили также не стоят на месте и, вместе со своим развитием, часто плодят новые жанры. И, не стоит забывать, что отброшенные прежде музыкальные элементы часто находят себе вторую жизнь как в новых для них стилях, так и возвращаясь в старые, уже после, и в других сочетаниях, порождая новое общее звучание и мисседж. То есть, получается одна стабильная линия, которая хоть и устойчивая, но достигающая эту самую устойчивость за счет своей непрерывной изменчивости, и, множество менее стабильных, часто сильно флуктирующих, но вместе с тем порождающих нужные мутации, в том числе и для «стабильной».
Это я к чему — а к тому, что Принцип Анны Карениной, безусловно есть и в IT, и в других сферах, но нужно понимать, что делая что-то похожим на удачную систему, мы получаем тот же мейнстрим, который также будет хорошо сконфигурирован и использующим best practicies, актуальными прежде всего на текущий момент времени в текущей среде. Используя же экзотику, шанс нарваться на неработающий где-то приём возрастает пропорционально её экзотичности. Однако, именно экзотичность привносит что-то новое в среду, меняя её и открывая дорогу как новым приёмам, так и старым, незаслуженно забытым ранее (или точнее заслуженно, но на тот момент времени). Часто экзотика просто опережает своё время, находя применение только в, уже, другой среде. Поэтому, естественно, всегда, самым надежным и гарантированно работающим будет способ максимально близкий к успешному в данный момент времени. Но время течет, меняется среда — меняется способ, и, через n-ое количество лет, возможно никто и не подумает решать ту или иную задачу так, как сейчас может казаться безальтернативным.
Поэтому, понимание текущей среды и динамики её развития позволит как внедрять в свои системы «правильную» экзотику, так и задавать, тем самым, «моду» на мейнстрим.