Модели, объекты, поведение, интерфейсы

[Вад]

Dimka, а что ты вкладываешь в слово "сильные"? Насколько я понимаю, разница только в том, что "на пути камикадзе" решения строятся из подручных материалов - но очень быстро. Не факт, что такие решения в итоге получаются дешевле или надёжнее. И уж точно, они как инженерные системы, могут тащить много "лишних деталей", потому что упростить систему - это в условиях цейтнота надо ещё суметь.

[Джон]

ИМХО кто-то из вас (или вы оба?) вдаётся в крайности. Чушь полнейшая, что станция слежения за спутниками исключительно ЦЕЛИКОМ И ПОЛНОСТЬЮ была построена из материалов со свалки. То что некоторые БУшные части нашли применение при её строительстве - вполне возможно. Почему бы и нет? Если деталь удовлетворяет требованиям, то какая разница? Если у меня нет специального молотка для колки орехов, почему камень не является идеальным вариантом? Тем более в контексте точно не указывается какие именно ф-ции выполняли эти части. А может они просто послужили каркасом фундамента? Ну дык я помню дом в деревне строили так всякое железо туда кидали. Что в этом "нелучшего"?
Всё зависит от условий и требований. С этой позиции и надо рассматривать. Как же можно что-то утверждать однозначно по этому вопросу?
Да даже просто с лингвистической стороны подойти. Чем принципиально отличаются выражения "использовать, что под рукой" и "использовать, что в распоряжении". Королёв кстати мог пользоваться только тем, что было в его распоряжении или под рукой. Хотелось большего, да не было.

[zubr]

Джон, никто не спорит, что если для конкретной задачи можно использовать что то готовое - то это хорошее решение, но в том случае, если это не связывает разработчика. Да и не совсем согласен с примером создания антенны по отношению к созданию эффективных интерфейсов. Ведь конструкторы подводной лодки и конструкторы поворотного узла корабельного орудия вряд ли в своей разработке предусматривали возможность использования своего изделия для каких то других целей.

[Джон]

Совершенно очевидно, что разработчики итальянской подводной лодки в 1931 году не предусматривали возможность использования её полностью или частично в советской станции слежения за спутниками. Но ведь в конечном итоге значение имеет функциональность устройства, а не его изначальное предназначение. И, если функциональность устройства удовлетворяет моим требованиям, вернее эксплуатационным требованиям, то я использую это устройство. Более того, разработчики могут сразу предусмотреть универсальность использования устройства в будущем. Примеров куча - от гаек и винтиков, до транзисторов и операционных усилителей. Конечно, есть специальные гайки и специальные усилители, которые можно использовать только по их прямому назначению (до тех пор пока ), но большинство являются всё-таки универсальными. Пример хорошего интерфейса при полном сохранении функциональности.
Поэтому,  почему бы и не использовать механизм поворота орудия, например, для шлагбаума? Или туалет с подводной лодки?

[Вад]

Joel Spolsky, как по заказу, сегодня разродился постом на данную тему, про duct-tape programmers: http://www.joelonsoftware.com/items/2009/09/23.html

Надо сказать, никакой особой силы в решениях "на клейкой ленте" как таковых, нет. Сила в том, что они создаются очень быстро, чтобы успеть урвать рынок, пока другие сидят и бесконечно проектируют красивые решения. Или в том, что они просто создаются очень быстро. Поэтому они наиболее хороши, если условия именно диктуют "сделай или умри". Разумеется, на переднем краю рынка думать месяцами над архитектурой никто просто не даст. Даже про юнит-тесты там сказано, что у клиента нет в них прямой потребности, а потому они чаще всего не являются критическими, и их можно отбросить, чтобы не жертвовать временем, которое можно потратить на более нужную фичу

[Dimka]

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

Ты одновременно ограничил цель и средства и при этом говоришь, что достижимость цели при таких средствах будет не очень. Согласен.

Моя основная мысль посвящена не этому. А тому, что творческая "интерпретация" имеющихся средств, ресурсов и возможностей может существенно упростить и ускорить достижение цели. "Сильное решение" - это такое решение, которое полностью обеспечивает достижение цели при минимальных затратах.

Но ведь в конечном итоге значение имеет функциональность устройства, а не его изначальное предназначение. И, если функциональность устройства удовлетворяет моим требованиям, вернее эксплуатационным требованиям, то я использую это устройство.

Совершенно верно.

Более того, разработчики могут сразу предусмотреть универсальность использования устройства в будущем.

А вот это требует комментария.

В рассуждениях zubr присутствует подход, способ мышления, при котором "сильное решение" невозможно. Почему? Потому порядок его мысли следующий:
1) Нам нужен автомобиль.
2) Автомобиль должен состоять из: кузова, крыльев, двигателя и т.д.
3) Мы смотрим, какие у нас есть: кузова, крылья, двигатели и т.д.

Это типичное проектирование "сверху вниз", в результате которого мы часто получаем ситуации, когда имеющиеся у нас старые наработки оказываются бесполезными в новых условиях. Единственный выход - произвести все комплектующие заново.

Есть другой способ мышления (например, в ТРИЗ ему обучают) - нужно отказаться от конкретных образов вещей и сосредоточиться на функциях. Вещь - автомобиль, функция - транспортировка и т.д.

Но этот более "универсальный" метод всё равно не позволяет нам создавать "универсальные" вещи. Т.е. если способ мышления, показанный zubr имеет ограничения как по методу, так и по содержанию выражающей эти мысли деятельности, то способ ТРИЗовцев снимает ограничения лишь в методе, но не в содержании. Он позволяет получить "сильное решение" здесь и сейчас, но не годится для разработки перспективных вещей, облегчающих решение новых проблем в будущем.

Чтобы снять ограничение с другой стороны, нужно изменить подход к постановке проблем. Так как правильное понимание проблемы - это уже половина решения. ТРИЗовцы это пытаются делать через выход в надсистему. Но по-моему в этом мало пользы, так как мы заранее не знаем, в каком контексте будем решать будущие проблемы, и поэтому "универсальность заранее" будет получаться плохо.

Пока на этом остановлюсь

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

Это приземлённое понимание "пути камикадзе". Я же в основном имел в виду, что условия "сделай или умри" стимулируют мыслительную деятельность и подталкивают к новым способам мышления. Потому что:

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

Это - предложение умереть, сделанное в условиях, когда на самом деле смерть не грозит

[Джон]

Более того, разработчики могут сразу предусмотреть универсальность использования устройства в будущем.

А вот это требует комментария.

Собственно говоря, что я хотел сказать. Немного в другой формулировке, которая ближе и понятней нам. Задача разработчика по возможности не накладывать дополнительные ограничения на функциональность устройства. Простой пример, когда-то давно я занимался пулевой стрельбой. На "вооружении" у нас были также винтовки CM-2, у которых ложе рукоятки имело вырез только для правшей (для левшей тоже есть модификация, но у нас их не было - "не завезли" (с) ). Левшам стрелять из неё было невозможно и им приходилось "испражняться" на ТОЗ-12, у которых этот "недостаток" отсутствовал. Ессно, что на соревнованиях на огневом рубеже лежали... ТОЗ-12 как наиболее универсальные. Спрашивается, какая была необходимость делать ложе под конкретную руку? Руководствуясь благими намерениями и статистикой разработчики ввели дополнительные требования к области применения - человек должен быть правшой. Таким образом левша мог использовать её, например, как костыль при повреждениях правой ноги, но не как отличную винтовку.

[zubr]

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

Это - предложение умереть, сделанное в условиях, когда на самом деле смерть не грозит

На самом деле это сегодняшняя реальность постсоветской промышленности.

[Dimka]

zubr, т.е. где-то "там" живут такие люди, которые легко и с радостью бухнут невообразимое количество денег на разработку "с нуля"? И лишь в постсоветской промышленности денег не дают?

[zubr]

zubr, т.е. где-то "там" живут такие люди, которые легко и с радостью бухнут невообразимое количество денег на разработку "с нуля"? И лишь в постсоветской промышленности денег не дают?

Где-то "там" стараются использовать готовые качественные решения (модули, технологии, материалы), а не привязываются к металлолому.
Простой пример, для производства какой то продукции необходим какой то станок. Есть 2 варианта решения:
1. Из 3-х поломанных устаревших станков собрать 1.
2. Купить новый современный станок.
Выбрав 1-й вариант вклад финансовых ресурсов минимальный. Но через неделю работы начинает течь гидравлика, так как стоит резина made in USSR, через месяц начнется люфт в подшипниковых узлах, так как подшипники made in USSR. Чтобы получить более-менее приличное качество на данном станке, необходимо ставить за него рабочего высокой квалификации с соответствующей оплатой труда. И все равно станок дает брак 20%. Плюс необходимо время на сборку и ремонт станка из 3-х.
По 2-му варианту за новый станок надо заплатить круглую сумму денег, которая окупится только через 2 года. Но зато  станок практически сразу готов к работе (после нескольких часов монтажа и пуско-наладочных работ), почти не ломается, гораздо дешевле в эксплуатации станка по 1-му варианту, брак почти отсутствует, не требует высокой квалификации рабочего.
Какой вариант выберет постсоветский бизнес-менеджер?

Что касается конструкторских решений, они зачастую получаются кривые, так как конструктор вынужден закладывать далеко не самые лучшие материалы и комплектующие, учитывать технологические возможности устаревших производств - в результате получается то что получается. Замкнутый круг.

[Dimka]

zubr, возвращаясь в горние выси...

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

Ну что ж, не спорю, что комфортная среда (здесь и сейчас) способствует экстенсивному развитию. Но никак не согласен с тем, что без комфортной среды развитие невозможно. Есть ещё и интенсивное развитие. И чтобы его включить, как нужна неблагоприятная среда, стимулирующая изменения и новые подходы. Или, как ты сам сказал, "голь на выдумки хитра".

[zubr]

Стоп. По моему понятия экстенсивного и интенсивного развития перепутаны.
1-й вариант: Конструктор, проектирует автомобиль в некомфортных условиях - на кульмане. Чтобы получить обтекаюмую форму с современным дизайном он вынужден использовать различные лекала, интуицию, делать модельки из дерева и т. п. Затем по чертежам конструктора лекальщики высокого разряда выпиливают штампы для кузовных деталей, а технологи пишут техпроцесс.
2-й вариант: Конструктор, проектирует автомобиль в комфортных условиях, используя достаточно мощный компьютер, мощный конструкторско-технологический программный пакет, позволяющий вести разработку в 3D с возможностями моделирования, симуляции работы механизмов, симуляции нагрузок. На выходе он получает чертежи, технологическую документацию, программы ЧПУ для электроэрозионных станков выжигающих штампы и заменяющих целую бригаду лекальщиков.
В первом варианте задействовано людей как минимум на порядок больше чем во втором. Качество же обратно-пропорционально.
Вопрос, какой из вариантов представляет экстенсивное развитие, а какой интенсивное?

[Dimka]

В этих примерах вообще нет развития. Это статические ситуации. Развитие - это перемена. И переход от 1-го ко 2-му - это интенсивное развитие. А развитие 1-го варианта в сторону увеличения числа народу без смены технологии - это экстенсивное.

Экс - это наружу (за счёт внешней среды), инт - это внутрь (за счёт реорганизации и оптимизации использования имеющихся ресурсов).

В данном случае ресурс - конструктор. А смена технологии - это элемент реорганизации.

Опять же, всё зависит от точки зрения на то, что является ресурсом. Как правило для интенсивного развития выбирают самый дорогой, ценный и редкий ресурс, а для экстенсивного - дешёвый и массовый.

Кульман и модельки из дерева явно дешевле конструктора и модельщика - людей. Зато в армии некогда военная техника была дороже людей - со всеми вытекающими решениями в боевых условиях.

[Sla]

Слышьте, философы!
Почитайте Жюль Верна. Вот там "путь камикадзе". А здесь - инженерная мысль.

[zubr]

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

[x77]

Вад, нет, это возможный способ построения моделей.

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

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

на практике всё упирается в знаменитую теорему о неполноте систем: нельзя описать систему в терминах самой системы - для этого всегда потребуется надсистема, включающая в себя описываемую систему. поэтому чем более полную (универсальную) модель мы хотим получить, тем на больший уровень абстракции вынуждены забираться.

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

очевидно, что при проектировании систем необходимо придерживаться очень жёсткой минимизации. т.е. если мы хотим объединить две разные модели, необходимо включать в "физику" общего мира законы и свойства, задействованные в обеих моделях.

иными словами, я бы попробовал не объединять модели, а построить модель предметной области ("надсистему"), в которой обе эти модели будут существовать, и которая будет описывать законы взаимодействия этих моделей.

[Dimka]

иными словами, я бы попробовал не объединять модели, а построить модель предметной области ("надсистему"), в которой обе эти модели будут существовать, и которая будет описывать законы взаимодействия этих моделей.

Правильно. Такой подход со времён Спинозы и Гегеля называют диалектикой.

Слышьте, философы!

Слышим-слышим

[Джон]

Ребят, выпейте водки, и всё станет на свои места. Чесслово.