: Эта статья написана исключительно для развлечения. Не пытайтесь повторить это на работе. Однако дома делайте все, что хотите. Отказ от ответственности Мы, разработчики, регулярно сталкиваемся , это всего лишь часть нашей работы. Поэтому на первый взгляд вопрос «Можно ли специально сделать баг?» может показаться банальным — «Да, конечно, я могу написать баг». Однако, если вдуматься, все уже не кажется таким очевидным. с ошибками Дело в том, что . Баг – это ошибка, недостаток в целом. ошибка — это не то же самое, что сломанный код рабочая программа. Термин «ошибка» в контексте проблем с программным обеспечением возник в 1947 году, когда моль вызвала сбой в работе компьютера Harvard Mark II. Инженеры буквально обнаружили мотылька, застрявшего в одном из реле, и назвали это «первым реальным случаем обнаружения ошибки». В чем проблема? Известно, что мир хорошо описывается математическими формулами. А формулы на самом деле являются алгоритмами. Поэтому, если мы смогли описать какое-то явление математически, то исправить полученную формулу так, чтобы она давала неверный результат, — задача нетривиальная. Тем не менее, не время отчаиваться. Здесь нам могут помочь . Мы все видели это . С границами всегда что-то не так 🤷♀️. Итак, отметим первую идею создания бага — . лишь иногда граничные условия 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 и завоюйте его доверие. Или отвлекать их разговорами во время проверки. Кстати, вы слышали о Гейзенбаге? Это ошибка, которая исчезает или меняет свое поведение во время исследования/ . Как кот Шредингера. Идеально, если решение проблемы не будет поручено вам. отладки Одним из распространенных примеров ошибок Гейзенбага является ошибка, которая появляется, когда программа компилируется оптимизирующим компилятором, а не когда та же программа компилируется без оптимизации (как это часто делается с целью проверки ее отладчиком). Во время отладки значения, которые оптимизированная программа обычно хранит в регистрах, часто передаются в основную память. Ты можешь Верь в себя! История знает примеры, когда в очень серьезных компаниях допускали баг в производство. Одна из самых дорогостоящих ошибок в программном обеспечении произошла в 1996 году, когда ракета «Ариан-5», выполнявшая миссию «Кластер», взорвалась всего через 40 секунд после старта. Причиной сбоя стала программная ошибка в системе наведения ракеты. Рейс 501 «Ариан-5». В 1999 году НАСА потеряло Марсианский климатический орбитальный аппарат из-за ошибки программного обеспечения. Программное обеспечение использовало британские единицы (фунт-секунды) вместо метрических единиц (ньютоны-секунды), что привело к сгоранию космического корабля в марсианской атмосфере. Марсианский климатический орбитальный аппарат НАСА: Более того, некоторые ошибки могут стать функциями, например, прыжки через стену в или поведение Махатмы Ганда в … возможно. Марио Civilization Разработка ошибки — это способность продумать свой алгоритм и тщательно предвидеть возможные проблемы. Так что, даже если у вас нет причин оставлять ошибку в коде, об этом все равно стоит задуматься.
