Хрупкость программного обеспечения

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

Причины[править]

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

Хрупкость программного обеспечения может быть вызвана алгоритмами, которые плохо работают для всего спектра входных данных. Хорошим примером является алгоритм, который позволяет выполнить деление на ноль, или уравнение подгонки кривой , которое используется для экстраполяции за пределы данных, к которым оно было приспособлено. Другой причиной хрупкости является использование структур данных, которые ограничивают значения. Это обычно наблюдалось в конце 1990-х годов, когда люди поняли, что их программное обеспечение имеет место только для записи 2-значного года; это привело к внезапному обновлению огромного количества хрупкого программного обеспечения до 2000 года. Еще одна наиболее часто встречающаяся форма хрупкости - это графические пользовательские интерфейсы, которые делают неверные предположения. Например, пользователь может работать на дисплее с низким разрешением, и программное обеспечение откроет окно, слишком большое, чтобы соответствовать дисплею. Другая распространенная проблема проявляется, когда пользователь использует цветовую схему, отличную от стандартной, в результате чего текст отображается в том же цвете, что и фон, или пользователь использует шрифт, отличный от стандартного, который не помещается в разрешенное пространство и отрезает инструкции и надписи.

Источник[править]

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

Некоторые примеры и причины хрупкости программного обеспечения:

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