Самые ошибки программистов

Как бы упорно мы не полагались на машины, они далеки от идеала. Как минимум, потому что сделаны человеком.

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

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

Начнём со странных вещей, коснувшихся относительно скромного числа людей, а закончим настоящими финансовыми катастрофами. Они стоили не один десяток бессонных ночей тем, кому пришлось срочно вычитывать хрупкий код и буквально спасать человечество.

1. Система заживо похоронила 8 500 пациентов больницы в Мичигане

В 2003 году Медцентр Св. Марии Милосердия в городе Гранд-Рапидс обновил свою программу для учёта больных до новой версии. Из-за неверного толкования данных переменные «выписан» и «скончался» перепутались.

Потому всем, кто уже прошёл лечение начали приходить уведомления о смерти по почте и в разных отчётах вроде анализа крови.

Проблема не стала бы масштабной, но из-за высокой автоматизации сообщения направились и пациентам, и в страховые службы. Когда последние видели, что человек «умирал», то переставали компенсировать последующее лечение. Сюда входило больше 2 000 пенсионеров и инвалидов.

Поскольку ошибку нашли через два месяца после поломки, примерно столько же потребовалось, чтобы восстановить информацию в сопутствующих службах и компенсировать ущерб.

2. Обновление ПО лишило 60 тысяч человек междугородных звонков

В январе 1990 года американский оператор связи AT&T улучшал свою программу по контролю переключателей между вышками. Из-за ошибки в коде одна из них во время звонка начала отправлять сигналы быстрее, чем другая могла их обработать.

Данные начали наслаиваться друг на друга, и проблема быстро распространилась по другим точкам. На обратном конце люди слышали только шум. Так продолжалось 9 часов.

Проблему решили откатом ПО до предыдущей версии, однако проблема не перестала быть актуальной.

Ситуация повторилась как минимум один раз в 1998 году, но тогда были затронуты только сервисные уведомления по SMS.

3. 5% всех магазинов России сломалось из‑за новой онлайн‑кассы

20 декабря 2017 года техника по контролю данных обновлялась, чтобы продавцы начали напрямую передавать информацию о транзакциях налоговой службе. Одно из таких улучшений заблокировало каждый двадцатый магазин страны.

Сбои начались в салонах сети DNS во Владивостоке, где люди просыпаются раньше Москвы. Система не давала отправлять расчёты в Федеральную налоговую службу (ФНС), а из-за этого кассиры не имели права реализовывать товар.

Пока проблема добралась до столицы, откуда начал решаться вопрос, по всей России встали некоторые точки Магнита, Пятёрочки с Перекрёстком, Эльдорадо и аптек Ригла.

ФНС пришлось быстро реагировать и разрешать магазинам работать в офлайн режиме. Тем разрешили вносить данные после того, как система восстановится.

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

Теоретический ущерб, по мнению Ассоциации компаний интернет-торговли, мог дойти до 2,5 млрд рублей. Реальный оказался чуть ниже благодаря быстрой оптимизации процессов со стороны ФНС.

4. Машине дали проектировать стадион в Коннектикуте. Тот рухнул

С 1972 года город Хартфорд старался расширить свою инфраструктуру и вкладывался в крупные проекты. Одним из них стал Hartford Civic Center – комплекс торговых, развлекательных и спортивных площадок.

Структуру стадиона проектировали через программу, что вместе с оптимизированным расходом материалов сэкономило городу около $500 тысяч.

Комплекс полностью функционировал и даже был «домом» для местной хоккейной группы New England Whalers с 1975 года.

Однако утром 18 января 1978-го стадион обвалился. Игр в тот день не проходило: здание было пустым и никто не пострадал.

СМИ растиражировали новость, где причиной указывали тяжесть снега. Но расследование показало, что на самом деле проблема была комплексной, а корнем оказалось наивное доверие программе.

Четыре несущие колонны с момента возведения были плохо продуманы в размере и креплении. Стадион начал постепенно «складываться» ещё во время строительства, а группы по контролю качества распределялись между разными подрядчиками и плохо согласовали данные.

Восстановление стоило городу $90 млн. В последствии на месте комплекса возвели арену XL Center, которая до сих пор исполняет роль главной спортивной площадки Хартфорда.

5. Intel выпустила процессор с ошибкой и устроила международный скандал

В 1994 году CPU под брендом Pentium был флагманом компании, и в нём пряталась микроскопическая проблема, которая касалась крошечной части людей: когда пользователь делил одно число на другое, результат был неверным. Выглядела ошибка так:

Программисты неправильно настроили одну из веток операций, вшитых в процессор. Она искала корневые данные и находила не те.

При этом основной ущерб пришёлся не на пользователей, а на компанию.

Из-за того, что Intel уже тогда уверенно чувствовала себя на рынке, а чипы были новые, даже федеральные СМИ многих стран подхватили новость и нанесли катастрофический ущерб имиджу и доходу компании.

В итоге за 1994 год замена всех повреждённых процессоров сократила выручку компании вдвое от запланированной – на $475 млн.

6. 6 миллионов автомобилей могут не раскрыть воздушные подушки

В январе 2020 года выяснилось, что датчики в некоторых моделях компаний Toyota и Honda слишком чувствительны к электрическому шуму.

Есть вероятность того, что в момент столкновения система не подаст сигнал системе безопасности. Та не сможет удержать ремни натянутыми, а подушки не наполнятся воздухом.

Проблема может быть глобальнее, поскольку компьютер из автомобилей Toyota разрабатывался сторонней организацией ZF-TRW. А она поставляла свои наработки как минимум шести компаниям в одних США, которые продали 12,3 млн машин.

Но пока только японские производители решили чинить датчики. И то, многие всё ещё ждут уведомления от своих диллеров.

7. MySpace уничтожил 50 миллионов песен пользователей

В 2016 году компания делала миграцию данных, которая началась еще в 2013 году. Уже тогда некоторые материалы и аккаунты стали недоступны части пользователей.

А в ходе переноса своей огромной библиотеки музыки, фотографий и видео возникла ошибка на сервере, которая их безвозвратно удалила.

Поскольку точной причины руководство не раскрыло, по поводу источника проблемы ходят разные слухи. Например, есть предположение, что хранить такой объём старых данных невыгодно и руководству было дешевле его «случайно» удалить.

Так или иначе, мир потерял один из крупнейших пластов интернет-культуры с 2003 по 2015 годы.

8. 144 тысячи родителей-одиночек не получили государственных выплат

В апреле 2003 года британская компания по поддержке малообеспеченных и неполноценных семей Child Support Agency внедрила систему по фильтрации заявлений. Она стоила £300 млн.

Спустя полгода обнаружилось, что обрабатывалась меньше, чем двадцатая часть просьб, и многие дети остались без материальной помощи.

Скандал длился как минимум до 2006 года, пока программа продолжала съедать 70% выделяемых на проект денег и затраты к 2010 году не составили £1,1 млрд.

В итоге в 2012 году агенство закрыли и вместо него запустили новую организацию Child Maintenance Group.

9. Уязвимость в защите 500 тысяч крупнейших сайтов давала доступ к вашей RAM

В апреле 2014 года специалисты по информационной безопасности обнаружили в библиотеке OpenSSL, на которой держится самый распространённый протокол HTTPS, критическую дыру в безопасности.

Её назвали Heartbleed по аналогии с процессом Heartbeat, взятым за основу этой ошибки.

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

И, хотя максимальный объём украденной информации не мог превышать 64 Кб за один запрос, этого хватало на доступ к паролям и конфиденциальным сообщениям.

Ошибка затронула 17% всех защищенных сайтов. В том числе Google, Facebook, Instagram, Twitter и даже Minecraft.

Опасность закрывалась простым патчем, поэтому многие компании отреагировали быстро.

Однако по масштабу с этой проблемой сопоставима только одна, и вы наверняка о ней хоть раз слышали.

10. Мир потратил $300 млрд, чтобы в 2000 году компьютеры продолжили работать

Фото Эмори Кристоф / Emory Kristof

До 1999 года системы программировали так, что одни отмечали даты форматом из 8 цифр (ЧЧ.ММ.ГГГГ), а другие оставляли 6.

Это могло привести к тому, что переход в новое тысячелетие вызвал бы ошибки в программах по всей планете.

Дата формата ЧЧ.ММ.ГГ могла заменить 2000 на 1900 год, поскольку оба числа кончаются на «ОО». Таким образом ошибка бы переписала и стёрла данные, нарушила работу алгоритмов и спровоцировала коллапс онлайн-систем.

Большинство времени и ресурсов компаний ушло не на исправление последствий, а на то, чтобы проверить каждый компьютер в компании.

Поскольку программное обеспечение не переживало таких прыжков в исчислении времени раньше, ситуацию обсуждали по всему миру.

Вокруг Проблемы 2000 года (или Y2K) было много разговоров, в том числе о целесообразности паники. Их подогревало то, что страны восприняли вопрос серьезно и прописывали инициативы на государственном уровне.

Например, Россия создала официальный документ Национальный план действий по решению “Проблемы 2000” в Российской Федерации.

Табло на последней строке «обнулилось» и показывает 1900 вместо 2000

Ближайшая похожая ошибка настигнет не оптимизированные 32-битные системы в январе 2038 года, однако программисты уже готовятся к переходу.

64-х битных систем ситуация коснётся через 292 миллиарда лет, так что тут можно расслабиться.

Куда реальнее и скорее грозит Проблема 10 000 года своим переходом на значения из пяти цифр. Кажется, что не стоит о ней беспокоиться – пока вопрос ведь скорее теоретический.

Правда, всегда есть вероятность того, что крупицы существующего кода из вашего смартфона доживут до той эпохи.

Может, призадуматься и стоит.

(30 голосов, общий рейтинг: 4.77 из 5)

Переводчик-фрилансер. Увлечён своей профессией. Переводит полезные статьи на разные темы — от IT до путешествий, урбанистики и социологии. Занимается лингвистическими исследованиями.

---

об авторе

Живёт в Нидерландах, занимается backend-разработкой, увлечённо инвестирует в криптовалюты.

---

---

Человеку свойственно ошибаться. День за днём все мы совершаем промашки. И на работе тоже.

Создание программ — задача сложная. Без ошибок здесь не обходится. Какие-то ошибки пустяковые, какие-то — серьёзные. Но они были и будут всегда.

И это хорошо. Потому что ошибки ценны. Конечно, если мы извлекаем из них уроки — и растём профессионально. Как говорила Элеонора Рузвельт, жизнь слишком коротка, чтобы тратить её на повторение чужих ошибок. Так что лучше на них учиться.

Я расскажу про самые частые ошибки разработчиков. Надеюсь, вы научитесь их избегать.

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

Помните об этом и будьте внимательны.

Я часто сталкиваюсь с тем, что в репозитории оказываются лишние файлы или в нём чего-то недостаёт. Это происходит тогда, когда фиксируют слишком много изменений за раз. Тут уж немудрено надобавлять лишнего или забыть что-то нужное.

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

С другой стороны, есть файлы, про которые часто забывают — по незнанию или не разобравшись в их назначении. Например, файл yarn.lock. Разработчики не понимают, зачем он нужен, — и потому боятся добавлять в репозиторий. Или считают, что этот файл важен только в их локальном окружении.

Чаще всего из-за пропавшего файла что-нибудь пойдёт не так, а что конкретно — зависит от файла. Например, если не хватает yarn.lock, вы получите разные зависимости для всех ваших окружений, что легко породит самые дурацкие ошибки.

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

Безусловно, иногда допустимо кодить «грязно». Когда главное — быстро получить результат. Например, если код нужен ненадолго или вовсе на раз. Но если кодом, который держится на костылях, будут пользоваться постоянно — это вам ещё аукнется.

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

А вам надо быстрее выдавать адекватный код, который верно решает поставленную задачу. Это значит — оптимальный для её условий, требований к кодингу в команде, понятный коллегам и так далее, а вовсе не лучший из всех возможных (например, по своим техническим характеристикам).

Так у вас останется время на действительно полезную работу.

Каждый разработчик хоть раз в жизни писал совсем короткий код — буквально пару строк. Казалось, тут просто нечему ломаться. И верно: здесь не ломалось — ломалось где-то ещё, но виноваты были как раз те две строчки.

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

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

В наследовании как таковом нет ничего плохого. Но я замечаю, что разработчики слишком уж им увлекаются. Это частая ошибка.

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

Так что помните: наследование — всё же не палочка-выручалочка, а палка о двух концах.

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

И это проблема. Потому что такие разработчики продолжают изобретать методы и инструменты, аналоги которых во фреймворке уже есть. То есть не только тратят время впустую, но и не пользуются потенциалом фреймворка — усложняют повторное использование кода.

Чтобы не делать двойную и тройную работу, изучайте фреймворки тщательнее.

Не учиться чему-то новому — самая досадная ошибка разработчика.

Да, не всегда получается учиться на работе — приходится тратить и личное время. Но это необходимо, чтобы оставаться востребованным, это инвестиции в себя.

Ключ к совершенству — в практике, это знают все. Без неё не получить полезные навыки, не освоить другие языки программирования, новые технологии и так далее.

Как попрактиковаться? Вот вам идеи pet-проектов, которые вы можете воплотить.

«Это задача в один стори поинт. Я быстро с ней управлюсь», — думали вы.

А всё оказалось иначе. Решение в лоб заработало не так, как ожидали. Пробуете альтернативное — на него уходит гораздо больше времени.

Недооценивать объём работы — ошибка частая, особенно в командах с гибким управлением проектами (типа Scrum).

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

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

Самоуверенные разработчики порой забывают, что тоже совершают ошибки. И чаще начинают принимать решения единолично, не консультируясь ни с кем. Однажды это непременно выйдет им боком: либо качество решений упадёт, либо коллеги начнут чувствовать себя ненужными.

Разработчик не может разбираться сразу во всём и делать всё одинаково хорошо. Стоит это осознать.

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

Integer overflow

Ракета-носитель Ariane 5 была запущена в 1996 году. Стоимость создания этой ракеты составила около 7 миллиардов долларов, а авария, которая произошла во время отрыва обошлась в 500 миллионов долларов. Ошибка была вызвана благодаря Integer overflow. Дело в том, что система попыталась впихнуть 64-bit floating point number в 16-bit signed integer. Это привело к ошибке, а в последствии к большому взрыву.

Символ, стоимостью 135 миллионов $

Космический аппарат Mariner 1 был запущен в 1962 году с целью первого полета вокруг Венеры. Практически с первых минут что-то начало идти не так и он сильно отклонился от заданого маршрута. Чтобы аппарат не упал на населенный пункт было принято решение взорвать его.

Считается, что ошибкой тому могла была быть точка вместо запятой. Таким образом код мог быть неправильно понятым компьютером и соответсвенно вызвал баги в системе.

Кроме того, считается что всему вина неправильно записанная формула. Так, формула Rn была записана без верхнего подчеркивания. Как бы там не было, но ошибка скрывается всего в одном символе, который кто-то когда-то неправильно записал.

Ошибка с Windows NT

В 1996 году на один из крейсеров было принято решение установить специальное ПО, так называемое Windows NT. Это было сделано в целях оптимизировать работу персонала, а также дополнительно облегчить им эту работу.

Корабль работал исправно в течении года, пока не произошел один случай. Один из членов экипажа ввел в базу данных число 0, что делать не надо. В системе не было установлена обработка подобного случая, что привело к делению на ноль. В итоге система запуталась и отключилась. Корабль дрейфил в полной отключке около трех часов.

К счастью, все обошлось, но если бы подобное случилось в бою или же во время шторма, то все могло сложиться не так успешно!

Взрыв газопровода в Сибири

Благодаря Канаде в 1982 году, ребята из ЦРУ узнали информацию о том, что КГБ планирует украсть у них систему управления газопроводом. Было принято решение дать троян, который постепенно бы ухудшал систему газопровода в СРСР и привел бы к взрыву. Так и случилось. КГБ клюнули на небольшой слив информации и подцепили настоящий вирус. 

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