Сьогодні переглядаючи публікацію Єгора Бугаєнка When Do You Stop Testing!, з подивом виявив, що мало хто розуміє і замислюється про те, що проблема тестування і затвердження того, що система не має недоліків принципово не вирішується. Це до речі ще актуально і у зв'язку з впровадженням електронних виборів, і вимогами з боку офіційних осіб і журналістів доказів відсутності дірок у системі безпеки. Наприклад у нас (Естонія) ця дискусія йде повним ходом, і політики хочуть отримати стовідсоткові докази надійності системи електронних виборів. Публічні політики, як правило незнайомі з логікою в її формальному вигляді. А Юм і Поппер, в кращому випадку, нагадують про якісь нудні філософські семінари, про які краще забути. Але коли я чую про те, що тестер або сеньйор починає цілком серйозно доводити, що код протестований і помилок немає зовсім, моє обличчя набуває цей вираз:
Існує кілька основних моментів, чому сама постановка такого типу питань повинна бути виключена, тим більше з вуст ІТ професіоналів.
Перший момент - логічний
Проблема індукції, яку серйозно розглянув Юм, ставить під сумнів саму можливість обґрунтування цілого ряду проблем і питань. Наприклад, виведення певних загальних висновків з наявності якихось приватних спостережень неможливо. Необмежена кількість спостережень чогось, не підтверджує істинність твердження. Карл Поппер, один з неймовірних геніїв в історії людства, звернув увагу на проблему фальсифікації, і став автором нової парадигми у філософії науки. Яка суть проблеми фальсифікації і як це стосується нас? Найвідоміший приклад, - це «Чорний Лебідь». Чорний Лебідь був символом неможливості чогось у 16 столітті в Лондоні. Старий Світ припускав, що всі лебеді білі, оскільки всі історичні записи про лебедів описували їх білі пір'я. І в цьому контексті чорні лебеді були неможливі, або не існували. Проте в 17 столітті представник Старого Світу зустрів неможливість в Австралії.
Існує асиметрія між підтвердженням і фальсифікацією. Проблема індукції полягає в тому, що індивідуальне твердження, як цей лебідь білий, або роблячи те і те, в такому контексті, помилки не відбулося, не може бути узагальнене на універсальне затвердження. Сингулярне утвердження існування не доводить загальне.
Наприклад, якщо останні 4,5 мільярда років Сонце регулярно (добре - добре, з якимось уповільненням) сходило над горизонтом, то це не говорить нам, що Сонце завжди встає над горизонтом. Або любитель парадоксів Б. Рассел наводить приклад з індичкою, яку годують, за якою доглядають, і вона думає, що так буде завжди, поки не настає той самий день, день Подяки.
Таким чином, щоб довести, що всі лебеді білі, ми повинні перевірити всіх лебедів у Всесвіті, і Лейбніц мені нашіптує, що це повинні бути всі можливі світи, що природно неможливо. Але для того, щоб спростувати це твердження, достатньо приїхати до Австралії, і зустріти одного чорного лебедя. Таким чином існує фундаментальна асиметрія між підтвердженням і фальсифікацією.
Говорити про відсутність багів у коді, або дірок у системі в цьому контексті неправильно. Не можна навіть ставити питання в цій площині, тому, що це відводить дискусію в абсолютно неправильному напрямку, особливо якщо в ній задіяні люди незіпсовані матаном.
Другий момент - обчислювальний
Теорема Райса накладає відбиток песимізму на нашу можливість створювати досконалі системи. Наслідок теореми Райса, яка в загальному вигляді випливає з проблеми зупинки машини Тюринга і обчислення, стверджує, що не існує універсального алгоритму для доведення або твердження про те, що програма, система, або алгоритм не містить помилок і робить те, що треба. Автоматичні універсальні системи тестування в загальному неможливі. Зокрема так, але що б ми не робили, - баги будуть! Статична типізація, TDD та інші методики можуть тільки вселити в нас більше впевненості і позбавити від деяких страхів, не більше.
Третій момент - інженерний
Існують такі ситуації, що ми можемо навіть знати, що у нас існує якийсь специфічний погляд, який руйнує нашу систему, тому, що ми спостерігали це в який-небудь момент. Ми знаємо, що є. Але ми не можемо його репродукувати. Я маю на увазі проблеми в мультипоточних додатках, де править бал недетермінізм. Немає особливих проблем виловити порожній, якщо сервер руйнується кожні десять хвилин. Але якщо нам необхідно, щоб сервер працював кілька місяців перш ніж проблема знову повернулася. Це в прямому сенсі неможливо налагодити. Гірше того, як згадував Paul Butcher, цілком ймовірно писати програми, які містять мультипоточні баги, які ніколи не проявляться незважаючи на те, як ретельно або як довго ми б тестували їх. Тільки тому, що звернення потоків до пам'яті можуть бути переупорядковані, не означає, що так і буде зроблено. І ми цілком можемо бути абсолютно в невіданні про наявність проблем, поки ми не зробимо апгрейд JVM або перейдемо на інше залізо, де ми раптово зіткнемося з таємничими проблемами, які ніхто не розуміє.
Всі ці три моменти роблять саме твердження про те, що багів немає, або про доказ безпеки чого-небудь безглуздим. Дуже великий відсоток ІТ професіоналів також не розуміє цього. Прекрасний приклад у пості Єгора Бугаєнка.
Якби мені запропонували на вибір дві супер здатності, вміння ділити на нуль, або знаходити всі баги в коді, то я б задумався, що взяти, тому що це речі одного порядку.
