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

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

Изменено 11.11.2019 11:25 Pauel

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

S>>>В таком контексте восприятия слова "гарантии" мне не совсем ясно, как наличие кадра, занимающегося 100% поиском багов, влияет на возможность раздавать обещания компенсации? Контроль качества в виде систематической деятельности вообще напрямую с такими обещаниями не связан. Это ясно из твоего определения.


I>>Не всё следует из определения Эта систематическая деятельность нужна именно для того, что бы проблемы по максимуму выявлялись и исправлялись на стороне разработки.

I>>А далее нам нужна модель надежности, например, классификация, динамика, паттерны появления багов и тд. Собтсвенно это вероятностные методы, см. теория надежности.
I>>Например, если ты видишь, что наработка на отказ, условно, несколько лет, то даешь гарантию от себя "год обслуживаем за свой счет".

S>Это лирика. Ты привел определение. Если ты с ним не согласен, то чего его привел? Если согласен — почему у меня нет контроля качества? Ведь он следует из наличия любой систематической деятельности обусловленного направления по определению.


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

I>>Нет здесь никакого кота. Цель — разбогатеть — достигнута. А далее у тебя другая цель и она становится недостижимой, т.к. ты покупаешь газпром сам у себя.

S>Что значит, сам у себя? Я так не умею. Я тебе говорю про две одинаковых покупки. У одной, выходит, результат гарантированный, в то время, как у другой — недостижимый. Ничего не смущает?

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

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

I>> Простой пример — твой скрипт проверяет все имеющиеся счетчики производительности. А что на счет неучтенных факторов ? Как твой скрипт проверяет неучтенные факторы ?

S>Сколько тебе обычно нужно времени, что бы проверить ВСЕ неучтенные факторы вручную? Те, которые тебе взбредут в голову — можно заскриптовать. Которые не взбредут — как ты их проверишь вручную?

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

I>>Конечно же не равно. Давать обещание, если у теб нет никаких оснований, крайне странно.

S>Ты не с Марса? Вокруг меня все дают обещания, при отсутствии оснований их сдержать. Сдерживать обещание — лишь хороший тон, не более того. Взять деньги и не написать ни строчки кода — сплошь и рядом.

Я уже понял, что слово гарантии у тебя является синонимом их отсутствия.

I>>Я же прямо сказал — в простых случаях один разработчик справится. Что тут непонятно?

S>Непонятно — насколько простых. Где грань? Где об этом в определении? Что за отсебятина? Покажи определение, где бы упоминались "простые случаи".

Ты хочешь, что бы я изложил тебе теоретические основы качества, тестирования и надежности в одном определении. Может лучше сразу все тайны мироздания да в трех словах?
Re[86]: Мнение: объектно-ориентированное программирование —
Здравствуйте, samius, Вы писали:

S>>>В таком контексте восприятия слова "гарантии" мне не совсем ясно, как наличие кадра, занимающегося 100% поиском багов, влияет на возможность раздавать обещания компенсации? Контроль качества в виде систематической деятельности вообще напрямую с такими обещаниями не связан. Это ясно из твоего определения.


I>>Не всё следует из определения Эта систематическая деятельность нужна именно для того, что бы проблемы по максимуму выявлялись и исправлялись на стороне разработки.

I>>А далее нам нужна модель надежности, например, классификация, динамика, паттерны появления багов и тд. Собтсвенно это вероятностные методы, см. теория надежности.
I>>Например, если ты видишь, что наработка на отказ, условно, несколько лет, то даешь гарантию от себя "год обслуживаем за свой счет".

S>Это лирика. Ты привел определение. Если ты с ним не согласен, то чего его привел? Если согласен — почему у меня нет контроля качества? Ведь он следует из наличия любой систематической деятельности обусловленного направления по определению.


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

I>>Нет здесь никакого кота. Цель — разбогатеть — достигнута. А далее у тебя другая цель и она становится недостижимой, т.к. ты покупаешь газпром сам у себя.

S>Что значит, сам у себя? Я так не умею. Я тебе говорю про две одинаковых покупки. У одной, выходит, результат гарантированный, в то время, как у другой — недостижимый. Ничего не смущает?

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

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

I>> Простой пример — твой скрипт проверяет все имеющиеся счетчики производительности. А что на счет неучтенных факторов ? Как твой скрипт проверяет неучтенные факторы ?

S>Сколько тебе обычно нужно времени, что бы проверить ВСЕ неучтенные факторы вручную? Те, которые тебе взбредут в голову — можно заскриптовать. Которые не взбредут — как ты их проверишь вручную?

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

I>>Конечно же не равно. Давать обещание, если у теб нет никаких оснований, крайне странно.

S>Ты не с Марса? Вокруг меня все дают обещания, при отсутствии оснований их сдержать. Сдерживать обещание — лишь хороший тон, не более того. Взять деньги и не написать ни строчки кода — сплошь и рядом.

Я уже понял, что слово гарантии у тебя является синонимом их отсутствия.

I>>Я же прямо сказал — в простых случаях один разработчик справится. Что тут непонятно?

S>Непонятно — насколько простых. Где грань? Где об этом в определении? Что за отсебятина? Покажи определение, где бы упоминались "простые случаи".

Ты хочешь, что бы я изложил тебе теоретические основы качества, тестирования и надежности в одном определении. Может лучше сразу все тайны мироздания да в трех словах?