Информация об изменениях

Сообщение Re[88]: Мнение: объектно-ориентированное программирование — от 11.11.2019 16:16

Изменено 11.11.2019 16:41 Pauel

Re[88]: Мнение: объектно-ориентированное программирование —
Здравствуйте, samius, Вы писали:

I>>Очевидно, что одним только определением всех проблем не решить. Факт в том, что для тебя в новинку связь качества и надежности.


S>Я не пытаюсь решать проблемы. Я пытаюсь понять, что ты мне пытаешься донести, ссылаясь на определение и делая выводы, противоречащие определению?


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

I>>Из твоего примера следует, что ты купил нечто существующее в единственном экземпляре. Далее ты покупаешь это же. Где тут две одинаковые покупки?


S>Ну ладно, про финансовые инструменты ты не слышал. Пусть я купил хлебушка.


Ок. Теперь покажи т.н. анализ ожиданий, логическую цепочку.

I>>При правильном подходе результат вполне определен — цель или достигается, или есть нечто неучтенное в условии. Другого быть не может. И цель это никак не отменяет.

S>Согласно твоим словам, цель либо гарантирована процессом, если процесс привел к успеху, либо недостижима, если не привел. Вот тебе процесс (если с газпромом так сложно): я покупаю хлебушка что бы набить брюхо. Почему сегодня результат может быть гарантированным, а завтра — недостижимым? Что я должен учесть?

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

I>>Ты путаешь постановку цели и конкретный результат.

S>Ну так объясни мне! Поесть хлебушка — гарантирует набить брюхо, или делает цель недостижимой принципиально?

См выше.

I>>Достаточно одного единственного, о котором стало известно в момент тестирования и который не отражен в скриптах. Тебе похоже даже в голову не приходит, как такое возможно

S>А тебе не приходит в голову, что это фактор можно отразить в скриптах.

Ок, покажи пример, как заскриптовать нечто неизвестное на момент написания скрипта, включая все сорта расширений — база знаний и тд и тд и тд. Скажем, сегодня ты пишешь скрипт, а завтра мы узнаем скажем, неожиданные требования и не сразу, а во время работы этого самого скрипта.
Можешь даже текстом — сегодня или завтра, на крайняк до конца сего месяца, напиши сюда нечто, о чем ты ни разу не слышал, не видел, не подозревал с начала жизни и будешь ни видеть, ни слышать, ни подозревать вплоть до начала 2020
Re[88]: Мнение: объектно-ориентированное программирование —
Здравствуйте, samius, Вы писали:

I>>Очевидно, что одним только определением всех проблем не решить. Факт в том, что для тебя в новинку связь качества и надежности.


S>Я не пытаюсь решать проблемы. Я пытаюсь понять, что ты мне пытаешься донести, ссылаясь на определение и делая выводы, противоречащие определению?


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

I>>Из твоего примера следует, что ты купил нечто существующее в единственном экземпляре. Далее ты покупаешь это же. Где тут две одинаковые покупки?


S>Ну ладно, про финансовые инструменты ты не слышал. Пусть я купил хлебушка.


Ок. Теперь покажи т.н. анализ ожиданий, логическую цепочку.

I>>При правильном подходе результат вполне определен — цель или достигается, или есть нечто неучтенное в условии. Другого быть не может. И цель это никак не отменяет.

S>Согласно твоим словам, цель либо гарантирована процессом, если процесс привел к успеху, либо недостижима, если не привел. Вот тебе процесс (если с газпромом так сложно): я покупаю хлебушка что бы набить брюхо. Почему сегодня результат может быть гарантированным, а завтра — недостижимым? Что я должен учесть?

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

I>>Ты путаешь постановку цели и конкретный результат.

S>Ну так объясни мне! Поесть хлебушка — гарантирует набить брюхо, или делает цель недостижимой принципиально?

См выше.

I>>Достаточно одного единственного, о котором стало известно в момент тестирования и который не отражен в скриптах. Тебе похоже даже в голову не приходит, как такое возможно

S>А тебе не приходит в голову, что это фактор можно отразить в скриптах.

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

Или так — ты заскриптуешь тот самый фактор, который случился у меня 8 лет назад во время прогона перформанс тестов, когда я только-только начал подогревать энвайрмент. Всё шло штатно, штанее некуда — все счетчики идеально ложились на ожидаемые результаты. Но прогон пришлось принудительно остановить. Вот покажи, пример скрипта. Потом мы вместе проверим, насколько хорош твой скрипт

Можешь иначе, текстом — сегодня или завтра, на крайняк до конца сего месяца, напиши сюда нечто, о чем ты ни разу не слышал, не видел, не подозревал с начала жизни и будешь ни видеть, ни слышать, ни подозревать вплоть до начала 2020