По сути, нет, но вы все равно должны делать все возможное. Я объясню почему (или просто перейдите к заключению, если вам не хватает терпения)
Рассмотрим задачу столь же тривиальную, как реализация бинарного поиска. В одной очень популярной реализации была ошибка, которая оставалась незамеченной около двух десятилетий. Если двадцати строкам понадобится двадцать лет, чтобы получить широкое распространение без ошибок и даже предположительно доказано, правильно, можем ли мы ожидать, что огромная программа не будет содержать ошибок?
Сколько ошибок мы можем ожидать от огромной программы? Одно число, которое я нашел, было «10 дефектов на 1000 строк» (Code Complete 2-е издание, стр. 517 - просто использовался пример, без цитирования каких-либо данных), что дает нам от 200 000 до 300 000 ошибок в вашем программном обеспечении. К счастью, у нас есть способы улучшить качество программы. Модульное тестирование, обзоры кода и обычное ручное тестирование, как известно, уменьшают количество ошибок. Тем не менее, число все еще будет высоким.
Если бы мы могли решить 95% всех ошибок, это было бы невероятно. И все же у нас все еще будет от 10 000 до 15 000 ошибок в программном обеспечении.
К счастью, поскольку программное обеспечение широко используется (и, следовательно, широко тестируется), будут найдены ошибки. Таким образом, мы будем постепенно получать меньше ошибок. Тем не менее, меньшее количество ошибок также означает, что оставшиеся из них труднее найти - поэтому не ожидайте линейной кривой при исправлении ошибок. Последние несколько ошибок будет действительно сложно найти и могут избежать обнаружения в течение нескольких лет (при условии, что они когда-либо будут обнаружены).
Вы также, похоже, ошибочно полагаете, что если программное обеспечение не изменится, новых ошибок не появится. Если программное обеспечение зависит от сторонних библиотек, новые версии могут нарушать некоторые функции, что приводит к появлению новых ошибок, даже если код приложения остается прежним. Новые операционные системы могут также сломать приложение, которое ранее работало идеально (см. Популярный пример в Windows Vista). Учитывайте также ошибки компилятора и т. Д.
Неясно, могут ли инструменты для проверки кода действительно решить проблему с ошибками программного обеспечения. Конечно, невозможно решить проблему остановки для любой программы, но можно доказать, что программа ведет себя так, как указано ... Но что тогда? Возможно, в программе проверки есть ошибка. Может быть, в самой спецификации есть ошибка.
Ясно, что мы можем значительно сократить количество ошибок, но вряд ли мы когда-нибудь доберемся до нуля.
Потому что есть мнение, что каждое исправление, которое вы делаете, создает больше ошибок, но я не думаю, что это правда.
(выделение добавлено)
Ты прав. Это утверждение неверно. Вот пример:
int main() {
int x[10];
x[10] = 8; //Buffer overflow here
return 0;
}
Теперь давайте исправим эту ошибку:
int main() {
int x[11];
x[10] = 8; //No buffer overflow here
return 0;
}
Видеть? Мы исправили ошибку и не представили новых.
Однако, безусловно, правильно, что каждый раз, когда вы исправляете ошибку, вы рискуете создать новую, хотя этот риск можно уменьшить (например, с помощью модульного тестирования).
Допустим, что на каждые 100 ошибок, которые я исправляю, я случайно ввожу новую. Поэтому, если я исправлю 10 000 ошибок, я добавлю 100 новых ошибок. И если я исправлю эти новые ошибки, я внесу одну ошибку. Ну и что? В программе теперь на 9 999 ошибок меньше, так что, вероятно, это лучше, чем было (при условии, что новая ошибка не в 10 000 раз хуже, чем предыдущие).
Кроме того, исправление ошибки может открыть новые. Но эти ошибки также могут быть исправлены. Если вы все сделаете правильно, в конечном итоге программное обеспечение будет в лучшем состоянии, чем оно было начато.
Я был старым из нескольких ведущих программистов, что лучше не исправлять много ошибок из-за понятия, которое я упомянул в ОП.
Такое поведение небрежно. Если есть ошибка, и вы можете ее исправить. Сделай это. Конечно, вы должны сделать все возможное, чтобы предотвратить добавление новых, но если я добавлю одну маленькую ошибку на каждые 10 серьезных ошибок, которые я исправлю, это не является веской причиной, чтобы прекратить исправлять ошибки. На самом деле, это хорошая причина, чтобы продолжать исправлять ошибки .
Чем меньше ошибок вы исправите, тем меньше ошибок будет возвращаться вам в будущем
Чем меньше ошибок вы исправляете, тем больше ошибок останется в вашем программном обеспечении, раздражая ваших пользователей. Действительно, они не будут «возвращаться к вам в будущем». Они не вернутся, потому что они никогда не уходили. Понятие «вернуться» связано с регрессией. Опять же, можно снизить риск регрессий.
Некоторые ошибки не могут быть исправлены, потому что они стали настолько широко используемыми, что люди начали зависеть от них, и исправление ошибки может сломать программу для этих пользователей. Такое случается. Однако могут ли они действительно считаться ошибками в этом случае?
Менталитет « исправь ошибку, сделай ошибку» может быть связан с That Horrible Monster - кодом, который настолько нечитаем и не поддерживается, что простое прикосновение к нему порождает ошибки. Если в вашей кодовой базе есть монстр, вам может понадобиться сначала удалить его из монстра, прежде чем что-либо делать.
Наконец, если вы ужасный программист, есть риск, что все, к чему вы прикасаетесь, создает новые ошибки. Это, очевидно, заставит старших программистов нервничать. Тем не менее, говоря: «Не делай ничего. Не трогай ничего. Даже не дышите». Вероятно, это не правильный способ создать здоровую рабочую среду. Образование лучше.
Заключение:
- Программное обеспечение, которое получает множество новых функций, но не исправляет ошибки, неизбежно будет отстой.
- Программное обеспечение, которое получает умеренное количество новых функций, но исправляет свои ошибки, имеет больше шансов на использование.
- Те, кто пытается иметь немного ошибок, имеют (в среднем) меньше ошибок, чем те, кому все равно.
- Нет смысла ожидать, что программа в конечном итоге станет свободной от ошибок.
- Старшие программисты не обязательно компетентны.
- Исправьте свои ошибки.
- Принять методологии, которые улучшают качество вашего программного обеспечения.