>Он хорошо продумал ответ. Проверить практически невозможно.

Я ваще не думал. Думать надо в другом месте. А

> Мои баги вообще крайне редко находятся кем-либо, кроме меня - далеко не каждый месяц. Где я могу получить свой пирожок?

Могу предложить значек «Почетный производитель никем не используемого ПО» :-)) [шутка]

> Я ваще не думал. Думать надо в другом месте. А

В сортире, что ли? А? :)

>>Оно у заказчика есть?

По моему это проблема уже другого уровня, вы не находите?

Нет, того же. Безбаговое ПО возможно, но пользователи не готовы его ждать и/или за него платить.

> Могу предложить значек «Почетный производитель никем не используемого ПО» :-)) [шутка]

В любой шутке есть доля шутки. Ты привел отличный пример этого правила.

Теоретически возможно, вне всякого сомнения.

На практике кто-то к этому стремится, но большинство плюёт на эту возможность - «лишь бы впарить».

Ну и - Ваша правда - если пользователь жаждет «без багов», то ему придётся либо «ждать», либо «платить».

Поскольку софт без багов писать никто не умеет, то 1 (только не в первую очередь).

7) Код должен быть под свободной лицензией, как есть, чтоб не ждали качества.

по голове себе постучи

Ты тестер?

А какая лицензия гарантирует качество?

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

ну я вроде никогда этого не скрывал

Тогда понятно откуда такой баттхерт :)

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

Вот еще одна точка зрения:

1. баг - это признанная ошибка.

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

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

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

5. иногда, это очень полезная точка зрения. иногда - нет.

> 1. баг - это признанная ошибка.

А если не признанная? Например не могут воспроизвести?

> багнутое и дырявое мало кто захочет покупать

Вы не поверите :-(

Вот факторы:
1) у соседа Васи такое же, и Вася все еще жив
2) все покупают же
3) реклама зато красивая
4) разработчики не красноглазые

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

А «бесплатность» в бизнес-секторе в качестве аргумента (массовый рынок в этой стране среди обычных «домашних» граждан крайне малоразвит) — это вообще красный сигнал. Это обычно сигнализирует либо о скрытых затратах, либо о безнадежном качестве, либо о том и другом сразу.

а коты не ушастые разве ? :)

/me пробубнел что-то с использованием слов «матчать» «Дейкстра» «сукины дети» «пафосные идиоты» «формальная верификация» и набора труднопроизносимых фразеологизмов из польского и чешского и свалил спать

> 1. баг - это признанная ошибка.

О-о, вот это требует уточнения, иначе...

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

«Плавающие» нерегулярно вылезающие баги тоже трудно назвать «признанными».

>Выберите вариант, который вам нравится больше:

Опрос гавно. Проблема в модели разработки. И «extreme programmin». Как разработали, так и работает.

А надо как разрабатывать по науке. С мат. доказательством. Говорити: Не нравится? Медленно?

Ну так жрите баги и не жалуйтесь. Все за них ответственно. И тестеры, и программисты, и менеджеры, и совет директоров, и акционеры

3). Если всё же баг - то см. п.2.

Есть вещи, которые нельзя доказать. Или что-то формально вроде и доказано, да вот на кошках тесты валятся, а в продакшене вааще пипец.

Так как тесты должны быть и так, и так, я выбираю тесты. :-)

>Есть вещи, которые нельзя доказать. Или что-то формально вроде и доказано, да вот на кошках тесты валятся, а в продакшене вааще пипец.

Есть. Но их несколько меньше, чем вообщ ничего.

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

> Есть. Но их несколько меньше, чем вообщ ничего.

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

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

Я знаю, как это тестировать, но я не знаю, как это доказать. Просвети меня, некомпетентного.

> Если что-то формально доказано, то не может валится на тестах и иметь одновременно валидный код. Есть доказательство, есть утвержденная тестовая последовательность. Все.

Для доказательства может быть взят замес из неверных исходных предпосылок. Тесты могут проверить валидность того и другого, и без всякого доказательства показать, что девелоперы дураки, а вот хреновым доказательством можно будет подтереться, даже если на него угробили два месяца.

http://thedailywtf.com/Articles/The-Proven-Fix.aspx

рекомендованное чтение всем младшим специалистам CS.

>Я знаю, как это тестировать, но я не знаю, как это доказать. Просвети меня, некомпетентного.

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

И это проблемы заказчика ПО.

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

>http://thedailywtf.com/Articles/The-Proven-Fix.aspx

рекомендованное чтение всем младшим специалистам CS.

Что я собсно и говорил. О «формальных» алгоритмах и доказательствах никто слышать не хочет, ибо непонятно.

Э, не. Мне ты как раз напоминаешь того индуса:

— Но я же доказал!
— Смотри, вот живая машина: оно _НЕ_РАБОТАЕТ_.
— Но я доказал!!!!11111FFFFUUUUUU!!!!1111

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

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

И это проблемы заказчика ПО.

Доказательство корректности ПО - «проблема заказчика ПО»?!?!?

Это как это?!?

Может, я чего не понял или неправильно понял?

А, так Вы, должно быть имели в виду «проблема» в смысле «беда заказчика ПО», а не в смысле «задача заказчика ПО»?

Тогда, сорри, я поторопился...

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

Нет, товарищ Дикий. Я знаю, как написать софтины, которые обозначил. Я знаю, как эмпирически определить их годность, и что при этом должно быть в ТЗ и в договоре. Я не знаю, что в них нужно доказывать _формально_, может, ты просветишь?

Сходи в супермаркет, в конце концов. Какие формальные, математические доказательства должен приводить разработчик POS?

— В супермаркете А мы поставили ПО от дяди Васи, в супермаркете Б мы поставили ПО дяди Пети, в супермаркете Г мы поставили ПО от фирмы «2С». За трое суток супермаркет А обслужил в среднем 15344 человек в сутки, Б обслужил 18465 чел/сутки, а супермаркет Г — ни одного.

Причина такого результата у супермаркета Г не только в том, что мы его поставили среди болот за старым минным полем, но и в том, что ПО от фирмы «2С» тормознутое говно, и если бы супермаркет стоял в доступном для покупателей месте, он все равно никого бы не обслужил.

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

После того, как дядя Вася вылечит свой сфинктер, для него вряд ли будет новостью, что победителем в нашем рейтинге стал дядя Петя, который не только пишет качественное ПО, но и дает хорошие откаты менеджерам отдела закупок супермаркета Б! Покупайте кассовое ПО у дяди Пети!

Так, что ли?

>Нет, товарищ Дикий. Я знаю, как написать софтины, которые обозначил.

я не говорил, что ты не знаешь как _писать_.

Я знаю, как эмпирически определить их годность, и что при этом должно быть в ТЗ и в договоре. Я не знаю, что в них нужно доказывать _формально_, может, ты просветишь?

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

Формально надо определить тестовую последовательность и доказать, что прохождение ее необходимо и достаточно для безбажности софта. ну и есессно алгоритмы доказать, если таковые используются.

Для этого разбить ПО на блоки, доказать верность данной системы при соответствии блоков заданным параметрам.

Отчасти это относится к Literate Programming.

Все что я написал - это в общем-то очевидные вещи. Я не понимаю, почему ты «ощетинился».

>— Но я же доказал! — Смотри, вот живая машина: оно _НЕ_РАБОТАЕТ_. — Но я доказал!!!!11111FFFFUUUUUU!!!!1111

Значит или ошибка в доказательстве, или машина сделана не в соответствии с описанной формой.

Насчет того, что проверка доказательства - трудная вещь, да. Ну и что?

Кто сказал, что должно быть легко?

Да и тем более уже начинают развиваться системы автоматического доказательства/проверки доказательства.

>1) за баги ответственны в первую очередь тестеры, это они не нашли;

Виноваты короткие сроки, нехватка опыта, изменения в ТЗ (что вкусе с первыми двумя даёт сам знаешь что), плохие условия оплаты (в том числе и из-за второго). Но плохое тестирование - в первую очередь, имо, если руки кодера не полный круг.

>> - продавцы за несоответствие прайсов актуальному товару,

Их наказывают рублем

А кодерские фирм по-твоему так не отвечают?

Ближе к 4-му пункту.

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

Сейчас же, к сожалению, никто ни за что не отвечает. Покупаешь коммерческий продукт и у производителя перед тобой совершенно нет никакой ответственности.

А какая лицензия гарантирует качество?

Никакая, но свободная позволяет снять с себя ответственность за баги, as is же. Хочешь жуй, а хочешь блюй.

свободная позволяет снять с себя ответственность за баги, as is же.

Перечитай любую EULA — будешь удивлён.

Во всем виноват Microsoft.

:)

И все-таки я считаю, что тестеры при разработке самые главные - если бы не они - никакого софта бы не было, потому что программисты иногда не удосуживаются проверить свое творение даже на запускаемость.

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

>за баги ответственны в первую очередь тестеры, это они не нашли;

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

любой баг можно выдать за фичу :)

segfault при старте - это новая фича версии 2.2.5

настоящие программисты багов не делают;

Да, но реальные - делают. Баги также делают постановщики ТЗ.

за каждый баг - соответствующий серьёзности баги вычет из з.п. (и/или лишение премии);

Тогда средняя з/п разработчика будет как максимум -30к рублей.

всё, что угодно, если код не мой;

А если мой - то ССЗБ.

баги надо смывать кровью

Менеджеров, которые организуют процесс так, что допускаются даже тривиальные баги.

так не признанная или не могут воспроизвести? надо бы определится для начала :-)

> То, что баги невозможны при исправном (или же исключить возможность незамеченной ошибки при неисправном) оборудовании.

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

Формально надо определить тестовую последовательность и доказать, что прохождение ее необходимо и достаточно для безбажности софта

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

Все что я написал - это в общем-то очевидные вещи. Я не понимаю, почему ты «ощетинился».

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

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

полезно различать процедуру воспроизведения и процедуру признания.

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

> 2) любой баг можно выдать за фичу :)

При условии, что этот баг подробно описан в документации.

А иначе:

6) баги надо смывать кровью...

Точнее исправлять их.

4й вариант самый предпочтительный так как обычно я 5й вариант =)

>никто не гарантирует отсутствие ошибок в коде.

Ну допустим в TeX математически доказано отсутствие ошибок, правда LaTeX на этот счет уже ниасилили