В последнее время меня все больше интересуют научные подходы к анализу сложности и стабильности программного решения. Причем, не столько "метрики сложности" вроде цикломатики или связности (или количества строк кода, не к ночи будет помянуто), а больше способы предварительной оценки.
К примеру, во многих случаях прозрачный и понятный переход от квадратиков на доске к построению мат. модели предлагаемой архитектуры с последующим расчетом неких показателей, идентифициющих "хорошесть" или "ужасность" решения в рамках определенных требований, вероятностей тех или иных событий, нам конкретно помог бы сэкономить тысячи человеко-часов и перевести архитектурные войны в более конструктивное русло дискуссий.
Уже переворошил кучу в том числе научных работ, и такое ощущение, что изыскания по этой теме кончились в середине 80-х (или я не там ищу), да и затрагивали в основном уже написанный код.
L>К примеру, во многих случаях прозрачный и понятный переход от квадратиков на доске к построению мат. модели предлагаемой архитектуры с последующим расчетом неких показателей, идентифициющих "хорошесть" или "ужасность" решения в рамках определенных требований, вероятностей тех или иных событий, нам конкретно помог бы сэкономить тысячи человеко-часов и перевести архитектурные войны в более конструктивное русло дискуссий.
А на чем именно терялось время и что есть архитектурные войны в вашем случае. Есть ощущения, что не в том направлении копаешь.
Здравствуйте, 0x7be, Вы писали:
L>>К примеру, во многих случаях прозрачный и понятный переход от квадратиков на доске к построению мат. модели предлагаемой архитектуры с последующим расчетом неких показателей, идентифициющих "хорошесть" или "ужасность" решения в рамках определенных требований, вероятностей тех или иных событий, нам конкретно помог бы сэкономить тысячи человеко-часов и перевести архитектурные войны в более конструктивное русло дискуссий. 0>А на чем именно терялось время и что есть архитектурные войны в вашем случае. Есть ощущения, что не в том направлении копаешь.
Элементарно. То, что очевидно одному, совсем не очевидно другому. Прийти к общему знаменателю бывает чрезвычайно трудно.
Здравствуйте, landerhigh, Вы писали:
L>Элементарно. То, что очевидно одному, совсем не очевидно другому. Прийти к общему знаменателю бывает чрезвычайно трудно.
Ну так это выглядит как проблема из "человеческой плоскости" — разрыв в квалификации, провал в коммуникативных навыках — способности конструктивно обсуждать различия во взглядах на проблему и находить этот самый знаменатель. Я сомневаюсь, что это можно решить техническими средствами, применив некую научную наработку из области анализа сложности.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, landerhigh, Вы писали:
L>>Элементарно. То, что очевидно одному, совсем не очевидно другому. Прийти к общему знаменателю бывает чрезвычайно трудно. 0>Ну так это выглядит как проблема из "человеческой плоскости" — разрыв в квалификации, провал в коммуникативных навыках — способности конструктивно обсуждать различия во взглядах на проблему и находить этот самый знаменатель. Я сомневаюсь, что это можно решить техническими средствами, применив некую научную наработку из области анализа сложности.
Да нет, проблема возникает как рза, когда все вроде на одной волне. Просто один считает, что требование А — важно, другой считает, что она даже не заслуживает обсуждения, третьи хотят в архитектуру затащить вообще все, что могут представить и так далее. Сама возможность перейти от словесной перепалке к взвешенной метрике позволила бы по крайней мере наложить фильтр на дискуссию.
Кроме того, индикатор переусложненности архитектуры также мог бы основываться на каких-либо нормализованных входных данных.
Почему мне это вообще интересно? Есть такая штука, как интуиция. Бывает, начинаешь делать некий сферический в вакууме модуль Х. Нарисовал квадратики, приступил к работе и интуитивно понимаешь, что решение, которое получается, некрасиво, хотя и показать этого не можешь. Интуиция все же на чем-то основывается, поэтому, КМК, должна существовать возможность перехода к некой абстрактной модели, в которой некрасивости можно будет банально подсчитать по формуле. Например, слишком большое число состояний модуля, слишком большое количество входов/выходов, наличие непересечающихся областей ответственности и так далее.
Здравствуйте, landerhigh, Вы писали: L>Почему мне это вообще интересно? Есть такая штука, как интуиция. Бывает, начинаешь делать некий сферический в вакууме модуль Х. Нарисовал квадратики, приступил к работе и интуитивно понимаешь, что решение, которое получается, некрасиво, хотя и показать этого не можешь. Интуиция все же на чем-то основывается, поэтому, КМК, должна существовать возможность перехода к некой абстрактной модели, в которой некрасивости можно будет банально подсчитать по формуле. Например, слишком большое число состояний модуля, слишком большое количество входов/выходов, наличие непересечающихся областей ответственности и так далее.
На индивидуальном опыте.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, landerhigh, Вы писали:
L>Да нет, проблема возникает как рза, когда все вроде на одной волне. Просто один считает, что требование А — важно, другой считает, что она даже не заслуживает обсуждения, третьи хотят в архитектуру затащить вообще все, что могут представить и так далее. Сама возможность перейти от словесной перепалке к взвешенной метрике позволила бы по крайней мере наложить фильтр на дискуссию.
Это уже давно и эффективно решается введением параметра business value, за который обычно отвечают аналитики, составляющие требования. Если требования не приоретизированы адекватно, то вместо хорошего продукта получается бесполезный набор фич.
L>Почему мне это вообще интересно? Есть такая штука, как интуиция. Бывает, начинаешь делать некий сферический в вакууме модуль Х. Нарисовал квадратики, приступил к работе и интуитивно понимаешь, что решение, которое получается, некрасиво, хотя и показать этого не можешь. Интуиция все же на чем-то основывается, поэтому, КМК, должна существовать возможность перехода к некой абстрактной модели, в которой некрасивости можно будет банально подсчитать по формуле. Например, слишком большое число состояний модуля, слишком большое количество входов/выходов, наличие непересечающихся областей ответственности и так далее.
Оценивать архитектуру безотносительно требований нет смысла. Если есть конкретные требования, то на любой элемент решения можно тыкнуть пальцем и спросить зачем он нужен и насколько он приближает к решению задачи.
Здравствуйте, landerhigh, Вы писали: L>Кроме того, индикатор переусложненности архитектуры также мог бы основываться на каких-либо нормализованных входных данных.
я предлагаю качеством архитектуры называть число, которое можно определить по статистике изменений кода. Посчитайте сколько в среднем мест в коде нужно поменять, если вы хотите поменять только одну вещь. Вот эта чиселка и может сказать о качестве архитетуры и даже позволит сравнивать приложения по качеству кода между собой.
Здравствуйте, landerhigh, Вы писали:
L>Да нет, проблема возникает как рза, когда все вроде на одной волне. Просто один считает, что требование А — важно, другой считает, что она даже не заслуживает обсуждения, третьи хотят в архитектуру затащить вообще все, что могут представить и так далее. Сама возможность перейти от словесной перепалке к взвешенной метрике позволила бы по крайней мере наложить фильтр на дискуссию.
Ну так это, опять же, не техническая проблема, а проблема несовпадения понимания целей и value участниками процесса. Нужность той или иной фитчи оценивается из понимания целей проект. Если возникает спор, значит понимание разное. Вполне вероятно, что эти цели явно не выявлены и неявно подразумеваются оппонентами.
L>Кроме того, индикатор переусложненности архитектуры также мог бы основываться на каких-либо нормализованных входных данных.
"Переусложенность" архитектуры — это абстракция.
Ты что-то посчитаешь и получишь некое число, что ты потом с ним будешь делать?
(Можно теперь спорить о том, является ли это число слишком большим или нет )
L>Почему мне это вообще интересно? Есть такая штука, как интуиция. Бывает, начинаешь делать некий сферический в вакууме модуль Х. Нарисовал квадратики, приступил к работе и интуитивно понимаешь, что решение, которое получается, некрасиво, хотя и показать этого не можешь. Интуиция все же на чем-то основывается, поэтому, КМК, должна существовать возможность перехода к некой абстрактной модели, в которой некрасивости можно будет банально подсчитать по формуле. Например, слишком большое число состояний модуля, слишком большое количество входов/выходов, наличие непересечающихся областей ответственности и так далее.
Я думаю, что ты решаешь не ту проблему. Я вижу проблему в том, как у вас поставлена работа с требованиями и problem solving.
Трудности с архитектурой — это лишь симптом, а не проблема.
Здравствуйте, landerhigh, Вы писали:
L>Да нет, проблема возникает как рза, когда все вроде на одной волне. Просто один считает, что требование А — важно, другой считает, что она даже не заслуживает обсуждения, третьи хотят в архитектуру затащить вообще все, что могут представить и так далее. Сама возможность перейти от словесной перепалке к взвешенной метрике позволила бы по крайней мере наложить фильтр на дискуссию.
Метрика не поможет, т.к. она не решает исходную проблему — разные точки зрения на разработку в команде. Самое забавное, что это вообще не проблема. Напротив, это возможность эффективно раскидать задачи, чтобы никто не ушёл обиженным
При поставленном процессе разработке её стремятся не убрать а использовать по максимуму. Например, SkyDance расписывал как это делается в скраме
L>Почему мне это вообще интересно? Есть такая штука, как интуиция. Бывает, начинаешь делать некий сферический в вакууме модуль Х. Нарисовал квадратики, приступил к работе и интуитивно понимаешь, что решение, которое получается, некрасиво, хотя и показать этого не можешь.
А не проще будет разобраться, почему вообще интуиция "выстреливает" только на этапе написания кода?
L>Интуиция все же на чем-то основывается, поэтому, КМК, должна существовать возможность перехода к некой абстрактной модели, в которой некрасивости можно будет банально подсчитать по формуле. Например, слишком большое число состояний модуля, слишком большое количество входов/выходов, наличие непересечающихся областей ответственности и так далее.
Мозг человека насквозь прагматичен, за "красиво-некрасиво" скрывается банальное нежелание делать лишнюю работу — переписывать код, держать в голове лишние детали, вспоминать костыли через полгода спусти и т.п. и т.д.
Если мы отбросим блаватского, ноосферу и прочую торсионщину, то придётся признать что в работе подсознания нет никакой магии, оно исходит ровно из того же, что известно вам лично: из опыта решения похожих проблем, знания матчасти, понимания задачи и способности спрогнозировать дальнейшее развитие событий.
Первые два пункта формализовать не получится никак, следовательно полной формальной модели не будет. Не, если пойти на принцип, всё возможно, но затраты на составление настолько детальной модели будут (как минимум) сопоставимы с написанием кода.
Теперь посмотрим на оставшееся:
С "пониманием" всё непросто — поверхностная оценка недалеко уйдёт от квадратиков на бумаге, детальная — со всеми связями и зависимостями — снова будет практически неотличима от кода.
С прогнозированием всё ещё хуже. Во-первых, вам потребуется модель задачи из предыдущего пункта + возможные будущие требования. Во-вторых, придётся ввести оценочную функцию для каждого из элементов решения — вероятность + стоимость изменения для конкретного требования. В-третьих — попробовать перестроить текущую модель так, чтобы минимизировать стоимость реализации будущих требований. Каждый из пунктов тянет на полноценную докторскую, в особенности третий — это NP-полная задача сопоставимая по сложности с "пчёлы vs задача коммивояжёра".
Поскольку никакой магии в работе подсознания таки нет, то ответы нашей формальной модели ничем не будут отличаться от нашей интуиции — "чую, что дело бесовское, но обосновать не могу"(с). В общем, по соотношению затраты-выхлоп вся затея очень напоминает вот это
Всё, что тут можно сделать — это не пытаться промоделировать сложную проблему, а попробовать свести сложную задачу к чуть менее сложной. Тут всего два варианта и в любом из них формальной моделью всего и близко не пахнет.
Во-первых, можно снизить стоимость "лишней работы" или хотя бы сделать её предсказуемой — вокруг этого пляшут агилисты с TDD, тяжёлый Rup/MSF, и инстурменты разработки — статическая верификация/тесты/анализ кода etc.
Во-вторых, можно сделать так, чтобы подсознание эффективно работало ещё на стадии "квадратики на листе", т.е. найти способ однозначно и полноценно описать модель/требования на естественном языке. Насколько знаю, с этой стороны заходит только в DDD.
На практике, разумеется используются оба подхода, как правило — неосознанно, просто потому, что оно работает.
Здравствуйте, landerhigh, Вы писали:
L>Элементарно. То, что очевидно одному, совсем не очевидно другому. Прийти к общему знаменателю бывает чрезвычайно трудно.
Почему бы не решить это разделением ответственности?
Здравствуйте, landerhigh, Вы писали:
L>Почему мне это вообще интересно? Есть такая штука, как интуиция. Бывает, начинаешь делать некий сферический в вакууме модуль Х. Нарисовал квадратики, приступил к работе и интуитивно понимаешь, что решение, которое получается, некрасиво, хотя и показать этого не можешь. Интуиция все же на чем-то основывается, поэтому, КМК, должна существовать возможность перехода к некой абстрактной модели, в которой некрасивости можно будет банально подсчитать по формуле. Например, слишком большое число состояний модуля, слишком большое количество входов/выходов, наличие непересечающихся областей ответственности и так далее.
Это то как раз не интуиция а вполне понятные метрики.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, landerhigh, Вы писали:
L>>Да нет, проблема возникает как рза, когда все вроде на одной волне. Просто один считает, что требование А — важно, другой считает, что она даже не заслуживает обсуждения, третьи хотят в архитектуру затащить вообще все, что могут представить и так далее. Сама возможность перейти от словесной перепалке к взвешенной метрике позволила бы по крайней мере наложить фильтр на дискуссию. G>Это уже давно и эффективно решается введением параметра business value, за который обычно отвечают аналитики, составляющие требования. Если требования не приоретизированы адекватно, то вместо хорошего продукта получается бесполезный набор фич.
Бизнес велью к вопросу не имеет никакого отношения. Считайте, что все фичи имеют одинаковое значение.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, landerhigh, Вы писали: L>>Кроме того, индикатор переусложненности архитектуры также мог бы основываться на каких-либо нормализованных входных данных. __>я предлагаю качеством архитектуры называть число, которое можно определить по статистике изменений кода. Посчитайте сколько в среднем мест в коде нужно поменять, если вы хотите поменять только одну вещь. Вот эта чиселка и может сказать о качестве архитетуры и даже позволит сравнивать приложения по качеству кода между собой.
Я что-то подобное давно применяю, называю правило "what if". Для прикидки гибкости решения. Интересно, можно ли подобное формализовать.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, landerhigh, Вы писали:
L>>Да нет, проблема возникает как рза, когда все вроде на одной волне. Просто один считает, что требование А — важно, другой считает, что она даже не заслуживает обсуждения, третьи хотят в архитектуру затащить вообще все, что могут представить и так далее. Сама возможность перейти от словесной перепалке к взвешенной метрике позволила бы по крайней мере наложить фильтр на дискуссию. 0>Ну так это, опять же, не техническая проблема, а проблема несовпадения понимания целей и value участниками процесса. Нужность той или иной фитчи оценивается из понимания целей проект. Если возникает спор, значит понимание разное. Вполне вероятно, что эти цели явно не выявлены и неявно подразумеваются оппонентами.
Вот и я о чем. Я о Фоме, а ты о Ереме.
Еще раз — важность фич не обсуждается. Если угодно, они все одинаково важны.
Обсуждается вопрос планирования и реализации этих фич с как можно более ранним отсевом предложений сделать холодильник и пылесос одним устройством.
L>>Кроме того, индикатор переусложненности архитектуры также мог бы основываться на каких-либо нормализованных входных данных. 0>"Переусложенность" архитектуры — это абстракция. 0>Ты что-то посчитаешь и получишь некое число, что ты потом с ним будешь делать?
Смотря какой смысл в это число вкладывать. Например, число зон ответственности модуля. Число непересекающихся зон ответственности. Пересечение ответственности между модулями
0>(Можно теперь спорить о том, является ли это число слишком большим или нет )
L>>Почему мне это вообще интересно? Есть такая штука, как интуиция. Бывает, начинаешь делать некий сферический в вакууме модуль Х. Нарисовал квадратики, приступил к работе и интуитивно понимаешь, что решение, которое получается, некрасиво, хотя и показать этого не можешь. Интуиция все же на чем-то основывается, поэтому, КМК, должна существовать возможность перехода к некой абстрактной модели, в которой некрасивости можно будет банально подсчитать по формуле. Например, слишком большое число состояний модуля, слишком большое количество входов/выходов, наличие непересечающихся областей ответственности и так далее. 0>Я думаю, что ты решаешь не ту проблему. Я вижу проблему в том, как у вас поставлена работа с требованиями и problem solving.
Не надо ничего за нас додумывать, окей? Если по теме нечего сказать, то проходи мимо.
Мне интересно выделенное, свою интуицию всем не одолжишь.
0>Трудности с архитектурой — это лишь симптом, а не проблема.
Именно что симптом. Чтобы вылечить проблему, хочется понять, существует ли в принципе возможность формального обоснования архитектурного решения на этапе его планирования, выходящая за рамки разговора у доски
S>Метрика не поможет, т.к. она не решает исходную проблему — разные точки зрения на разработку в команде. Самое забавное, что это вообще не проблема. Напротив, это возможность эффективно раскидать задачи, чтобы никто не ушёл обиженным
Можешь считать, что этой проблемы не существует. Вся команда стоит у доски, чешет репу и хором говорит, что решение вроде хорошее, но что-то не так.
S>При поставленном процессе разработке её стремятся не убрать а использовать по максимуму. Например, SkyDance расписывал как это делается в скраме
Я и сам могу уже трехтомник о скраме написать. А воз и ныне там.
S>
L>>Почему мне это вообще интересно? Есть такая штука, как интуиция. Бывает, начинаешь делать некий сферический в вакууме модуль Х. Нарисовал квадратики, приступил к работе и интуитивно понимаешь, что решение, которое получается, некрасиво, хотя и показать этого не можешь. S>А не проще будет разобраться, почему вообще интуиция "выстреливает" только на этапе написания кода?
Это просто пример. Она выстреливает всегда, просто на этапе кодирования косяки банально выясняются на примере. Когда говорим о более абстрактных вещах, без применения каких-либо формальных метрик обосновывать бывает нечем.
L>>Интуиция все же на чем-то основывается, поэтому, КМК, должна существовать возможность перехода к некой абстрактной модели, в которой некрасивости можно будет банально подсчитать по формуле. Например, слишком большое число состояний модуля, слишком большое количество входов/выходов, наличие непересечающихся областей ответственности и так далее.
S>Если мы отбросим блаватского, ноосферу и прочую торсионщину, то придётся признать что в работе подсознания нет никакой магии, оно исходит ровно из того же, что известно вам лично: из опыта решения похожих проблем, знания матчасти, понимания задачи и способности спрогнозировать дальнейшее развитие событий.
S>Первые два пункта формализовать не получится никак, следовательно полной формальной модели не будет. Не, если пойти на принцип, всё возможно, но затраты на составление настолько детальной модели будут (как минимум) сопоставимы с написанием кода.
S>Теперь посмотрим на оставшееся: S>С "пониманием" всё непросто — поверхностная оценка недалеко уйдёт от квадратиков на бумаге, детальная — со всеми связями и зависимостями — снова будет практически неотличима от кода.
Если поверхностная оценка позволяет принять решение на ее основе, то это уже будет очень и очень хорошо. Рисовать все квадратики заранее оставим апологетам RUP.
S>С прогнозированием всё ещё хуже. Во-первых, вам потребуется модель задачи из предыдущего пункта + возможные будущие требования. Во-вторых, придётся ввести оценочную функцию для каждого из элементов решения — вероятность + стоимость изменения для конкретного требования. В-третьих — попробовать перестроить текущую модель так, чтобы минимизировать стоимость реализации будущих требований. Каждый из пунктов тянет на полноценную докторскую, в особенности третий — это NP-полная задача сопоставимая по сложности с "пчёлы vs задача коммивояжёра".
А вот это уже интересно.
На самом деле некие признаки формальной модели вырисовываются. Но судя по имеющимся материалам, это и правда на несколько докторских тянет.
Здравствуйте, landerhigh, Вы писали:
L>Не надо ничего за нас додумывать, окей? Если по теме нечего сказать, то проходи мимо.
Я считаю, что я говорю по теме.
Впрочем, видимо я и правда пойду.
Здравствуйте, landerhigh, Вы писали:
L>Можешь считать, что этой проблемы не существует. Вся команда стоит у доски, чешет репу и хором говорит, что решение вроде хорошее, но что-то не так.
Согласитесь, в этом случае проблема на 1000% состоит не в отсутствии формальной метрики Я бы поставил на то, что модель на доске не покрывает всех сценариев или недостаточно проста в реализации. Если угадал — никакая формальная метрика тут не поможет: проблема — не в функции оценки, а в анализе входных данных. Соответственно, копать надо в эту сторону.
L>Я и сам могу уже трехтомник о скраме написать. А воз и ныне там.
Так никто и не говорил что скрам идеален. По ссылке — весьма неплохая методика оценки входных требований, которая работает даже если вы не используете скрам в целом. Ну, или не работает, это как повезёт
S>>А не проще будет разобраться, почему вообще интуиция "выстреливает" только на этапе написания кода? L>Это просто пример. Она выстреливает всегда, просто на этапе кодирования косяки банально выясняются на примере. Когда говорим о более абстрактных вещах, без применения каких-либо формальных метрик обосновывать бывает нечем.
С абстрактными вещами проще бороться с помощью анализа требований — стараться не допускать, чтобы на дизайн влияли сиюминутные требования, которые могут легко поменяться в будущем.
С выявлением косяков на этапе кодирования — представлением сценариев использования в виде вызовов методов вашего API. Получим разделение функционала на куски с ограниченной ответственностью. Их написать и поддерживать — гораздо проще, чем монолитный кусок кода.
S>>С "пониманием" всё непросто — поверхностная оценка недалеко уйдёт от квадратиков на бумаге, детальная — со всеми связями и зависимостями — снова будет практически неотличима от кода. L>Если поверхностная оценка позволяет принять решение на ее основе, то это уже будет очень и очень хорошо. Рисовать все квадратики заранее оставим апологетам RUP.
Тогда вам нужно вносить в модель только значимые требования, иначе всякая мелочёвка перетянет одеяло на себя. Если такой способ разделения требований есть — достаточно самих квадратиков, формальная оценка тут не поможет. Если нет — тем более: мусор на входе — мусор на выходе.
S>>Каждый из пунктов тянет на полноценную докторскую, в особенности третий — это NP-полная задача сопоставимая по сложности с "пчёлы vs задача коммивояжёра". L>А вот это уже интересно. L>На самом деле некие признаки формальной модели вырисовываются. Но судя по имеющимся материалам, это и правда на несколько докторских тянет.
Ну да, по трудоёмкости это будет тот же код. Только без собственно кода.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, landerhigh, Вы писали:
L>>>Да нет, проблема возникает как рза, когда все вроде на одной волне. Просто один считает, что требование А — важно, другой считает, что она даже не заслуживает обсуждения, третьи хотят в архитектуру затащить вообще все, что могут представить и так далее. Сама возможность перейти от словесной перепалке к взвешенной метрике позволила бы по крайней мере наложить фильтр на дискуссию. G>>Это уже давно и эффективно решается введением параметра business value, за который обычно отвечают аналитики, составляющие требования. Если требования не приоретизированы адекватно, то вместо хорошего продукта получается бесполезный набор фич.
L>Бизнес велью к вопросу не имеет никакого отношения.
Имеет, всегда, даже если вы этого не хотите или не знаете.
L>Считайте, что все фичи имеют одинаковое значение.
Так не бывает. Всегда можно упорядочить фичи по важности.
Для начала вам всегда требуется выбрать тот набор требований\фич\сценариев, которые необходимо покрыть вашим решением. Когда такой набор сформирован, то стандартные метрики, типа Mantainability Index, помогают оценить качество того что сделано.
)
.