Ответственность программистов за баги

> Суть не в этом. Вот только тестирование отдельных партий продукции не гарантирует отсутствие брака в других партиях а вот валидация процесса гарантирует с очень хорошим результатом.

На первых этапах нужно проверить, что применение процесса приносит валидный результат. Если результат неудовлетворителен — корректировать процесс. Когда выхлоп становится таким, какого хотелось, тогда валидировать собственно процесс и прямоту рук. Ты прав, что все время валидировать каждую единицу продукции нельзя, но и когда производство только налаживается, и продукт сам новый, надо смотреть в оба.

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

>...CMMI

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

Помимо GMP есть еще и GLP который как раз валидирует процесс иследования/разработки, правда он не такой распространенный, GMP в ЕС и ЕМНИП США закреплен на законодательном уровне из-за чего кстати наши лекарства на европейский рынок и не пускают, правда и у нас сертификаты получать начали, но вроде ограничиваются ISO 9000 который позволяет устанавливать стандарт качества вообще чего угодно, в том числе и ПО. Насчет эффективности GLP судить не могу, но сделан он по мотивам GMP однако программированию ближе именно GLP. Организация процесса разработки по большей части вопрос дисциплины а любая дисциплина без карательных механизмов очень быстро скатывается в сраное говно.

Причина же непопулярности подобных процессов скорее психологическая чем экономическая - любой человек стремится минимизировать уровень контроля и ответственности. Поэтому подобные процессы валидации надо закреплять законодательно иначе их применяющие оказываются в проигрышной ситуации по сравнению с адептами quick@dirty

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

Велкам то дойчланд )

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

Да. Лучше медленно, но верно. Да и тем более я думаю, что при расширении области использования появились ьы новые, более быстрые, автоматизированные средства верификации.

Ну тады иди, бери ипотеко-подобный кредит, и начинай платить, чтобы к старости получить веб-браузер HTML 4.0.

а мне лучше - пусть глючит, но дает новые возможности. Пусть, например, google earth падает раз в 10 минут (хотя и не падает), но работает сейчас, чем пять лет ждать непадающего.

Пусть GPS-навигатор перезагружается при проезде через перекресток рядом с домом, зато он есть сейчас, а не через три года и не по цене в половину авто.

восемь лет назад срез репозитория Дебиана на 2 сд казался громандым. Щас на 5 двд не влезает. Тебе еще мало софта?

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

мне приходилось говорить с теми, кто работает в конторах, имеющих ISO 9000. Они все говорят одно - в момент сертификации мы напряглись, а получив сертификат обратно расслабились.

Причина же непопулярности подобных процессов скорее психологическая чем экономическая - любой человек стремится минимизировать уровень контроля и ответственности. Поэтому подобные процессы валидации надо закреплять законодательно иначе их применяющие оказываются в проигрышной ситуации по сравнению с адептами quick@dirty

* С какой это стати ты будешь запрещать чего-то адептам quick and dirty? почему они должны ждать каких-то валидаций, если они им не нужны?

* если хотите валидаций - ну введите официальный знак «Это валидированный софт», процедуру валидации, и откажитесь от использования всего, что ее не прошло. Когда тебе кто-то даст валидированную ОС с браузером, заходи на ЛОР, расскажешь

> Ты бы пошел к врачам которые не несут ответственности за предоставляемое лечение и диагностику?

А шо делать. C другой стороны, к врачу с liability insurance с размером в $1M тебе просто не попасть...

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

Такое давно уже есть. Ты ГОСТовскую рамку для чертежей видел? Там даже место есть для надписей

1. Чертил - Иванов [подпись]

2. Проверил - Петров [подпись]

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

> восемь лет назад срез репозитория Дебиана на 2 сд казался громандым. Щас на 5 двд не влезает. Тебе еще мало софта?

Да, мало. Мог бы написать тут список конкретных пожеланий, но лень.

почему плохо? как раз с точностью до наоборот )

>мне приходилось говорить с теми, кто работает в конторах, имеющих ISO 9000. Они все говорят одно - в момент сертификации мы напряглись, а получив сертификат обратно расслабились.

Что собственно и подтверждает тезис о бесполезности всяких проверок в отсутствии кнута

С какой это стати ты будешь запрещать чего-то адептам quick and dirty?

Во-первых нет ничего более постоянного чем временное решение а во-вторых дурное влияние заразительно. Стандарты имеют смысл лишь при массовом внедрении

>у програмистов тоже есть code review, где все твои изменения просматривают, прежде чем включают в главную ветку. Иногда даже двое просматривают.

Некто Ханс Рейзер уже ласково высказывался по этому поводу, Линус с его ММ отдыхает. В общих чертах - просматривать только код патча бесполезно, нужно описание алгоритма чем разработчики ядра брезгуют не поднимаясь выше понятий «патч» и «фича» и постоянно пытаются скрестить ежа с ужом чтоб получить метр колючей проволки.

>1. Чертил - Иванов [подпись]

2. Проверил - Петров [подпись]

Я даже знаю как эти подписи ставятся. У нас поллабы за шефа расписываться умеет

6) Расстрел, сопровождающийся пытками в газенвагене.

На самом деле должна быть (ИМХО) высокая ответственность руководителей проектов, ведущих направления. Известно - как поставлена задача, так она и решается.

>поллабы за шефа расписываться умеет

Шеф такой шеф. Пущай попробуют мои за меня расписаться, мало не покажется.

> Некто Ханс Рейзер уже ласково высказывался по этому поводу, Линус с его ММ отдыхает.

И где теперь этот Рейзер?

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

Критика автора не является критикой его взглядов

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

> Критика автора не является критикой его взглядов

Хорошо. Вот у него есть эта ФС. Почему top500 стремаются ее использовать в повседневном быту, а Линус стремается смерджить в ядро? Ведь судя по таким выкладкам, какие приводят Райзер, Шишкин и ко., это был бы самый стабильный, самый бриллиантовый код во всем ядре.

И почему, раз под этим кодом такая научная база подведена, Novell, вооруженная явно не самыми кретинскими инженерами, все-таки перевела SuSE Enterprise на ext3. Видать, работает эта научная база только со сферическими инсталляциями в вакууме.

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

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

Баги - неотъемлемый результат работы программистов