Re[83]: Мнение: объектно-ориентированное программирование —
От: samius Япония http://sams-tricks.blogspot.com
Дата: 06.11.19 17:20
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>> Факт №1 — долголетие невозможно гарантировать. Следовательно у тебя гарантии есть выдумка.

S>>С пониманием гарантий долголетия почему-то у тебя нет проблем.

I>Гарантии качества совсем не такие. Никто не может гарантировать, что багов не будет, или что все баги будут найдены.

I>Гарантии качества совсем про другое.

I>Наоборот Деятельность может показать, что гарантии качества = 0. Заказчики смотрят на эту часть и видят, что слишком высокий риск и отчаливают, то есть — страхуют себя.


I>Ты буквально перефразировал свой поинт про долголетие

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

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

I>>>Цель — гарантии, но при этом цель не является обязательной

S>>Передергиваешь. Цель не является обязательным следствием действий, направленных на достижение этой цели.

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

Я покупаю газпром, что бы разбогатеть завтра на 100 рублей. Т.е. завтра мы узнаем, была ли цель обязательным результатом этой покупки, или недостижимым? Но если я завтра, разбогатев на 100 рублей, захочу еще раз купить газпром. То послезавтра эта же цель будет недостижимой, при том, что сегодня она была обязательным результатом.... Прям, кот Шредингера на ровном месте.

I>>>Но это все тестирование отдельных аспектов, а интересует тестирование всей системы в целом, в т.ч. буквально тесты на проде.

I>>>Пример "переводим трафик на x% нодов, смотрим метрики, возвращаем как было". Это тоже тестирование и никаким авто-тестами не делается. Например потому, что настандартная ситуация, про которую автотест не знает, может убить всё нахрен, т.к. это прод.
S>>И почему это никакими авто-тестами не делается? Что тут такого, чего не сможет выполнить и оценить автотест?

I>А я выделил ответ на твой вопрос. Нет способа заскриптовать "а проверь, есть ли нечто новое, неизвестное, подозрительное, что может повалить весь прод"

Поверь, нет способа это гарантированно выполнить и вручную за конечное время. Проблему останова знаешь?

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

S>>Определение не требует. Перечитай его. "Любая систематическая деятельность, направленная".

I>Требует. "Гарантированое подтверждение" включает в себя много всего

Гарантированное подтверждение соответствия требованиям — это цель. И кстати, подтверждение соответствию требований не равно обещанию компенсировать.

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


S>>Ты нестрог к формулировкам. Ты утверждаешь вещи, которые расходятся со здравым смыслом. Например, из твоего требования наличия кадра, 100% времени занимающегося поиском, следует что один лишь разработчик не может обеспечить контроль качества, т.к. его деятельность не может на 100% состоять из поиска новых багов.


I>Разработчик совмещая роль тестировщика находится в постоянном конфликте интересов. Цели противоположные — вместо "быстрее написать" появляется "тщательнее протестировать"

I>В простых случаях совмещение работает. Но только в простых. Кроме того, в общем случае до кучи к конфликту интересов это совершенно разные знания, умения, подходы и методологии.

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