Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Silver_s, Вы писали:
S_>>1) Если при выборе одного из двух решений... Тогда тут 10 раз надо сначала подумать.
G>Если оба варианта равновероятны, то надо выбирать тот, который потребует меньше писанины.
G>Если нет, то тот, который наиболее вероятен.
G>Не надо предсказывать. Надо руководствоваться правилос выше.
В правиле выше сказано про вероятности. А определение вероятностей это и есть попытка сделать предсказание. Не по звездам делаются адекватные оценки вероятностей. И не по пакетам программ мат-статистики, когда о таких вещах речь идет. К тому же определить вариант где меньше писанины это тоже гадание. Да и какая писанина интересует, в краткосрочном плане или в долгосрочном?
G>Почти любая попытка "продумать наперед" обычно не приносит полезных результатов.
А вот с этим, как ни странно согласен. Главное чтобы это не вело к ложным выводам и действиям, большим потерям времени.
Но когда проходятся точки невозврата, после которой остановить паровоз и отправить обратно становится тяжело. Тогда стоит гораздо больше времени потратить на попытки предсказать к чему может привести вариант. И кроме того на поиск еще и других вариантов можно потратиться, которые на первый взгляд не видны.
Но под "продумать наперед" я не имею ввиду проектирование сверху-вниз, а потом продавливание этих первоначальных решений до потери пульса, игнорируя все факты несостоятельности таких первоначальных решений. Это как раз, надекватная оценка способностей продумать ситуацию наперед, не удалось продумать а все равно упрямится...
Думаю не станешь отрицать что существуют конторы где программисты говорят "Ой как все криво,косо сделано" Но переделать невозможно. Такие системы и конторы держатся на плаву если слабая связь между отдельными программистами(один не может проушить работу другого, и не должен знать что делает сосед). И слабая связь с предыдущими годами работы(добавления не смогут порушить старое). Переделывать в этом случае невыгодно, когда больше 200 человеко-лет вложено, переделка может обойтись дорого.
Т.е. там может быть важна(из-за чего контора на плаву держится) не столько архитектура, а поддержка пользователей,предметная область,сама бизнес логика. А в архитектурном плане много лет много человек делают абсолютно одно и тоже, клонируют кусок кода втыкают бизнес логику, и добавляют в общий массив. И плюс часть времени на борьбу с багами, обход граблей, возникающих из-за кривизны.
А бывают системы где все заходит вобще в полный тупик из-за какой-то мелочи или кривизны архитектуры. И откаты назад с глубокими переделками неизбежны, поскольку нужно не наращивание за счет количества, а качественное развитие. Там скорее принципы XP более актуальны.
S_>>А если писал фичу две недели, и есть подозрения на 50% что потом к ней потребуется добавка которую 1 час писать, а если отложить на 2 недели, то потребуется 8 часов чтобы ту же добавку написать (переключение контекста).
S_>>Если подсчитать матожидание затрат (как бы не смешно звучало) : в первом случае 1 час, во втором 0.5*8
G>Неверно. Это только сдвинет переключение контекста, а не уберет его.
G>Кроме того переключение контекста — очень субъективная вещь.
G>Не надо копать, надо делать то что нужно сейчас и уменьшать связность.
Да, копать сомо по себе не надо,как самоцель, надо прокачивать интуицию для таких случаев где формальный анализ бессилен.
А интуиция по оценке неких свойств системы или некой области, насколько знаю, прокачивается только путем наблюдения и экпериментального изучения (действие-наблюдение реакции,результата).
За какими факторами,свойствами, атрибутами, наблюдаешь. По ним и будешь иметь представление. За чем не наблюдаешь, того нет.
А то что нужно сейчас, конечно тоже надо делать. После этого уже возможно появятся идеи как это можно сделать лучше по-другому. Из ничего идеи трудно создать. Да и вобще мне больше нравится философия XP где все "здесь и сейчас" но не доводя до абсурда.
-----
Если на дырки в земле не обращать внимания,то суслики не существуют.И непонятно кто капусту жрет в огороде — самоликвидируется наверно.
Но в принципе, если огород в порядке нет смысла каждую неровность в земле изучать.
Это замечание уже скорее по поводу вопросов из обсуждаемой статьи.
К примеру ту же WPF могли сделать только одним способом? Или много вариантов из которых тяжело выбирать — один по своему хорош другой по своему и каждый в чем-то проигрывает. По условию бы делала команда одного проф. уровня и специализации. А не сравнивать с тем что бы сделала конвеерная бригада по производству учетных систем.Для которых слово заказчика-закон и менеджер проектов никогда не ошибается.
Или такой частный случай. Hеализация и работа property в WPF сложнее чем в WinForms? Если сложнее то зачем так сделали? Везде ли подойдет такая реализация пропертей или могут обозвать извращенцем того кто такое же сделал в другой задаче? Ясно что такие пропертя определенные неудобства тоже причиняют (кроме положительных моментов).Кроме того их еще изучить надо чтобы понять. Когда существует простой и очевидный способ из объектов просто собирать через Reflection.
Если кому то в статье бросается в глаза только то что она формально не строгая. Значит с аналогичными проблемами на практике не сталкивались, и эти вопросы просто не актуальны.
На просьбу сделать попытку изложить то же, но более формально. Скорее всего будет ответ — невозможно формализовать то чего нет.
Сложность определяется энтропией, а поскольку к данным вопросам формулы энтропии не подходят. А другие логичные формулы и строгое описание не придумываются, значит это субьективизм,ересь, и пустопорожние разговоры оторванные от жизни.
З.Ы. Надоело срочить по клаве, перехожу в читатели.
А если кратко то к каждой строчке на которые отвечал написал бы "Согласен, с оговоркой что не всегда так бывает". Кроме ... неявного утверждения что не надо гадать а просто выбирать наибольшую вероятность
Надеюсь ветка продолжится. И не в виде борьбы за чистоту терминов.
