После аварии на Саяно-Шушенской ГЭС стало модным говорить о грядущих изменениях в положении производителей софта, которые, нехорошие такие люди, наконец-то, обязаны будут ответить за каждый баг (в самых воинствующих интерпретациях даже смыть каждый из них кровью). Это, конечно, вполне возможно... Только выиграют ли от этого пользователи?
Баги (сиречь ошибки) есть в любых программах - это, скажем так, одна из аксиом программирования. Как справедливо замечают те, кто негодует из-за отказа производителей программного обеспечения от ответственности за последствия использования их продукции, большая часть софта сегодня распространяется на условиях "AS IS" (дословный перевод на русский - "как есть"). Производители программ не гарантируют пользователю их безошибочную работу - собственно, именно это положение лежит в основе отказа от ответственности за последствия их использования.
Любимый аргумент тех, кто против такого порядка вещей, - это что производитель автоматизированной системы управления, скажем, атомной электростанцией, не гарантирует того, что в результате работы его системы станция не взлетит на воздух. "Зачем тратятся такие большие деньги на разработку или покупку программ, если они всё равно не способны правильно работать?" - любят спрашивать они. Контраргумент - червивые яблоки. "Покупая яблоки, вы не можете потребовать от их поставщика гарантии, что ни в одном из них не окажется червей", - говорят те, кто понимает, что невозможно требовать от производителей программного обеспечения полного отсутствия в нём каких бы то ни было ошибок. Не так уж важно, чья позиция вам ближе - дело в том, что требования заставить производителей программного обеспечения нести ответственность за последствия его использования относятся к разряду чего-то совершенно фантастического.
Дело здесь, в общем-то, даже не в возможных ошибках. Пользователи, которые работают, скажем так, с обычными программами, слабо представляют себе уровень надёжности программного обеспечения, обеспечивающего работу тех же электростанций, железных дорог и тому подобных объектов. Дело в том, что производитель программного обеспечения не может гарантировать правильность его использования. После каких-либо инцидентов, пусть даже и не столь трагичных, как тот, который произошёл на Саяно-Шушенской ГЭС, производителю программного обеспечения будет сложно доказать, что какой-либо сбой произошёл из-за нарушения инструкций по его использованию, даже если действия пользователя (или, правильнее сказать, оператора) тщательно протоколируются самой программой).
Сложно даже представить, насколько окажутся загруженными суды, если принцип "AS IS" перестанет действовать и пользователи, потерявшие данные в результате программного сбоя, смогут подавать иски к производителям "обидевших" их программ. Сколько пользователей, случайно удаливших собственные данные, обвинят программу в сбое?..
Как видите, единственное, чего позволит добиться отмена принципа "AS IS", - это непроизводительные траты времени и дополнительная нагрузка на судебную систему. Поэтому предложение его отмены - это просто "перекладывание с больной головы на здоровую" в самом что ни на есть явном виде.
Вадим СТАНКЕВИЧ
Версия для печати
Комментарии
Страницы
Стоимость труда определяется спросом - как и любого другого товара - СПРОСОМ И ПРЕДЛОЖЕНИЕМ.
Если простой НЕ программист выпускает автомобили, которые можно условно назвать автомобилями или которые НИКТО не покупает - то этого простого НЕ программиста только жаль.
Да, ЕСТЬ места, где самородки с фунт весом ЕСТЬ. :)
Во. Надо бы, наверное, ознакомиться и читателей ознакомить, что ЕСТЬ СОФТ БЕЗ БАГОВ! - Я о таком лет 5-7 назад слыхал.
"А ты едал?" -- "Не едал, но слыхал, что кто-то видал, как барин едал." (Любимая присказка моей бабушки.)
На самом деле существуют методологии, которые позволяют снизить количество багов или даже исключить их появление. Например, Agile и Test Driven Development, когда сначала пишутся тесты для кода, который будет написан впоследствии. Подобные разработки действительно очень качественные и с гарантией, но и стоят дороже, поскольку программист пишет в 2 раза больше кода. Хороший менеджер должен чаще использовать подобные подходы для своих команд разработчиков, даже если нужно каждому отдельному программисту это разжевать. Но факт в том, что сейчас даже солидные произодители ПО экономят на ресурсах и преследуют лишь скорость создания ПО (все же конкуренция), поэтому у программистов нет стимула совершенствоваться, ведь их просто накажут, если они будут писать в 2 раза медленнее, но с высоким качеством через TDD.
По любому - барин то что-то ЕДАЛ, и это что-то было ОТЛИЧНО от того, что едим МЫ. - Не так ли, mike?! ;-)
Нет, речь не об этих методиках вовсе идет. - Эти методики не позволяют довести число багов до нуля! - Точнее, следуя этим методикам нельзя сказать, что у меня багов нет вовсе. - Все что можно сказать, это то, что при разработке я использую методику Agile и Test Driven Development и ... все. - Но о числе оставшихся багов в ПО, в этом случае, нельзя сказать НИЧЕГО конкретного.
ПО метро во Франции (а сейчас построили и в Саудовской Аравии - полностью автоматическое метро) разрабатывается СОВСЕМ по ДРУГИМ методикам.
Если весь функционал покрыт тестами (несколько тысяч), то проект не сбилдится, если хоть один тест (Unit тест) упадет. А тесты проверят все - от входных данных до времени выполнения куска кода. Поэтому в данном случае возможно полное отсутствие багов(для небольших приложений). Это как пример формализации задачи уменьшения багов, причем вполне успешной. Если задачу можно формализовать, то значит и можно измерить и точность результатов.
Страницы