Здравствуйте, landerhigh, Вы писали:
L>В последнее время меня все больше интересуют научные подходы к анализу сложности и стабильности программного решения. Причем, не столько "метрики сложности" вроде цикломатики или связности (или количества строк кода, не к ночи будет помянуто), а больше способы предварительной оценки.
L>К примеру, во многих случаях прозрачный и понятный переход от квадратиков на доске к построению мат. модели предлагаемой архитектуры с последующим расчетом неких показателей, идентифициющих "хорошесть" или "ужасность" решения в рамках определенных требований, вероятностей тех или иных событий, нам конкретно помог бы сэкономить тысячи человеко-часов и перевести архитектурные войны в более конструктивное русло дискуссий.
L>Уже переворошил кучу в том числе научных работ, и такое ощущение, что изыскания по этой теме кончились в середине 80-х (или я не там ищу), да и затрагивали в основном уже написанный код.
L>Накидайте ссылок, пожалуйста.
У меня сложилось впечатление, что метрики измерют только сами метрики, а как эти измеренные значения относятся к сложности программы одному богу известно. Ну не поддается воображение программиста сухой статистике, ну и ладно. Хотя можно применить принцип забивания гвоздей, всех заставить писать единообразно. Например, долой все программы с нечетным количеством строк кода !!! Тоже своего рода метрика, можно измерить и подискутировать что лучше листинги с четным и нечетным количеством строчек?
Здравствуйте, landerhigh, Вы писали: L>В последнее время меня все больше интересуют научные подходы к анализу сложности и стабильности программного решения. Причем, не столько "метрики сложности" вроде цикломатики или связности (или количества строк кода, не к ночи будет помянуто), а больше способы предварительной оценки. L>Накидайте ссылок, пожалуйста.
Я не встречал интересных ссылок по теме и даже особо не интересовался методами анализа решений, но разбирал сам процесс построения решений, думаю, ниже написанное вам пригодится.
Итак, готовое решение некоторой задачи/проблемы можно представить в виде дерева, состоящего из более мелких(промежуточных) решений, навроде:
Создание решения это собственно построение этого дерева, "решение за решением"(образно можно представить что дерево растёт от корня, и когда все ветки достигают нижнего уровня — решение готово), но это не линейный процесс, некоторые ветки выходят(или могут выйти по мнению разработчиков) за рамки требований, что приводи к их откату и затем перестраиванию, а в худшем случае, и всех связанных с ними веток. Откат может быть небольшим(до предыдущего решения), но может быть и огромным, вплоть до корня.
На этой модели, кстати, можно показать отличия водопадного и итеративного подходов к разработке. Первый предписывает дереву равномерно расти сверху вниз не выходя за рамки требований, второй предписывает в начале как можно быстрей достичь нижнего уровня, даже ценой нарушения некоторых требований, затем расти/уменьшатся в ширь(в цикле перестраиваний), чтобы таки вписаться в рамки требований. L>К примеру, во многих случаях прозрачный и понятный переход от квадратиков на доске к построению мат. модели предлагаемой архитектуры с последующим расчетом неких показателей, идентифициющих "хорошесть" или "ужасность" решения в рамках определенных требований, вероятностей тех или иных событий, нам конкретно помог бы сэкономить тысячи человеко-часов и перевести архитектурные войны в более конструктивное русло дискуссий.
Проблема в том что не возможно однозначно сказать что какое-то из промежуточных решений(например решение D21), принятых при разработке, хорошее/плохое, до тех пор, пока решение задачи не будет _полностью_ готово. Потому что пока задача не решена, для этого не достаточно информации(она ещё не создана, её попросту не существует). Но "хорошесть" или "ужасность" решения можно предположить с некоторой вероятностью, основываясь на информации о текущем состоянии разработки и опыта использования подобного решения в подобных задачах, это пытаются реализовать разработчики аналитических, экспертных систем и прочих ИИ. L>Уже переворошил кучу в том числе научных работ, и такое ощущение, что изыскания по этой теме кончились в середине 80-х (или я не там ищу), да и затрагивали в основном уже написанный код.
ИМХО, они упёрлись в проблему "у нас нету штуковины способной учится и анализировать лучше чем человек" и бросили все силы на её решение.
или
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, landerhigh, Вы писали:
L>Бизнес велью к вопросу не имеет никакого отношения. Считайте, что все фичи имеют одинаковое значение.
Тогда содержательного разговора не получится.
Потому что один говорит "давайте втащим абстрактный DAL через ORM для того, чтобы можно было легко заменить СУБД с MS SQL на Oracle".
А другой говорит "требования заменяемости СУБД в ТЗ не было, поэтому давайте прекратим страдать фигнёй и сделаем анемик, в котором максимально легко добавлять новые атрибуты к сущностям".
Первый парирует "требования добавляемости новых атрибутов к сущностям в ТЗ тоже не было, поэтому давайте прекратим страдать фигнёй" и т.п.
Дело не в том, что одно из решений красивее другого. Дело в том, что они покрывают различные требования. Без придания ценности отдельным фичам вы не сможете рассудить такой спор.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, landerhigh, Вы писали:
L>>Можешь считать, что этой проблемы не существует. Вся команда стоит у доски, чешет репу и хором говорит, что решение вроде хорошее, но что-то не так. S>Согласитесь, в этом случае проблема на 1000% состоит не в отсутствии формальной метрики Я бы поставил на то, что модель на доске не покрывает всех сценариев или недостаточно проста в реализации. Если угадал — никакая формальная метрика тут не поможет: проблема — не в функции оценки, а в анализе входных данных. Соответственно, копать надо в эту сторону.
Нет, считаем, что модель на доске покрывает все сценарии. Грабли начинаются несколько позже.
L>>Я и сам могу уже трехтомник о скраме написать. А воз и ныне там. S>Так никто и не говорил что скрам идеален. По ссылке — весьма неплохая методика оценки входных требований, которая работает даже если вы не используете скрам в целом. Ну, или не работает, это как повезёт
В принципе, при правильном подходе скрам позволяет избежать многих проблем. Косяки в архитектуре высшего уровня особенно больно ударяют там, где проект приходится резать на части и реализовывать разными командами. При правильном применении скрама и регулярных scrum of scrum архитектуру можно уточнять итеративно, на основе обратной связи от команд. Это требует определенных затрат на организацию и поддержание процесса.
S>>>А не проще будет разобраться, почему вообще интуиция "выстреливает" только на этапе написания кода? L>>Это просто пример. Она выстреливает всегда, просто на этапе кодирования косяки банально выясняются на примере. Когда говорим о более абстрактных вещах, без применения каких-либо формальных метрик обосновывать бывает нечем.
S>С абстрактными вещами проще бороться с помощью анализа требований — стараться не допускать, чтобы на дизайн влияли сиюминутные требования, которые могут легко поменяться в будущем.
Считаем, что требования не меняются. Речь идет о граблях, когда изначально модули неправильно спланировали, заложили слишком много или мало отвественности и так далее.
S>>>Каждый из пунктов тянет на полноценную докторскую, в особенности третий — это NP-полная задача сопоставимая по сложности с "пчёлы vs задача коммивояжёра". L>>А вот это уже интересно. L>>На самом деле некие признаки формальной модели вырисовываются. Но судя по имеющимся материалам, это и правда на несколько докторских тянет. S>Ну да, по трудоёмкости это будет тот же код. Только без собственно кода.
Не обязательно полностью формализовывать модель. Но во многих случаях иметь возможность базовой формальной проверки выбранной модели до перехода к собственно разработки помогло бы очень сильно.
Здравствуйте, gandjustas, Вы писали:
L>>Бизнес велью к вопросу не имеет никакого отношения. G>Имеет, всегда, даже если вы этого не хотите или не знаете.
Не имеет. Нужно реализовать вообще все фичи. Вопрос в том, как избежать ошибок на этапе планирования крупноблочной архитектуры.
L>>Считайте, что все фичи имеют одинаковое значение. G>Так не бывает. Всегда можно упорядочить фичи по важности.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, landerhigh, Вы писали:
L>>Бизнес велью к вопросу не имеет никакого отношения. Считайте, что все фичи имеют одинаковое значение. S>Тогда содержательного разговора не получится.
Еще раз — все фичи имеют одинаковое значение
S>Потому что один говорит "давайте втащим абстрактный DAL через ORM для того, чтобы можно было легко заменить СУБД с MS SQL на Oracle". S>А другой говорит "требования заменяемости СУБД в ТЗ не было, поэтому давайте прекратим страдать фигнёй и сделаем анемик, в котором максимально легко добавлять новые атрибуты к сущностям". S>Первый парирует "требования добавляемости новых атрибутов к сущностям в ТЗ тоже не было, поэтому давайте прекратим страдать фигнёй" и т.п.
S>Дело не в том, что одно из решений красивее другого. Дело в том, что они покрывают различные требования. Без придания ценности отдельным фичам вы не сможете рассудить такой спор.
Все это, конечно, хорошо, но к вопросу не имеет ни малейшего отношения. Задача не в том, как разруливать спор "а давайте сделаем то, а давайте это". Набор фич уже есть, согласован и подлежит реализации. Вопрос состоит в том, как на этапе планирования крупноблочной архитектуры выявлять переусложненные модули, модули со слишком большой областью ответствености, повторение функциональности и так далее.
1. АлексКаб нарисовал что-то вроде пирамидки Сагатовского — метод анализа проблем в системном анализе.
2. Можно обмерить увсе, начиная от диграмм use-case до конечного кода (даже код виртуальной машины — этим как раз профайлеры занимаются)
Метрики можно придумать самые разные — не суть. Суть — имеем вектор координат в некотором многомерном пространстве.
3. Далее возникает вопрос, что с этим вектором делать. Вернее — их много векторов — по разным проектам надо такие вектора собрать.
4. Далее можно юзать Теорию принятия решений — при многих критериях.
Или привлечь экспертов для сравнительных оценок по какому-нить методу экспертных оценок.
Например, метод анализа иерархий.
При множестве экспертов потребуется провести процедуру согласования экспертной информации.
5. На основании экспертной информации можно построить функции принадлежности нечетких множеств — понеслись нечеткие оценки. Лингвистические, конечно.
6. Вектор можно подать на вход нейронной сети. Только опять же нечеткой нейронной сети, например, Ванга-Менделя.
На выходе такой сети — значение лингвистической переменной. Что-то вроде " высокая сложность".
В общем, что делать с вектором метрик — это как раз исследовательский проект.
Но можно получить РЕЗУЛЬТАТ...
Если не жаль времени и интересно...
Таким образом, начинать надо с определения набора полезных метрик — это само по-себе — исследование.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, landerhigh, Вы писали:
L>Накидайте ссылок, пожалуйста.
Сложность и стабильность программного обеспечения относиться к слабо формализуемым понятиям, особенно с учетом возможного изменения требований.
Построения достаточно полной мат. модели и вычисления по ней числового параметра, который характеризует качество того или иного решения — очень сложно.
Могу предложить подойти к проблеме немного с другой стороны.
Есть такая область знаний, которая называется "Теория принятия решений". Принятие решения — это процесс выбора альтернатив, имеющий целью достижение осознаваемого результата.
Для ознакомления можно посмотреть, книгу
Блюмин С.Л., Шуйкова И.А.
Модели и методы принятия решений в условиях неопределенности. — Липецк: ЛЭГИ, 2001. — 138 с.
Математика там несложная, имеются примеры.
Попробую привести простой пример использования данного подхода.
Пусть у нас есть группа архитекторов ПО, готовая к тысячам часов архитектурных войн. Пусть они предложили набор альтернативных архитектур.
Теперь каждый эксперт независимо составляет матрицу предпочтений для альтернатив. Т.е. ставит каждой паре альтернатив число от 0 до 1, которая "меряет" его уверенность в том, что 1-ю архитектуру нужно предпочесть 2-ой.
Все, архитектурные войны отменяются, в действие вступает алгоритм, который по набору матриц и правилам нечеткой логики выдает степень предпочтения (число от 0 до 1) для каждой альтернативы.
Осталось только выбрать то решение, которому соответствует максимальное число.
Есть также процедуры выявления факта несогласованности экспертов.
Также рассматриваются варианты, когда эксперты имеют веса, либо между ними задано отношение нечеткого предпочтения.
Безусловно, что такой подход основан на том, что эксперты — это действительно эксперты в своей области.
AC>Я не встречал интересных ссылок по теме и даже особо не интересовался методами анализа решений, но разбирал сам процесс построения решений, думаю, ниже написанное вам пригодится.
В дополнение к этому я хочу посоветовать прочитать книгу: Буч Г. Объектно-ориентированный анализ и проектирование.
Здравствуйте, landerhigh, Вы писали:
L>Все это, конечно, хорошо, но к вопросу не имеет ни малейшего отношения. Задача не в том, как разруливать спор "а давайте сделаем то, а давайте это". Набор фич уже есть, согласован и подлежит реализации. Вопрос состоит в том, как на этапе планирования крупноблочной архитектуры выявлять переусложненные модули, модули со слишком большой областью ответствености, повторение функциональности и так далее.
На этапе планирования крупноблочной архитектуры всё, что вы можете увидеть — это крупные блоки.
Я, если честно, не понимаю, как вы выявите переусложнённость модуля до того, как этот модуль будет описан.
Если я рисую квадратик на доске и говорю: "это — модуль кэширования", и оппонент рисует квадратик и говорит "это — модуль кэширования", то совершенно непонятно, у кого из нас решение переусложнено.
Если у оппонента нет "модуля кэширования", то моё решение переусложнено. При условии, что оно реализует те же фичи.
Если вы получили два одинаковых набора квадратиков, то крупноблочная архитектура выбрана. Начинайте проектировать модули — точно так же, в виде квадратиков. Считаете квадратики — получаете меру сложности.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, landerhigh, Вы писали:
L>Элементарно. То, что очевидно одному, совсем не очевидно другому. Прийти к общему знаменателю бывает чрезвычайно трудно.
Я думаю это не имеет никакого отношения к ИТ. На примере, два кандидат имеют подготовку : структуры данных 1000 И 5000 часов, аргоритмы 1000 и 5000 часов, работали на одной и том же проекте но разное время, но первый имеет опыт асинхронного, многопоточного, UI + попробовал доп язык джаваскрипт, а второй вместо этого занимался архитектурой приложения и управлением командой. У первого опыт 3 года, у второго — 12 лет.
Вопрос — кто из них быстрее поймет функциональное программирование, хаскель тот же, и почему ?
Второй вопрос — кто из них быстрее и качественее напишет какой нибудь актуальный и сложный алгоритм "с нуля" ?
Ни одна методика оценки сложности не даст ответ. Скорее всего хаскель освоит тот, у кого опыт более разнообразный "в ширину". У кого из двух будет ширше — трудно сказать, нужны детали которых в общем случае никогда нет и быть не может.
На мой взгляд есть только один подход к общему знаменателю — искать причины непонимания в недостаточной прокачке той или иной области или отсутствии некоторых понятий. Большинство специалистов в ИТ рассуждает приблизительно так(общий знаменатель прочитаного мною на этом форуме):
"Ну почитаешь денек, разберешься и напишешь"
"Я не программист, но понял хаскель за неделю"
"А что тут сложного ? Если кто не понимает монады, то это не ко мне"
Очевидно, для того что бы почитать денек и разобраться нужен уже определенный опыт и знания, при чем степень прокачки достаточная для того, что бы делать рассуждения в уме со скоростью много большей скорости чтения материяла. С хаскелем нужно иметь хорошую математику и достаточно широкий спектр технических приемов.
Выходит так — Нет понятий — нет и рассуждений, а вот скорость рассуждений определяется количеством опыта применения не только конкретного понятия но и взаимосвязаных понятий. Кроме того, еще и глубина памяти, объем воображения и многие другие вещи так же зависят от количества опыта и тд.
То есть решение вырисовывается такое — для каждого баззворда нужно найти некоторый минимальный базис, который необходим что бы освоить баззворд "за две минуты". Тогда станет ясно, почему один понимает, а другой — нет.
P.S. Избитый пример про понятия: "Разные люди работают с полиуретановыми волокнами по разному — продавец трикотажа, покупатель трикотажа, инженер-химик, инженер-технолог, дизайнер одежды и рабочий в цехе по изготовлению одежды. Вопрос — понимают ли эти люди одно и то же когда слышат слово "лайкра" или "спандекс" ?
Здравствуйте, landerhigh, Вы писали:
L>Почему мне это вообще интересно? Есть такая штука, как интуиция. Бывает, начинаешь делать некий сферический в вакууме модуль Х. Нарисовал квадратики, приступил к работе и интуитивно понимаешь, что решение, которое получается, некрасиво, хотя и показать этого не можешь. Интуиция все же на чем-то основывается, поэтому, КМК, должна существовать возможность перехода к некой абстрактной модели, в которой некрасивости можно будет банально подсчитать по формуле. Например, слишком большое число состояний модуля, слишком большое количество входов/выходов, наличие непересечающихся областей ответственности и так далее.
Интуиция это твой переварены опыт. Если ты никогда не делал параметризацию алгоримов или классов, то решение на лямбдах скорее всего покажется крайне некрасивым. А если связыванием , зависимостями и обязанностями никогда не интересовался, то di/ioc покажется глупой затеей которая вводит в заблуждение.
Спасибо за сообщение. В принципе, все это мне известно, но было полезно взглянуть на вопрос в комплексе.
Как раз на прошлой неделе смотрел видео с презентации Гапертона на Software People. Его доклад во многом пересекается с тем что вы написали. В частности о том, что "проектирование это процесс формулирования и проверки гипотез". В этом плане (цитата): "Прототипы, Дизайн-ревью, Код-ревью, Тесты -- вляются не«практиками», а
средствами проверки«гипотез»".
Очень советую посмотреть этот доклад: http://www.youtube.com/watch?v=yzIRO85SO6g Слайды: http://www.slideshare.net/gladerru/gaperton-software-people-2012
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, landerhigh, Вы писали: L>>Кроме того, индикатор переусложненности архитектуры также мог бы основываться на каких-либо нормализованных входных данных. __>я предлагаю качеством архитектуры называть число, которое можно определить по статистике изменений кода. Посчитайте сколько в среднем мест в коде нужно поменять, если вы хотите поменять только одну вещь. Вот эта чиселка и может сказать о качестве архитетуры и даже позволит сравнивать приложения по качеству кода между собой.
Во, прямо совпадающее со мной мнение, тока нужно немного подкорректировать. Берем исходную версию программы и 10 фичь(вещь которую можно поменять). Последовательно меняем одну и подсчитываем в сколько мест нужно полезть и поменять. У нас получается всего 10 чисел которые и скажут нам о том насколько исходная версия программы (и только она) приспособлена к внесению изменений для каждой из фичь. Вроде как бы при другой архитектуре должна получиться другая последовательность чисел. То есть другая архитектура более благосклонна к внесению одник фичь и затрудняет внесение других фичь. Очевидно нам нужно из последовательности в 10 чисел получить только одно — символизирующее архитектуру. Значит нам нужно еще и умножать каждое число на степень полезности и востребованности фичи а потом можно и сложить эти числа чтобы получить одно число для каждой архитектуры.
Проблема состоит в том, внесении фичи2 после фичи1 может быть на порядок труднее выполнить чем просто добавление фичи2 без фичи1. То есть сложность внесения изменений кореллируют между собой. Потому исследования сложности для одной единственной версии программы не совсем правильное мероприятие. Нужно измерять не просто внесение фичи2 в исходную версию, но и в версию с уже встроеннной фичей1, а также версией с встроенной фичей 3 и т.д., а также естественно комбиначей. например, с версией где есть фичи 1 3 5, но нет фичь 4, 6 и 8. Потому у нас для 10 фичь получиться вообще говоря не 10 измеренных значений а 2**10 = 1024. Каждое из которых нужно еще умножить на коеффициент полезности фичь.
Я еще не говорил что одна и та же фича в разных версиях программ полезна по разному? Значит полезность фичь нужно задавать относительно версии программы. Хотя конечно есть фичи которые никак не зависят от версии, но такое бывает редко.
Выводы: метрики вообще не то меряют что нужно. Условно говоря метрики измеряют описание программы в некоторый момент времени, а нужно измерять трудоемкость перехода от одного описания к другому. Вся сложность заключена в основном в изменении программы, а не в ее описании в каждый момент времени.
T>Интуиция это твой переварены опыт. Если ты никогда не делал параметризацию алгоримов или классов, то решение на лямбдах скорее всего покажется крайне некрасивым. А если связыванием , зависимостями и обязанностями никогда не интересовался, то di/ioc покажется глупой затеей которая вводит в заблуждение.
Это очень приземленный пример. У меня интуиция прокачана до уровня, что уже на этапе планирования безошибочно определяю вполне рабочие предложения, но с которыми мы огребем серьезных проблем. Проблема в том, что аргументировать это могу далеко не всегда. О чем и сыр-бор, хочется иметь возможность использовать формализованный подход при необходимости.
Здравствуйте, landerhigh, Вы писали:
T>>Интуиция это твой переварены опыт. Если ты никогда не делал параметризацию алгоримов или классов, то решение на лямбдах скорее всего покажется крайне некрасивым. А если связыванием , зависимостями и обязанностями никогда не интересовался, то di/ioc покажется глупой затеей которая вводит в заблуждение.
L>Это очень приземленный пример. У меня интуиция прокачана до уровня, что уже на этапе планирования безошибочно определяю вполне рабочие предложения, но с которыми мы огребем серьезных проблем. Проблема в том, что аргументировать это могу далеко не всегда. О чем и сыр-бор, хочется иметь возможность использовать формализованный подход при необходимости.
Конечно приземленный, я ведь не знаю, чем ты занимаешься по работе Интуитивное понимаение это в некотором приближении характеризует уровень прокачки понятий и саму систему понятий. То есть, не можешь сказать, значит тебе не хватает какого то кусочка опыта или понятия. Формализованый подход здесь уже подсказали со ссылками на Гапертона. В любом случае это просто опробованые эвристики.
Здравствуйте, landerhigh, Вы писали:
L>У меня интуиция прокачана до уровня, что уже на этапе планирования безошибочно определяю вполне рабочие предложения, но с которыми мы огребем серьезных проблем. Проблема в том, что аргументировать это могу далеко не всегда. О чем и сыр-бор, хочется иметь возможность использовать формализованный подход при необходимости.
Не останавливайся на "чувствую, что проблема, но объяснить не могу". Сделай следующий шаг. Попробуй выяснить причину и попробуй ее объяснить.
Некоторое время назад я стал просить коллег заставлять меня объяснять почему мне не нравится какое-либо решение. Времени, конечно, тратиться на это много так как ты себе не всегда можешь объяснить почему тебе что-то нравится или нет. Но польза несомненна. Ты начинаешь лучше понимать проблему, коллеги узнают что-то новое. И, главное, они могу аргументированно возразить тебе. Последнее особенно ценно. Избавиться от "суеверий" всегда полезно.
Поначалу это сложно, но чем больше ты пробуешь докопаться до причины, тем проще. Вообще, причин не так уж и много (скажем типов причин), поэтому следующие объяснения могут опираться на предыдущие.
Проверено на людях (на мне и моей команде)
СУВ, Aikin
И, опять же, ссылка на доклад Гапертона.
Правила проверки решений
• «Это неправильно» «Как ваше решение будет работать вот в такой ситуации?»
• Давление на авторитеты Ссылки на конкретный опыт с примерами
• Убеждения В инженерии все можно обосновать логически
• Это будет так! «В закон Ома верю. Все остальное надо проверять»
Здравствуйте, Aikin, Вы писали:
L>>У меня интуиция прокачана до уровня, что уже на этапе планирования безошибочно определяю вполне рабочие предложения, но с которыми мы огребем серьезных проблем. Проблема в том, что аргументировать это могу далеко не всегда. О чем и сыр-бор, хочется иметь возможность использовать формализованный подход при необходимости. A>Не останавливайся на "чувствую, что проблема, но объяснить не могу". Сделай следующий шаг. Попробуй выяснить причину и попробуй ее объяснить.
Здравствуйте, landerhigh, Вы писали:
L>Это очень приземленный пример. У меня интуиция прокачана до уровня, что уже на этапе планирования безошибочно определяю вполне рабочие предложения, но с которыми мы огребем серьезных проблем. Проблема в том, что аргументировать это могу далеко не всегда. О чем и сыр-бор, хочется иметь возможность использовать формализованный подход при необходимости.
"Понимаю но не могу объяснить" это близкий родственник "не понимаю". Потому что легко в таком положении поддаться ошибочным позывам.
Попробуй точно сформулировать какие проблемы могут быть в тех или иных решениях. Потом опиши почему они возникнут. На этом этапе можно притянуть формальные метрики, но обычно уже нет необходимости.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, landerhigh, Вы писали:
L>>Это очень приземленный пример. У меня интуиция прокачана до уровня, что уже на этапе планирования безошибочно определяю вполне рабочие предложения, но с которыми мы огребем серьезных проблем. Проблема в том, что аргументировать это могу далеко не всегда. О чем и сыр-бор, хочется иметь возможность использовать формализованный подход при необходимости.
G>"Понимаю но не могу объяснить" это близкий родственник "не понимаю". Потому что легко в таком положении поддаться ошибочным позывам.
Видимо, неправильно выразился. В данном случае "не могу" — это скорее "не хочу", ибо многие вещи считаю очевидными. Когда команда устоялась, это не является проблемой — люди сработались, понимают друг друга с полуслова и знают сильные или слабые стороны друг друга и не принимают критику как личное оскорбление, но при этом не позволяют авторитету превалировать над логикой.
В новых командах или в межкомандном взаимодействии все совсем иначе.
G>Попробуй точно сформулировать какие проблемы могут быть в тех или иных решениях. Потом опиши почему они возникнут. На этом этапе можно притянуть формальные метрики, но обычно уже нет необходимости.
Дело в том, что подобный подход понятен не всем. Некоторые его вообще никогда не осилят. Но при этом могут переспорить (и перетроллить) половину этого форума.
Формальный подход как раз нужен для борьбы с ними.
Я бы поставил на то, что модель на доске не покрывает всех сценариев или недостаточно проста в реализации. Если угадал — никакая формальная метрика тут не поможет: проблема — не в функции оценки, а в анализе входных данных. Соответственно, копать надо в эту сторону.
