Можно ли намеренно сделать ошибку?

Мы, разработчики, регулярно сталкиваемся с ошибками , это всего лишь часть нашей работы. Поэтому на первый взгляд вопрос «Можно ли специально сделать баг?» может показаться банальным — «Да, конечно, я могу написать баг». Однако, если вдуматься, все уже не кажется таким очевидным.

Дело в том, что ошибка — это не то же самое, что сломанный код . Баг – это ошибка, недостаток в целом.

рабочая программа.

В чем проблема?

Известно, что мир хорошо описывается математическими формулами. А формулы на самом деле являются алгоритмами. Поэтому, если мы смогли описать какое-то явление математически, то исправить полученную формулу так, чтобы она лишь иногда давала неверный результат, — задача нетривиальная. Тем не менее, не время отчаиваться. Здесь нам могут помочь граничные условия . Мы все видели это if index == 0 {…} else if index == n-1 {…} . С границами всегда что-то не так 🤷‍♀️. Итак, отметим первую идею создания бага — игнорирование крайних случаев .

В общем, перебор массивов — это кладезь потенциальных ошибок. И самый распространенный из них — index out ofbounds . Если вы никогда не сталкивались с такой вещью, вы никогда не программировали. К сожалению, эта ошибка настолько популярна, что люди начали писать безопасные оболочки для массивов, что-то вроде array[safe: index] . Так что сегодня ваши коллеги вряд ли утвердят какой-либо кодекс без этой штуки. Попробовать можно, но это вряд ли…

Распространенные ошибки включают переполнение стека . Рекурсивный алгоритм может повторяться бесконечно, если нет условия выхода. Рекурсия здесь кажется необязательной — напишите while true , и все готово. Однако, опять же, популярность бага играет против нас. Разработчики прекрасно знают о потенциальных проблемах бесконечных циклов, и на код-ревью их взгляд обязательно бросится на что-то подобное 👮

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

 var coditionCounter = 0; class A { func foo() { while coditionCounter < 10 { coditionCounter++; B.boo(); } } } class B { func boo() { coditionCounter--; } }

Общие советы

Забавно, что даже ChatGPT отказывается помочь, когда дело доходит до написания ошибок. Возможно, мне просто нужна премиум-подписка… 🤔

Положительная сторона ИИ заключается в том, что он предлагает набор общих правил, которые способствуют написанию кода без ошибок: кодируйте небольшими шагами, следуйте стандартам кодирования, пишите модульные тесты и бла-бла-бла. Мы можем попробовать сделать обратное — написать спагетти-код и забыть о SOLID. Однако таким образом мы теряем контроль над всем написанным нами кодом . Вместо изящного точечного оружия мы получаем неуправляемый хаос, который победит нашу программу.

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

Мой общий совет таков (вы поделитесь своим в комментариях):

• Управляйте уровнем доступа . Чтобы вернуться назад, измените значения важных параметров в самых неожиданных местах. Сделайте это через несколько занятий, как если бы вы были VPN.

• Реализуйте неожиданную логику в дочернем классе. Короче говоря, сломайте принцип L в SOLID .

   class A { func decrease() { x--; } } class B: A { override func decrease() { x++; } }

• Скрывайте свои коварные изменения в более крупных функциях. Чем больше очередей, тем лучше – затеряйтесь в толпе.

• Используйте тот же принцип в запросах на включение. В небольшом пиаре вероятность быть замеченным выше.

• Попробуйте разбить ошибку на части и поместить их в разные пул-реквесты . Если можно, то и разным рецензентам.

• Найдите слабые места вашего QA и завоюйте его доверие. Или отвлекать их разговорами во время проверки.

Кстати, вы слышали о Гейзенбаге? Это ошибка, которая исчезает или меняет свое поведение во время исследования/ отладки . Как кот Шредингера. Идеально, если решение проблемы не будет поручено вам.

Ты можешь

Верь в себя! История знает примеры, когда в очень серьезных компаниях допускали баг в производство.

Рейс 501 «Ариан-5». Одна из самых дорогостоящих ошибок в программном обеспечении произошла в 1996 году, когда ракета «Ариан-5», выполнявшая миссию «Кластер», взорвалась всего через 40 секунд после старта. Причиной сбоя стала программная ошибка в системе наведения ракеты.

Марсианский климатический орбитальный аппарат НАСА: В 1999 году НАСА потеряло Марсианский климатический орбитальный аппарат из-за ошибки программного обеспечения. Программное обеспечение использовало британские единицы (фунт-секунды) вместо метрических единиц (ньютоны-секунды), что привело к сгоранию космического корабля в марсианской атмосфере.

Более того, некоторые ошибки могут стать функциями, например, прыжки через стену в Марио или поведение Махатмы Ганда в Civilization … возможно.

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