После аварии на Саяно-Шушенской ГЭС стало модным говорить о грядущих изменениях в положении производителей софта, которые, нехорошие такие люди, наконец-то, обязаны будут ответить за каждый баг (в самых воинствующих интерпретациях даже смыть каждый из них кровью). Это, конечно, вполне возможно... Только выиграют ли от этого пользователи?
Баги (сиречь ошибки) есть в любых программах - это, скажем так, одна из аксиом программирования. Как справедливо замечают те, кто негодует из-за отказа производителей программного обеспечения от ответственности за последствия использования их продукции, большая часть софта сегодня распространяется на условиях "AS IS" (дословный перевод на русский - "как есть"). Производители программ не гарантируют пользователю их безошибочную работу - собственно, именно это положение лежит в основе отказа от ответственности за последствия их использования.
Любимый аргумент тех, кто против такого порядка вещей, - это что производитель автоматизированной системы управления, скажем, атомной электростанцией, не гарантирует того, что в результате работы его системы станция не взлетит на воздух. "Зачем тратятся такие большие деньги на разработку или покупку программ, если они всё равно не способны правильно работать?" - любят спрашивать они. Контраргумент - червивые яблоки. "Покупая яблоки, вы не можете потребовать от их поставщика гарантии, что ни в одном из них не окажется червей", - говорят те, кто понимает, что невозможно требовать от производителей программного обеспечения полного отсутствия в нём каких бы то ни было ошибок. Не так уж важно, чья позиция вам ближе - дело в том, что требования заставить производителей программного обеспечения нести ответственность за последствия его использования относятся к разряду чего-то совершенно фантастического.
Дело здесь, в общем-то, даже не в возможных ошибках. Пользователи, которые работают, скажем так, с обычными программами, слабо представляют себе уровень надёжности программного обеспечения, обеспечивающего работу тех же электростанций, железных дорог и тому подобных объектов. Дело в том, что производитель программного обеспечения не может гарантировать правильность его использования. После каких-либо инцидентов, пусть даже и не столь трагичных, как тот, который произошёл на Саяно-Шушенской ГЭС, производителю программного обеспечения будет сложно доказать, что какой-либо сбой произошёл из-за нарушения инструкций по его использованию, даже если действия пользователя (или, правильнее сказать, оператора) тщательно протоколируются самой программой).
Сложно даже представить, насколько окажутся загруженными суды, если принцип "AS IS" перестанет действовать и пользователи, потерявшие данные в результате программного сбоя, смогут подавать иски к производителям "обидевших" их программ. Сколько пользователей, случайно удаливших собственные данные, обвинят программу в сбое?..
Как видите, единственное, чего позволит добиться отмена принципа "AS IS", - это непроизводительные траты времени и дополнительная нагрузка на судебную систему. Поэтому предложение его отмены - это просто "перекладывание с больной головы на здоровую" в самом что ни на есть явном виде.
Вадим СТАНКЕВИЧ
Комментарии
Страницы
Это верно.
>А тесты проверят все - от входных данных до времени выполнения куска кода.
Это НЕ верно. Тесты НЕ могут проверить ВСЕ! - Помнится мне у Exсel был баг - он с некоторым числом (и это число не нуль) не мог корректно производить арифметическую операцию - но не будешь же ВСЕ числа прогонять через тесты?
Типа такого: "Пару дней назад в одной из программ пакета Microsoft Offece 2007 (а именно отличился всеми любимый без сарказма Excel 2007) была найдена ошибка, проявляющаяся в неправильном отображении числа 65535. Во всяком случае, официальное объяснение Microsoft в своём блоге дала именно такое - некорректное отображение. И пару доказательств, мол если ввести формулу =77.1*850, то результат будет вывведен как 100000. Однако если рядом ввести =E1*2, то результат окажется верным - 131070.
Чего-то меня переклинило проверять столь святых людей, как работников Микрософта. В общем я проверил на 4 арифметических действия, этого хватила чтобы понять, что ошибка веселее чем кажется. На скриншотах видно - первый скрин снят с данных, второй с формул. В том месте, где происходит сложение, если результат "отображается неверно, но в памяти он верен", итого всё равно выходит боком."
Верно, что можно сказать, что в этом случае багов станет МЕНЬШЕ! - Но ведь НЕИЗВЕСТНО СКОЛЬКО ИХ ОСТАЛОСЬ ТО?! -
О том, сколько же багов осталось нельзя сказать, как бы ты не покрывал свой код и сколько бы тестов не написал!!!
12 сентября 2009 года, 23:13
Стоимость труда определяется спросом - как и любого другого товара - СПРОСОМ И ПРЕДЛОЖЕНИЕМ.
Если вы делаете говно, опираясь на завышенный спрос - скоро вас вышибут из бизнеса
Если простой НЕ программист выпускает автомобили, которые можно условно назвать автомобилями или которые НИКТО не покупает - то этого простого НЕ программиста только жаль.
Вы не логик -- а демагог! Слесарь не виноват в проблемах автомобильного завода. А то, что вам его жаль, -- ну, если ВАМ проломят башку на улице, вас тоже будет жаль... И где тут конструктив? Тупая констатация...А еще логик!
Типичное заблуждение: путаем стоимость труда и цену. Стоимость труда определяется прежде всего затратами времени, не говоря уже о стоимости оснастки и квалификации разработчика,
хехе! Учи основы экономики, "НЕ программист".
А если РЫНКА нет - как уже ДАВНО производят типа ЛАДА типа "авто"?!
Но и покупатель НЕ виноват, что он НЕ хочет приобретать "нечто", что выпускает ЭТОТ НЕВИНОВНЫЙ слесарь!
Хорошо - ВЕЛИЧИНА ЗАРПЛАТЫ ОПРЕДЕЛЯЕТСЯ СПРОСОМ И ПРЕДЛОЖЕНИЕМ НА РЫНКЕ ТРУДА!
пойдет? ;-)
Ну пока я, простой рабочий с вазовского конвейера, оказался без работы, то на вынужденном досуге опишу завод. Как мы дошли до такой жизни. Текст сырой и сумбурный. Так, что терпите."
http://community.livejournal.com/rusrep/31739.html
Страницы