Сколько ошибок слишком многие? [закрытый]

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

Волосы в супе - слишком многие и в голове лишь немногие. Все это зависит

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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