Что вы считаете основной причиной дефектов программного обеспечения (и как их минимизировать) [закрыто]

Я определяю дефект , как:

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

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

Основной причиной дефектов программного обеспечения является интерпретация.

Интерпретация клиентом функции отличается от интерпретации дизайнера.

Дизайнерская интерпретация отличается от интерпретации программиста.

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

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

Я считаю, что основной причиной дефектов программного обеспечения являются программисты.

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

Частично это происходит из-за нежелания изучать / понимать терминологию конечного пользователя, что вызывает недоразумения.

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

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

Основной причиной дефектов является плохое управление ;)

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

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

Плохое управление .

(отказ от ответственности: я должен нанимать и управлять разработчиками)

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

Большинство методов разработки, которые я изучаю, сводятся к сокращению N, потому что сложность программы, по крайней мере O(N^2)и возможно O(k^N). Определение Nоставлено в качестве упражнения для читателя, но я думаю о таких вещах, как цикломатическая сложность. Инкапсуляция логики и данных приводит к уменьшению N путем разделения проблемы.

Невозможность думать обо всем.

Быть неполным

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

Социальный этикет. Социально недопустимо называть кого-то недееспособным.

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

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

Errare humanum est

График Давление определенно является сильным источником.

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

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

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

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

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

Написание кода, который молча терпит неудачу, против кода, который сообщает обо всех ошибках.

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

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

Основной причиной дефектов программного обеспечения является написание кода.

Пишите меньше кода, и у вас будет меньше ошибок ;-)

На одном уровне управление. Но это не только PHB. Это управление самим кодом, который может отражать или не отражать корпоративное управление.

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