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

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

PJ>>>Невозможно гарантировать изменение кода без вероятности внесения бага. Точка.
I>>C этим никто не спорит

C>

I>>>"Никто — ни конечный пользователь, ни программист — не сможет сказать по внешнему виду, что что-то изменилось"
I>>>(Рефакторинг, 2003, изд Символ, Спб, стра 62 последний абзац)

I>>Любые внешние провеки, в любом количестве.

Небольшой ликбез по контролю качества:

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

Парадокс — из этого никак не следует ненужность тестов, испытаний и тд

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

На примере, ты пишешь некий шустрый аналог мутекса. От него все и всегда ждут гарантий.
1 "Невозможно гарантировать изменение кода без вероятности внесения бага."

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

2 Следовательно, нужен жесткий контроль, не глазом, а фиксация внешнего поведения.

Соответсвенно — внешнее поведение мутекса надо покрыть тестами. Использующий его код — другими тестами.
Более того — при обнаружении проблем их нужно решать и эти кейсы так же покрывать тестами.

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

PJ>>>Невозможно гарантировать изменение кода без вероятности внесения бага. Точка.
I>>C этим никто не спорит

C>

I>>>"Никто — ни конечный пользователь, ни программист — не сможет сказать по внешнему виду, что что-то изменилось"
I>>>(Рефакторинг, 2003, изд Символ, Спб, стра 62 последний абзац)

I>>Любые внешние провеки, в любом количестве.

Небольшой ликбез по контролю качества — качество, как степень соответствия требованиям, есть вероятностная величина которая никогда не бывает 100%. 0 — да. 100 — никогда.

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

Парадокс — из этого никак не следует ненужность тестов, испытаний и тд

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

На примере, ты пишешь некий шустрый аналог мутекса. От него все и всегда ждут гарантий.
1 "Невозможно гарантировать изменение кода без вероятности внесения бага."

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

2 Следовательно, нужен жесткий контроль, не глазом, а фиксация внешнего поведения.

Соответсвенно — внешнее поведение мутекса надо покрыть тестами. Использующий его код — другими тестами.
Более того — при обнаружении проблем их нужно решать и эти кейсы так же покрывать тестами.