Сколько ошибок слишком много?

Я иногда разочаровываюсь в своей работе из-за воспринимаемой ошибкой моего кода. Но я думаю, что больше не производю, и, вероятно, меньше, чем большинство людей. Например, я только что закончил разработку проекта, который занял 3 месяца, когда тестеры обнаружили около 10 настоящих ошибок и, возможно, 10 других изменений без ошибок (т.е. Я могу изменить цвет этой кнопки). Я думаю, что это неплохо после 3 месяцев развития, но другие люди смотрят на меня, как будто я только что проверил в самом большом количестве мусора. Как вы думаете?

Изменить: добавлю дополнительную информацию.

В конце я не просто проверял все. Я постоянно проверял и проводил собственное тестирование, когда я шел. Очевидно, я нашел и исправил множество ошибок, когда я пошел.
Первый раунд тестирования внешними людьми состоялся через два месяца. Большинство ошибок были в областях, которые, как я знал, имели проблемы и не тестировались полностью сами, но поскольку программное обеспечение все еще "находится в разработке"
Второй раунд тестирования проходил через 3 месяца, и, как и первая версия, в областях, в которых я не был настолько внимателен, хотя я не думаю, что это было так много проблем.
Большинство ошибок были в довольно видимых частях приложения, поэтому, возможно, это ухудшило ситуацию. Эти части, пока они видны, не были действительно целостными или использовались, что часто пользователем. На самом деле некоторые из запросов были приостановлены как несущественные.

Ответ 1

Один волос в супе слишком много, а в голове слишком мало. Все зависит от

Ответ 2

Число "внешних" ошибок для программиста на 1 000 строк кода (KLOC) является константой. Показатель варьируется от 3-4 для очень хороших программистов до 10 для средних программистов до "лотов".

Это означает: для каждых 1000 строк кода вы обнаружите, что многие "ошибки" (от глупых опечаток в строке до полного f *** кода в методе до катастрофического дизайна, что приводит к полной перезаписи).

Обратите внимание, что мы обычно делаем намного больше ошибок, но чем лучше получается программист, тем больше ошибок они обнаруживают до того, как код покидает свой стол (отсюда "внешние" ошибки → ошибки, которые другие люди находят). Кроме того, хорошие программисты будут иметь тенденцию делать несколько катастрофических ошибок и более "глупых" ошибок (которые легко исправить, но более смущающие: "Как я мог наблюдать это?" ).

Интересно, что количество ошибок является постоянным по отношению к языку, поэтому очень хорошие программисты на ассемблере делают 4 ошибки /KLOC, поэтому очень хорошие программисты на C делают 4 ошибки /KLOC, поэтому очень хорошие программисты на Java делают 4 ошибки /KLOC, и др.

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

Теперь на вопрос "когда слишком много ошибок?" Сделать шаг назад. По мере развития у вас будет много ошибок (большинство из них внутренние). У конечного продукта будет меньше ошибок, потому что большинство будет найдено во время разработки. Это означает, что это важно, когда вы смотрите. Это также означает, что количество ошибок само по себе не является хорошим показателем "здоровья".

Чтобы понять, когда ваш проект начинает болеть, вы должны как-то подсчитать свои ошибки (сколько строк я написал, сколько ошибок я нашел, сколько я мог исправить). Это много усилий и часто имеет отрицательную рентабельность инвестиций. Эти вещи трудно измерить, и требуется время, чтобы записать ошибки, которые вы найдете где-то, и это все отвлекает вас от вашей цели: Напишите код.

Мой подход заключается в том, чтобы начать писать больше тестов, когда появляется больше ошибок. Почувствованное количество "багги" (или беспокойство на моей стороне) является хорошим показателем того, что-то не так. Поэтому, если вы чувствуете, что создаете две новые ошибки с каждой строкой кода, это верный сигнал, что что-то нужно сделать. Если вы пишете много строк кода, и все встает на свои места, как по волшебству, то зачем тратить время на измерение того, как хорошо все идет?

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

[EDIT] Некоторые ссылки с информацией, где я получил свои номера:

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

Что касается проектов с коротким проверочным циклом, я считаю, что каждая ошибка слишком много. Всегда исправляйте ошибки перед написанием нового кода (# 5 в Joel Test).

Ответ 6

Относительно говоря, 10 ошибок в течение 3 месяцев кода могут быть очень хорошими. Если бы я сделал проект, который занял 3 месяца, я бы не удивился, если бы в нем было найдено 200 ошибок.

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

Ответ 7

Восприятие качества программного продукта может сильно различаться между программистом и пользователем. Это отчасти потому, что человек видит это изнутри, а другой видит его снаружи.

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

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

Смотрите также: количество WTF в минуту.

Ответ 8

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

Если дело в том, что сумма net и сумма налога в счете-фактуре не соответствуют валовой, тогда вам следует беспокоиться. Если это случай двух человек, которые редактируют один и тот же счет в то же самое время, что-то странное случается 1 раз в 5, тогда вы можете быть менее обеспокоены.

Ответ 9

В качестве приблизительной метрики трехмесячный проект составляет 25 000-50 000 строк кода, поэтому вам следует ожидать найти 10 ошибок на 1000 строк в ходе собственного тестирования, поэтому типичным будет 100-500 ошибок.

Если ваш собственный тестовый отдел сообщает об ошибках в 0,2 балла /1000 строк за то, что звучит как сольное усилие (кто-нибудь прокомментировал это?), то либо вы очень хороши, либо они недостаточно хороши,

Ответ 10

Вы можете обратиться к функциональным правилам безопасности, таким как ISO26262 (http://en.wikipedia.org/wiki/ISO_26262) или IEC 61508. Потому что имеет значение, является ли следствием ошибки/ошибки является потеря человеческой жизни - или только холодный кофе.

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

Количество сбоев также связано со сложностью. (например: http://www.cas.mcmaster.ca/~lawford/papers/SeparatingSafetyAndControl.pdf, ch 4.4)

DFSS (дизайн для шести сигм) и аксиоматический дизайн - это инженерные концепции для сокращения сбоев в продуктах.

Ответ 11

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

http://amartester.blogspot.com/2007/04/bugs-per-lines-of-code.html

Ответ 12

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

Ответ 13

Я просто перфекционист, но я, как правило, просматриваю все и проверяю его на то, что, как я знаю, использовал, чтобы сломать его (и все, что я знаю, когда-то работало), чтобы убедиться, что мой новый код исправляет мои старые проблемы (и doesn 't "исправить" любые старые решения). У меня плохая привычка зависеть от исправления ошибки, а не добавления чего-то, что мне нужно добавить. Это, наверное, хорошо, но кто знает?

Я предполагаю, что вы тратите 3 месяца на запись и нахождение ошибок, и что ваш окончательный результат после 3 месяцев работы имел 10 ошибок. Все в порядке. Я бы не сказал, что это хорошо или плохо - это зависит от того, сколько из ваших 3 месяцев вы тратите на исправление ошибок. Если вы просто выплевываете код в течение 3 месяцев, а затем проверяете его, 1) вы делаете это неправильно, и 2) это довольно удивительно. Если, однако, вы проводите эти 3 месяца, проверяя свой код и убедившись, что он работает, и я подозреваю, что вы это делаете, я мог бы предложить потратить всего лишь немного времени, проверяя его, чтобы отсеять по меньшей мере 5 из этих 10 ошибок. Если они являются угловыми случаями, которые происходят только с неправильной, необычной комбинацией входных данных, то это несколько простительно, но если они довольно распространены, вы должны подумать о том, чтобы немного времени уделять их отслеживанию.

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

Ответ 14

Если другие воспринимают ваш код как багги, он слишком глючит. Восприятие важнее реальности. Неважно, если у вас только 1 ошибка. Чтобы восприниматься как ошибка (даже если это была всего лишь 1 ошибка), это означало бы, что вы создали некоторые довольно видимые ошибки.

Как и другие, мы не можем сказать вам о вашей ситуации, если 10 ошибок слишком много, потому что нам нужно знать тип ошибок. Я бы предложил вам посмотреть на типы ошибок, которые вы создаете, чтобы увидеть, есть ли какие-либо сходства. Вы не понимали требований? Было ли много ошибок? Логические ошибки? и т.д. Затем оцените, являются ли эти ошибки ошибками, которые вы должны были поймать. Если да, определите способ не вводить эти типы ошибок в следующий раз.

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

Кто-то отметил, что 3 или 4 ошибки на kSLOC являются средними, что кажется слишком высоким, но я был в проектах, которые были хуже (так, может быть, и нет). Однако у тех же проектов не было очень хороших разработчиков. IMO, если это не ошибка или неверная интерпретация, ошибка не должна быть в коде. Если это так, вы не выполняете свою работу должным образом. Так что, может быть, 10 слишком много, может быть, нет, это зависит от типов ошибок, которые вы создаете.

Ответ 15

С точки зрения перфекционистов, 1 ошибка слишком много. Насколько релевантный взгляд на перфекционист оказывается очень субъективным.

Если это сжатый код, как можно меньше ошибок, так как это увеличит продажи (вы не будете из уст в уста говорить о своей ошибкой).

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

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

Кроме того, были ли эти 10 ошибок, когда тестировщики тестировали предварительный код? Если это так, то это очень хорошо (последний проект, над которым я работал, я иногда управлял 10 ошибками за день... но потом исправил их на следующий день, потому что это были мелочи, которые я просто не считал полностью:)). Но ошибка подсчитывается до того, как система перейдет в живую, вряд ли подсчитайте (если она не пройдет за неделю до выпуска, и у вас есть проблемы, соответствующие исходным требованиям)

Ответ 16

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

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

Ответ 17

Сложно сказать, сколько ошибок много. Я думаю, что метрики с ошибками X на Y строк кода являются такими же ошибочными, как и любая метрика, использующая строки кода (например, измерение производительности).

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

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

Ответ 18

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

Я лично считаю, что это положительное поведение для разработчиков, чтобы найти как можно больше ошибок в своем программном обеспечении. Конечно, я говорю о профессиональных и компетентных разработчиках - не стоит оставлять в них ошибки, чтобы таким образом заработать очки-коричневые. Но если я получаю 1 баг за тот же код, что еще один разработчик обнаруживает 10 ошибок, я бы не стал смотреть в этом разработчике, особенно если мы рассматриваем "большие" проекты

Ответ 19

Количество ошибок менее важно, чем время, необходимое для их обнаружения. Чем дольше требуется определить ошибку, тем дороже будет отслеживать и исправлять, и, скорее всего, исправление этой ошибки может сломать что-то еще. Тест на раннем этапе и тестирование часто (TEATO?) - лучший подход.

Ответ 20

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

S = серьезность возникновения дефекта (большое влияние на программное обеспечение: сбой, потеря данных...)
O = рейтинг появления (как часто происходит дефект)
Оценка обнаружения (здесь не очень полезно: модульные тесты?)

Насколько эффективен "важный" дефект, может быть RPN = S x O.

Нет программного обеспечения без ошибок. Сам разработчик никогда не лучший тестер. Вот почему шаги QA всегда необходимы. Тестеров, которые вас обвиняют, должны быть рады обнаружить дефекты до того, как клиент сделал это. Конечно, есть еще плохое программирование или плохой дизайн, но также плохое тестирование... Мир не идеален, но мы должны справляться со всеми этими вещами соответствующим образом. Использование даже более сложных процессов разработки программного обеспечения, если разрабатываемое программное обеспечение используется, например, в медицинской или военной среде. Если были использованы все инструменты для обеспечения качества программного обеспечения: дизайн FMEA, проверка статического кода, обзоры одноранговых кодов, модульное тестирование, тестирование компонентов, системные тесты,... никто не должен быть обвинен.