Кривая ванны относится к современному программному обеспечению? [закрытый]
Лично мне нравится делать это так:
- создать задание cron, которое выполняется очень часто, скажем, раз в минуту
- Я использую библиотеку ruby для планирования, которое позволяет Я устанавливаю исполнения так, как хочу, и они хорошо написаны в коде, что, по крайней мере, на мой взгляд, делает их более удобными, чем изменение заданий cron на сервере. Лично я использую эту библиотеку (есть из чего выбирать).
Если вы находитесь на бесплатном уровне Heroku, я не уверен, что он позволит вам выполнять cron очень часто, но, тем не менее, вы можете использовать другие сервисы, которые могут выполнять код в любое время.
[ 111] Например, если вы размещаете свой код на GitLab, в него уже встроен планировщик, так как вы можете его использовать.
5 ответов
Краткий ответ - «да». Длинный ответ заключается в том, что распределение ванны не очень хорошая модель из-за отсутствия преемственности в работе сбоев. Скажем, например, что входное значение 42 вызывает ошибку деления на ноль; тогда распределение этих отказов будет точно распределением 42 значений на входе. Это не похоже на аппаратное обеспечение, как вы говорите: программное обеспечение не терпит неудачу с течением времени, оно терпит неудачу, когда оно неправильно.
Возможно, вы здесь неправильно используете слова: вы имеете в виду дефект а не сбой . Ошибка является одним из случаев неправильного поведения; дефект - недостаток в реализации, «ошибка».
Появление дефектов в программном обеспечении имеет тенденцию распространяться по типу ванны, но на самом деле оно далеко не так чисто, как ваша картина: ошибки, как правило, наблюдаются рано и сужаются, а затем появляются патчи и новые выпуски, с общей тенденцией к повышению, начиная дальше в жизни программного обеспечения. Однако даже это требует тщательного определения, поскольку вы действительно говорите о дефектах, наблюдаемых в единицу времени.
Теперь, сказав, что современная практика SE имеет тенденцию изменять фактические показатели, но не распределение наблюдаемых дефектов во времени. «Современное» здесь также заслуживает небольшого определения: программное обеспечение Space Shuttle HAL имеет очень низкий уровень дефектов, используя методы SE, которые были «современными» 20 лет назад: строгая спецификация, структурированное программирование, строгий анализ, контроль и тестирование версий OCD. Экстремальное программирование имеет тенденцию к низким показателям «дефектов», но многие из вещей, которые более традиционные методы назвали бы «дефектами», XP называет «пользовательским вводом» - поскольку нет точного и строгого определения того, что он должен делать , «Дефект» - это просто другая история.
Были проведены достойные исследования, чтобы показать, что XP / TDD действительно приводят к низкой частоте появления дефектов, но я был бы очень удивлен, если бы распределение дефектов / единичное время отличалось.
Кривая ванны - это действительно дескриптор аппаратных сбоев (и, к тому же, хорошего), а не программного обеспечения.
Однако с программным обеспечением происходит нечто подобное. Вообще говоря, в большинстве программных производств наша способность создавать сложности продолжала немного опережать нашу способность справляться с ней - так как в работе есть какой-то принцип Питера, где программные системы (в совокупности) усложняются, пока не становятся неуправляемыми, и тогда оставайся там. Поэтому, хотя сегодня мы гораздо лучше справляемся с некоторыми системными проблемами 1990-х годов, чем были тогда, мы не намного лучше справлялись с системными проблемами 00-х годов. Такова жизнь.
Но я не думаю, что это похоже на ванну.
Не совсем, большинство ошибок найдено во время первоначального развертывания программного обеспечения. После этого это обычно постепенный набор ошибок, в основном вызванных изменениями в коде или добавлением новых функций. Ничего подобного первоначальному выпуску кода. По мере того, как разработчики, создавшие оригинальный продукт, вымирают, а обновления прекращаются, ошибки также прекращаются.
Я думаю, что многое зависит от того, насколько хорошо оно поддерживается. У меня есть одно большое приложение с графическим интерфейсом, где я практически единственный программист, который поддерживает его, и частота его дефектов неуклонно снижается на протяжении многих лет, и я не ожидаю, что оно будет расти в будущем.
Однако, если бы я позволил младшему программисту поддерживать его, я бы не чувствовал себя так же, поскольку у программиста по сопровождению есть большой соблазн написать «достаточно хорошее» исправление, а не «правильное» исправление. Я не могу винить его полностью, он, вероятно, не знает код, который сделал оригинальный программист.
Что касается правой стороны ванны, если вы учитываете внешние факторы, такие как операционные системы, то может быть некоторая корреляция, как я У нас было несколько приложений, которые сломались в более новых версиях Windows, обычно не по вине приложения. Но это относительно небольшое число.
Я думаю, что в графике есть некоторая (маленькая) правда. После первого или двух первых выпусков вы вводите новые функциональные возможности и новые ошибки, а также исправления ошибок к предыдущим ошибкам, поэтому я думаю, что вы получаете постоянный поток новых ошибок. Но через некоторое время кодовая база становится хрупкой и трудной в обслуживании, поэтому я считаю, что поток новых ошибок резко возрастает. Именно тогда, наконец (надеюсь), вы сможете убедить своих боссов прекратить исправления и начать реинжиниринг.