Возникновение может привести к ошибкам

При работе с big data ошибок не избежать. Вам нужно докопаться до сути данных, расставить приоритеты, оптимизировать, визуализировать данные, извлечь правильные идеи. По результатам опросов, 85 % компаний стремятся к управлению данными, но только 37% сообщают об успехах в этой области. На практике изучать негативный опыт сложно, поскольку о провалах никто не любит говорить. Аналитики с удовольствием расскажут об успехах, но как только речь зайдет об ошибках, будьте готовы услышать про «накопление шума», «ложную корреляцию» и «случайную эндогенность», и без всякой конкретики. Действительно ли проблемы с big data существуют по большей части лишь на уровне теории?

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

Ошибки выборки

В статье «Big data: A big mistake?» вспомнили об интересной истории со стартапом Street Bump. Компания предложила жителям Бостона следить за состоянием дорожного покрытия с помощью мобильного приложения. Софт фиксировал положение смартфона и аномальные отклонения от нормы: ямы, кочки, выбоины и т.д. Полученные данные в режиме реального времени отправлялись нужному адресату в муниципальные службы.

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

В результате основным объектом исследования стало событие в приложении, но статистически значимой единицей интереса должен был оказаться человек, использующий мобильное устройство. Учитывая демографию пользователей смартфонов (на тот момент это в основном белые американцы со средним и высоким уровнем дохода), стало понятно, насколько ненадежными оказались данные.

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

По словам авторов исследования «Обзор методов обработки селективности в источниках больших данных», существует множество источников big data, не предназначенных для точного статистического анализа — опросы в интернете, просмотры страниц в Твиттере и Википедии, Google Trends, анализ частотности хештегов и др.

Одной из самых ярких ошибок такого рода является прогнозирование победы Хилари Клинтон на президентских выборах в США в 2016 году. По данным опроса Reuters/Ipsos, опубликованным за несколько часов до начала голосования, вероятность победы Клинтон составляла 90%. Исследователи предполагают, что методологически сам опрос мог быть проведен безупречно, а вот база, состоящая из 15 тыс. человек в 50 штатах, повела себя иррационально — вероятно, многие просто не признавались, что хотят проголосовать за Трампа.

Ошибки корреляций

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

На диаграмме выше показано общее количество наблюдений НЛО с 1963 года. Число зарегистрированных случаев из базы данных Национального центра отчетности по НЛО в течение многих лет оставалось примерно на одном уровне, однако в 1993 году произошел резкий скачок.

Таким образом, можно сделать совершенно логичный вывод, что 27 лет назад пришельцы всерьез взялись за изучение землян. Реальная же причина заключалась в том, что в сентябре 1993 года вышел первый эпизод «Секретных материалов» (на пике его посмотрели более 25 млн человек в США).

Теперь взгляните на данные, которые показывают частоту наблюдений НЛО в зависимости от времени суток и дня недели: желто-оранжевым окрашена наибольшая частота случаев наблюдения. Очевидно, что пришельцы чаще высаживаются на Землю в выходные, потому что в остальное время они ходят на работу. Значит, исследование людей для них — хобби?

Эти веселые корреляции имеют далеко идущие последствия. Так, например, исследование «Доступ к печати в сообществах с низким уровнем дохода» показало, что школьники, имеющие доступ к большему количеству книг, получают лучшие оценки. Руководствуясь данными научной работы, власти Филадельфии (США) занялись реорганизацией системы образования.

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

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

Потеря данных

(с)

Иногда выборка может быть верной, но авторы просто теряют необходимые для анализа данные. Так произошло в работе, широко разошедшейся по миру под названием «Фрикономика». В книге, общий тираж которой превысил 4 млн экземпляров, исследовался феномен возникновения неочевидных причинно-следственных связей. Например, среди громких идей книги звучит мысль, что причиной спада подростковой преступности в США стал не рост экономики и культуры, а легализация абортов.

Авторы «Фрикономики», профессор экономики Чикагского университета Стивен Левитт и журналист Стивен Дабнер, через несколько лет признались, что в итоговое исследование абортов попали не все собранные цифры, поскольку данные просто исчезли. Левитт объяснил методологический просчет тем, что в тот момент «они очень устали», и сослался на статистическую незначимость этих данных для общего вывода исследования.

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

Ошибки анализа

(с)

Биотех стал для технологических предпринимателей новым рок-н-роллом. Его также называют «новым IT-рынком» и даже «новым криптомиром», имея ввиду взрывную популярность у инвесторов компаний, занимающихся обработкой биомедицинской информации.

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

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

Тревогу вызывает большое количество научных работ в области генетики, в которых содержатся ошибки. Команда австралийских исследователей проанализировала около 3,6 тыс. генетических работ, опубликованных в ряде ведущих научных журналов. В результате обнаружилось, что примерно одна из пяти работ включала в свои списки генов ошибки.

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

В научной литературе гены часто обозначаются символами: например, ген Септин-2 сокращают до SEPT2, а Membrane Associated Ring Finger (C3HC4) 1 — до MARCH1. Excel, опираясь на настройки по умолчанию, заменял эти строки датами. Исследователи отметили, что не стали первооткрывателями проблемы — на нее указывали более десятилетия назад.

В другом случае Excel нанес крупный удар по экономической науке. Знаменитые экономисты Гарвардского университета Кармен Рейнхарт и Кеннет Рогофф в исследовательской работе проанализировали 3,7 тыс. различных случаев увеличения госдолга и его влияние на рост экономики 42 стран в течение 200 лет.

Работа «Рост за время долга» однозначно указывала, что при уровне госдолга ниже 90 % ВВП он практически не влияет на рост экономики. Если же госдолг превышает 90 % ВВП, медианные темпы роста падают на 1 %.

Исследование оказало огромное влияние на то, как мир боролся с последним экономическим кризисом. Работа широко цитировалась для оправдания сокращения бюджета в США и Европе.

Однако несколько лет спустя Томас Херндорн, Майкл Эш и Роберт Поллин из Университета Массачусетса, разобрав по пунктам работу Рогоффа и Рейнхарта, выявили банальные неточности при работе с Excel. Статистика, на самом деле, не показывает никакой зависимости между темпами роста ВВП и госдолгом.

Заключение: исправление ошибок как источник ошибок

(с)

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

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

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

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

Правильно анализировать большие данные мы можем научить в Академии MADE — бесплатном образовательном проекте от Mail.ru Group. Заявки на обучение принимаем до 1 августа включительно.

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

Определение

Ошибка в программировании (или так называемый баг) – это ситуация у разработчиков, при которой определенный код вследствие обработки выдает неверный результат. Причин данному явлению множество: неисправность компилятора, сбои интерфейса, неточности и нарушения в программном коде.

Баги обнаруживаются чаще всего в момент отладки или бета-тестирования. Реже – после итогового релиза готовой программы. Вот несколько вариантов багов:

1. Появляется сообщение об ошибке, но приложение продолжает функционировать.
2. ПО вылетает или зависает. Никаких предупреждений или предпосылок этому не было. Процедура осуществляется неожиданно для пользователя. Возможен вариант, при котором контент перезапускается самостоятельно и непредсказуемо.
3. Одно из событий, описанных ранее, сопровождается отправкой отчетов разработчикам.

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

История происхождения термина

Баг – слово, которое используется разработчиками в качестве сленга. Оно произошло от слова «bug» – «жук». Точно неизвестно, откуда в программировании и IT возник соответствующий термин. Существуют две теории:

1. 9 сентября 1945 года ученые из Гарварда тестировали очередную вычислительную машину. Она называлась Mark II Aiken Relay Calculator. Устройство начало работать с ошибками. Когда его разобрали, то ученые заметили мотылька, застрявшего между реле. Тогда некая Грейс Хоппер назвала произошедший сбой упомянутым термином.
2. Слово «баг» появилось задолго до появления Mark II. Термин использовался Томасом Эдисоном и указывал на мелкие недочеты и трудности. Во время Второй Мировой войны «bugs» называли проблемы с радарной электроникой.

Второй вариант кажется более реалистичным. Это факт, который подтвержден документально. Со временем научились различать различные типы багов в IT. Далее они будут рассмотрены более подробно.

Как классифицируют

Ошибки работы программ разделяются по разным факторам. Классификация у рядовых пользователей и разработчиков различается. То, что для первых – «просто программа вылетела» или «глючит», для вторых – огромная головная боль. Но существует и общепринятая классификация ошибок. Пример – по критичности:

1. Серьезные неполадки. Это нарушения работоспособности приложения, которые могут приводить к непредвиденным крупным изменениям.
2. Незначительные ошибки в программах. Чаще всего не оказывают серьезного воздействия на функциональность ПО.
3. Showstopper. Критические проблемы в приложении или аппаратном обеспечении. Приводят к выходу программы из строя почти всегда. Для примера можно взять любое клиент-серверное приложение, в котором не получается авторизоваться через логин и пароль.

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

Также существуют различные виды сбоев в плане частоты проявления: постоянные и «разовые». Вторые встречаются редко, чаще – при определенных настройках и действиях со стороны пользователя. Первые появляются независимо от используемой платформы и выполненных клиентом манипуляций.

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

Виды

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

Разработчики выделяют следующие типы ошибок по уровню сложности:

1. «Борбаг» – «стабильная» неполадка. Она легко обнаруживается на этапе разработки и компилирования. Иногда – во время тестирования наработкой исходной программы.
2. «Гейзенбаг» – баги с поддержкой изменения свойств, включая зависимость от среды, в которой было запущено приложение. Сюда относят периодические неполадки в программах. Они могут исчезать на некоторое время, но через какой-то промежуток вновь дают о себе знать.
3. «Мандельбаг» – непредвиденные ошибки. Обладают энтропийным поведением. Предсказать, к чему они приведут, практически невозможно.
4. «Шрединбаг» – критические неполадки. Приводят к тому, что злоумышленники могут взломать программу. Данный тип ошибок обнаружить достаточно трудно, потому что они никак себя не проявляют.

Также есть классификация «по критичности». Тут всего два варианта – warning («варнинги») и критические весомые сбои. Первые сопровождаются характерными сообщениями и отчетами для разработчиков. Они не представляют серьезной опасности для работоспособности приложения. При компилировании такие сбои легко исправляются. В отдельных случаях компилятор справляется с этой задачей самостоятельно. А вот критические весомые сбои говорят сами за себя. Они приводят к серьезным нарушениям ПО. Исправляются обычно путем проработки логики и значительных изменений программного кода.

Типы багов

Ошибки в программах бывают:

• логическими;
• синтаксическими;
• взаимодействия;
• компиляционные;
• ресурсные;
• арифметические;
• среды выполнения.

Это – основная классификация сбоев в приложениях и операционных системах. Логические, синтаксические и «среды выполнения» встречаются в разработке чаще остальных. На них будет сделан основной акцент.

Ошибки синтаксиса

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

Синтаксические ошибки – ошибки синтаксиса, правил языка. Вот пример в Паскале:

Код написан неверно. Согласно действующим синтаксическим нормам, в Pascal в первой строчке нужно в конце поставить точку с запятой.

Логические

Тут стоит выделить обычные и арифметические типы. Вторые возникают, когда программе при работе необходимо вычислить много переменных, но на каком-то этапе расчетов возникают неполадки или нечто непредвиденное. Пример – получение в результатах «бесконечности».

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

Выше – пример логической ошибки в программе. Тут:

1. Происходит сравнение значения i с 15.
2. На экран выводится сообщение, если I = 15.
3. В заданном цикле i не будет равно 15. Связано это с диапазоном значений – от 1 до 10.

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

Время выполнения

Run-time сбои – это ошибка времени выполнения программы. Встречается даже когда исходный код лишен логических и синтаксических ошибок. Связаны такие неполадки с ходом выполнения программного продукта. Пример – в процессе функционирования ПО был удален файл, считываемый программой. Если игнорировать подобные неполадки, можно столкнуться с аварийным завершением работы контента.

Самый распространенный пример в данной категории – это неожиданное деление на ноль. Предложенный фрагмент кода с точки зрения синтаксиса и логики написан грамотно. Но, если клиент наберет 0, произойдет сбой системы.

Компиляционный тип

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

Наличие подобных неполадок делает бета-тестирование невозможным. Компиляционные ошибки устраняются при разработке-отладке.

Ресурсные

Ресурсный тип ошибок – это сбои вроде «переполнение буфера» или «нехватка памяти». Тесно связаны с «железом» устройства. Могут быть вызваны действиями пользователя. Пример – запуск «свежих» игр на стареньких компьютерах.

Исправить ситуацию помогают основательные работы над исходным кодом. А именно – полное переписывание программы или «проблемного» фрагмента.

Взаимодействие

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

Исключения и как избежать багов

Исключение – событие, при возникновении которых начинается «неправильное» поведение программы. Механизм, необходимый для стабилизации обработки неполадок независимо от типа ПО, платформ и иных условий. Помогают разрабатывать единые концепции ответа на баги со стороны операционной системы или контента.

Исключения бывают:

1. Программными. Они генерируются приложением или ОС.
2. Аппаратными. Создаются процессором. Пример – обращение к невыделенной памяти.

Исключения нужны для охвата критических багов. Избежать неполадок помогут отладчики на этапе разработки. А еще – своевременное поэтапное тестирование программы.

P. S. Большой выбор курсов по тестированию есть и в Otus. Присутствуют варианты как для продвинутых, так и для начинающих пользователей.

Перейти к содержанию