Comments 51
1. Разработчики уже знают как делать правильно, это называется «опыт в предметной области»;
2. Приходят к хорошей системе путем непрерывного рефакторинга, стоит это бешеных денег и времени. Раза 3-4 всю системы нужно будет переписать. На практике такое возможно только в своих собственных проектах. Поэтому свои, домашние, проекты, лучше растят скилл по сравнению с коммерческой разработкой.
3. Делают как показалось вначале правильным, судорожно пытаются найти время на рефакторинг и оказываются в итоге там же, где и большинство — в левой части вашего квадрата.
Исправить такое незавидное положение можно если придумать некую алгебраическую структуру на множестве требований. Тогда «правильную» архитектуру мы сможем вычислять, с некоторой точностью. Но такого даже на горизонте нет. А пока нужно рассчитывать на опытных коллег, сообщество, общение и передачу знаний о том, что работает, а что нет.
Процедура может вернуть различные коды возврата (не равные нулю) в случае каких-либо ошибок, так как причин возникновения ошибок — множество.
В случае успешной отработки (без ошибок) процедура вернёт код возврата равный нулю (т.е. вариант успешной отработки один; а число «ноль» — также уникальное в своём роде).
Итогом работы программистов является код. Его качество напрямую зависит от "качества" собственно программиста. Следовательно, исследовать нужно причины, а не следствия. Личности, команды и их подготовку, а не их продукты.
В статье же постулируется банальность. Вероятность совпадения двух и более положительных исходов равна произведению вероятностей. А так как отдельные вероятности всегда меньше 1 вывод очевиден… Хоть Карениной, хоть аттрактором это называйте ;)
Проиллюстрируем поведение диссипативных динамических систем (между людьми есть «притяжение»).
<> Трудно иметь дело с негрубыми динамическими системами. Бесконечно малое изменение
параметров приводит к качественному изменению динамики, к другому аттрактору, другому «результату». Случай «вздорного» супруга, нестабильности психики или соматики. Не будем рассматривать, как предположительно не соответствующий счастливой семье.
<> С грубыми — существенно легче. Параметры можно «немного» изменить, а режим останется качественно неизменным.
<> Если грубая система существенно диссипативна — начальные условия («детали» встречи) и внешние воздействия играют малое значение в в наблюдаемом эксперименте, «быстро забываются», и аттрактор быстро достигается во временной реализации.
<> Если это не так, и степень сжатия элемента объема фазового пространства невелика,
приближение к аттрактору будет медленным.
— — — — — После введения, переформулируем эффект АК:
<> Мы неявно постулируем существование класса подобных семей, которые можно классифицировать как счастливые (единый аттрактор или множество некоторым образом «подобных» аттракторов).
<> {наблюдаемый режим}
Каждая счастливая семья — на неком аттракторе, который занимает малую область фазового пространства. Наблюдаемый режим семьи «ограничен». Несчастливые — в более «объемной» области наблюдаемых переменных, поведение может быть более разнообразным в каждом рассматриваемом случае. Также выше введен постулат о подобии режимов, свойство «счастье».
<> {параметры}
Внутренние характеристики каждой семьи (параметры) принадлежат множеству, соответствующему данному аттрактору «счастливая семья». В соответствии с постулатом «счастья», по-видимому, множества параметров подобны, или принадлежат одному общему множеству.
<> При анализе истории развития отношений счастливых семей, мы возможно, также обнаружим, что есть общность деталей их встречи (в каждом случае начальные условия принадлежат бассейну притяжения. Бассейны притяжения счастливых семей в первом приближении можно считать «подобными» ).
Каждый довоенный шаг участников Первой мировой кажется логичным и взвешенным, но в совокупности они привели к большой войне. Теперь я знаю как это называется. Раньше я называл это фразой из Летова (той, где всё летит в область неустойчивости). Ситуация, где любые логичные улучшения в конечном итоге ведут в пропасть. Здоровская статья, спасибо!
Либо действия некоторых участников были недостаточно продуманными, либо война и была целью некоторых, либо в целом ситуация в Европе тех лет наиболее легко могла разрешиться именно войной (по аналогии с термодинамикой — система без притока энергии сама приходит к состоянию термолинамического равновесия)
Существует ли принцип или нет, каждый решает для себя. Я считаю что он стоит в ряду с другими философскими принципами типа перехода количества в качество.
В каком-то смысли это мета-принципы, которые можно конкретизировать для конкретных областей. Я попытался сделать это для ИТ и программирования.
Кстати, а обсуждении ангоязычного варианта статьи были очень любопытные выходы. В одном из форумов пришли к заключению о необходимости референтных моделей для предметных областей и типовых процессов.
Про ITIL не знаю, но одна фирма поблагодарила меня и сообщила о расширении своего материала иныормацией об этом принципе.
А что вы конкретно понимали в «копанием» ITL и т.д.?
Очевидно, Вы относитесь как и примерно 11% процентов участвующих в опросе к скептикам относительно существования Принципа Анны Карениной.
Это Ваш личный выбор, стоит ли прислушиваться к позиции большинства коллег (по крайней мере из усастников опроса).
—
— Воняют?
— Да нет.
— От них все плачут?
— Нет.
— Если их оставить на солнце, то они темнеют и покрываются пятнами?
— Нет! Я говорю про слои! И у тех и у других есть слои, понятно?
— У тортов тоже есть слои! Значит,
Шрек (Shrek)
Следуя этой логике, если у систем с САК есть общие признаки, то они одинаково неустойчивы. Это несколько противоречит идее статьи о том, что устойчивость имеет ряд общих признаков, позволяющих ей быть устойчивой. А у неустойчивой системы нет общих признаков, которые позволяли бы ей быть неустойчивой.
Проблемы возникают из-за использования нестандартных, неопробованных, другими словами — «экзотических» решений и компонент.
Именно этим принципом на моей памяти руководствывались все менеджеры, выбирая Oracle (ведь большинство успешных компаний юзает эту СУБД). Других аргументов не было. В итоге мы приходим к некоторому стадному эффекту.
один автор недавно притянул джеб кличко как новую методологию управления проектом и линейной деятельностью.
для писателя- это полезно, набивает руку писать тексты.
вопрос в том — а какой инструмент дает чтение такой статьи читающему? Какие задачи он после прочтения станет решать по другому? что это дает его мировоззрению?
не заценили выше принцип Шрека, хорошо — есть у меня и еще:
если вам не на чем больше прокрастинировать, как на подобных статьях — то… прокрастинируйте на здоровье. если уж все равно заняться больше нечем достойным.
принцип школьника — необходимо занимать свое мышление ЧЕМ НИБУДЬ, вдруг что-то из этого (тригонометрия или толстый роман Толстого) окажется когда-нибудь полезным. а не окажется — ну
Но всё же это другая тема, имхо.
С математикой Ваша знакомая явно не в ладах. Посчитайте сами, как при паре не очень больших концертных залов, гостинице и нескольких ресторанах внутри здания можно за год заработать около 800 миллионов евро. Правда жизни такова, что город расчитывает за 20 лет отдать взятые под строительство кредиты. При этом город взял на себя много непрямых расходов по эксплуатации здания. Но знатоки относятся к этим расчётом очень скептически. И немецкое общество налогоплательщиков остро этот прект критикует.
Городской совет особенно и не возражает. Говорит что строительство затеяно из престижа, чтобы у города был символ, как у Парижа его знаменитая башня.
Вот в чём Ваша знакомая права — это с названием. Официальное название строения — Elbphilharmonie. Но в народе и даже по телевизору его всё-же часто называют оперой.
1) Разработка «сверху вниз». Сначала проектирование «на бумаге» чёткой архитектуры проекта, проработка возможностей масштабирования, выбор инструментария и т.д. Только потом непосредственная разработка.
Этим должны заниматься разные люди. «Стратеги» определяют общий план (не вдаваясь в частности), «тактики» определяют методы его реализации (при необходимости указывая «стратегам» на эти самые частности). Сообща вырабатывают наиболее оптимальные решения, тем самым страхуя друг друга от ошибок проектирования и/или реализации. Поэтому в проекте критически важно наличие специалистов обоих типов.
В противном случае чаще всего получается печально знаменитый «индусский код», в процессе отладки которого ошибки могут множиться как головы Лернейской гидры – на месте одной пофиксенной появляются две новые…
2) В команде обязательно должен быть хотя бы один аналитик с так называемым «негативным мышлением», способный думать на несколько шагов вперёд. Который, конечно же, дико замучает всех своими опасениями – но зато с высокой долей вероятности «предскажет» все возможные риски, подводные камни и прочие слабые места.
Не в обиду (и не в упрёк) будет сказано, но непосредственные разработчики нередко просто физически неспособны на подобный критический анализ всего проекта, будучи полностью загружены решением локальных технических задач.
3) По возможности ограничить использование в крупных проектах сторонних библиотек и компонентов. Согласен, что писать самим нередко дольше и сложнее. Но в своём коде всегда проще разобраться и найти проблемные места. Кроме того, в этом случае можно будет с самого начала «заточить» все необходимые модули конкретно под архитектуру текущего проекта.
Впрочем, этот пункт сугубо ИМХО. Ситуации бывают разные.
4) И, наконец – грамотный менеджмент проекта, с чётко выстроенной иерархией и чётко прописанными должностными обязанностями.
Чтобы разработчики, с одной стороны, не метались между разнородными (и порой противоречащими друг другу) указаниями и комментариями различных начальственных инстанций, а с другой стороны – и не были предоставлены сами себе, действуя «кто в лес, кто по дрова».
Причём, все обсуждения желательно фиксировать в письменном виде – хоть в тех же мессенджерах. Увы, необходимая бюрократия. Но она значительно снижает риск появления «ничейных» ошибок (поиск которых в крупных проектах подобен поиску иголки в стоге сена). Поскольку всегда можно поднять «логи» всех указаний/комментариев – за счёт чего гораздо проще выследить всю цепочку ошибочных решений. На всякий случай, уточню: это не с целью «поиска крайнего», а именно с целью локализации проблемных участков проекта.
Вот как-то так видится…
P.S. К слову, в продолжение темы безвременно усопшей госпожи Карениной (а также в тон статье), многое из вышеперечисленного применимо и наоборот – к человеческим отношениям. Круг замкнулся. ))
Причем теория о наличии двух видов теорий относится, по-моему, ко второму виду (шутка)
Время от времени и правда появляется желание все взять и обобщить.
Не все неустойчивое плохо и не все устойчивое хорошо.
Кто хоть раз в жизни переходил лужу или канаву по бревнышку, меня понимает. Неустойчиво двигаться по бревнышку лучше, чем свалиться вниз и принять в канаве устойчивое положение.
Автор статьи немного не понял смысла сказанного в книге.
Арнольд как раз говорил о том что хождение по бревнышку — является пределом устойчивости, за границей которого находится канава. То есть свалиться в канаву с бревна у нас больше шансов, чем пройти по бревну невредимым.
В общем — я думаю в определённом контексте Ваше утверждение верно.
Принцип Анны Карениной верен только при очень упрощенной модели.
Причем, если упрощать "каждая несчастливая семья несчастлива по-своему" тем же способом, которым было получено "все счастливые семьи похожи друг на друга", то получится "все счастливые похожи друг на друга, все несчастливые похожи друг на друга".
Изложение принципа в приложении к одомашниванию тоже некорректно.
Одомашнивались животные очень по разному.
Сравните кошку и собаку и их контракты на жизнь рядом с человеком.
А если упрощать, то не одомашниваемые тоже "одинаковые". Для них просто не нашлось подходящего контракта с человеком (подходящего человеку, конечно).
В реальности же можно говорить об ограниченном количестве приемлемых известных решений (то самое "одинаковое счастье" в терминах принципа Анны Каренниной).
Но однажды находится кто-то, кто находит новое решение и открывает "новый способ быть счастливым", расширяя список решений. Но люди стремятся к упрощению, и принимая новое решение забывают о чем-то старом. А потому новый способ может оказаться как действительно новым, так и давно забытым старым.
А еще хуже, когда следуя принципу Анны Карениной всех загребают под одну гребенку, объявляя что-то одно верным и каноническим, а все остальное ересью, не признавая счастье тех, кто продолжает быть счастливым "неправильно". Но те, кто вроде должен быть одинаково счастливым, частенько оказываются по разному несчастными, пытаясь следовать "единственно правильному решению проблемы счастья".
1) Принцип Анны Карениной это по-сути модель. Любая модель проще описываемой реальности. Если речь идёт о динамических системах, интересен аспект предсказательной способности модели. А она может быть и отрицательная и положительная.
2) Термин «одомашнивание животных» я использовал строго в соответствии с цитируемой книгой. Если Вы эту книгу не читали, очень советую прочитать. Если Вы под одомашниванием понимаете что-то другое, чем в книге, то сначала надо договориться о терминах. И только потом заявлять о правильности или неправильности.
3) Принцип Анны Карениной — это инструмент. Им можно пользоваться или не пользоваться. Можно пользоваться неправильно, «загребая всех под одну гребёнку».
Проблема в формулировке принципа, который провозглашается вне модели (сначала принцип, а только потом модель, соответствующая этому принципу). Формулировка слишком однозначна и не показывает цели моделирования.
Если бы формулировка была такой: "Все несчастные семьи несчастливы по своему, а счастливые нас не особо интересуют", претензий бы не было.
Так как все удачные «системы» одной и той же предметной области похожи друг на друга по объективным показателям во времени, то и каждая «система» может быть проблемная по своим субъективным показателям.
Проблемы могут возникать из-за решения лиц привлечь работников низкой квалификации с «экспериментальными» решениями, которые «проникают» в открытую и ослабленную «систему» из-за необходимости ее большей устойчивости во времени при осознаваемом обоюдном риске и энтузиазме получить эффект решения проблемы, а только потом оценку результатов (принцип «эксперимента").
Но итоге «система» выживет только так: объективная оценка — «высокая» квалификация – устойчивость системы с оценкой рисков – показатели – оценка показателей.
То есть Принципа Анны Карениной может и существует, но как недооценка или переоценка объективных показателей во времени, то есть как неудачный «эксперимент» с суммой субъективных оценок. Но остается «открытым» вопрос: нужны ли кому-то такие эксперименты?
Если ваша система не совсем хороша или совсем нехороша, но устойчива и делает своё дело (находится в неустойчиво-хорошей части мира), вам следует хорошенько подумать, а стоит ли рисковать и что-то радикально менять.
… вам можно примерять лавры чудотворца. Вы умудрились устойчиво-плохую систему запихать в неустойчиво-хороший квадрант.
Ну или злого гения.
Это я к чему — а к тому, что Принцип Анны Карениной, безусловно есть и в IT, и в других сферах, но нужно понимать, что делая что-то похожим на удачную систему, мы получаем тот же мейнстрим, который также будет хорошо сконфигурирован и использующим best practicies, актуальными прежде всего на текущий момент времени в текущей среде. Используя же экзотику, шанс нарваться на неработающий где-то приём возрастает пропорционально её экзотичности. Однако, именно экзотичность привносит что-то новое в среду, меняя её и открывая дорогу как новым приёмам, так и старым, незаслуженно забытым ранее (или точнее заслуженно, но на тот момент времени). Часто экзотика просто опережает своё время, находя применение только в, уже, другой среде. Поэтому, естественно, всегда, самым надежным и гарантированно работающим будет способ максимально близкий к успешному в данный момент времени. Но время течет, меняется среда — меняется способ, и, через n-ое количество лет, возможно никто и не подумает решать ту или иную задачу так, как сейчас может казаться безальтернативным.
Поэтому, понимание текущей среды и динамики её развития позволит как внедрять в свои системы «правильную» экзотику, так и задавать, тем самым, «моду» на мейнстрим.
Другими словами: технические законы не зависят от времени в отличие от привязанностей публики в той или иной точке нашего земного шарика.
А касательно плохоспроектированного — почему речь должна идти именно о плохоспроектированном. Можно допустим построить концепт самолёта, такой, для прочности которого нужны другие материалы, недоступные сейчас. Он не сможет летать сейчас так как хотелось бы, но сможет потом.
Если мы говорим о фундаментальных законах физики, то да, они зачастую неизменны, но и в них иногда вносятся поправки временем, как в закон всемирного тяготения Ньютона например. А если говорить о среде, тут дело другое — сейчас мы летаем на самолётах, но кто сказал, что потом не будем летать на условных летающих тарелках с антигравитационной тягой, а не турбореактивной и какие-то инженерные идеи пригодятся для них, а какие-то канут в лету, а может так станется, что вспомнится какая-то ранее забракованная идея, которая вполне будет уживаться в рамках полётов на летающих тарелках. Вопрос во взятом масштабе.
Принцип Анны Карениной в программировании и ИТ