Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет chistyakov ([info]chistyakov)
@ 2007-02-26 20:42:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
За что я ненавижу "программистов"
Где-то в конце 70-х годов - испытания амерской ЗСУ "Сержант Йорк". Для поражения вертолетов. ЗСУ была оснащена системой распознавания образов.
Во время испытаний около неё безуспешно кружил вертолет-мишень, которую она так и не смогла распознать. Зато распознала как вертолет вентилятор в туалете, расположенном метрах в 800-х от ЗСУ. И успешно его поразила.

Испытания американского истребителя F-16 проводились, понятное дело, в северном полушарии. На заключительном этапе самолет решили проверить где-то в Латинской Америке, но уже с другой стороны экватора. При переводе самолета в режим автопилота он автоматически развернулся "вверх ногами".

В Афганистане двое наводчиков-наблюдателей (канадцы) подсвечивали цель для наведения на нее бомбы. После сброса бомбы в GPS приемнике закончились батарейки. Расчет их быстро заменил. В результате ракета прилетела не туда. Причина проста. После подачи питания в прибор, переменные, отвечающие за координаты цели, автоматически инициализировались координатами текущего местоположения. Наводчики погибли от близкого разрыва.

На испытаниях Су-24 регулярно случался отказ аппаратуры бомбометания. Причем происходило это только в том случае, если на цель заходил летчик-испытатель Ильюшин. Причина оказалось тоже не сложной. Только он заходил на цель с точностью, превышавшей машинную точностью. Получался "машинный нуль", после чего шел сбой из-за попытки деления на ноль.

Этот пример тоже очень характерен, хотя, строго говоря, он и не относится напрямую к разработке ПО, но демонстирует важность тестирования. Возникла эта проблема, скорее всего, на МБР 15А30, причем уже после постановки ее на боевое дежурство. При пуске, ракета выходила из шахты и взрывалась на высоте нескольких метров над землей. Причина оказалась тоже не самой сложной. Рубашка сопла охлаждается окислителем, после чего он поступает в камеру сгорания. В спешке принятия нового комплекса на вооружение к очередной годовщине, в систему пуска двигателя внесли небольшие улучшения, которые не протестировали должным образом. В результате пироклапан срабатывал с большим запаздыванием. Окислитель не поступал в трубки охлаждения, а жаропрочности сопла хватало только на то, чтобы ракета вышла из шахты.

Причиной взрыва 4 июня 1996 г. ракеты Ариан-5, была программная ошибка. В системе управления ракеты использовалось модифицированное программное обеспечение ранее успешно работавшее на Ариан-4, но Ариан-5 ускорялась быстрее предыдущей модификации, в результате когда на 40 секунде полета одна из вспомогательных подпрограмм попыталась преобразовать длинное целое значение в короткое без проверки величины значения, и то вышло за границы типа, произошло отключение системы управления ракеты, и она была взорвана по команде на самоликвидацию. Прямой (вместе с ракетой-носителем была потерян коммуникационный спутник) и косвенный ущерб от этого программного сбоя был оценен в полмиллиарда долларов.

История о неприятностях ракетного крейсера ВМС США «Иорктаун». Это экспериментальный, так называемый «умный корабль» (smart ship), важнейшие системы жизнеобеспечения которого управляются компьютерами без участия человека. И что немаловажно – под руководством операционной системы Windows NT 4.0. Так вот, однажды вся эта махина, находясь в открытом море, на три без малого часа встала в полный ступор из-за наглухо зависшего программного обеспечения. Причем произошло это из-за совершенно пустяковой оплошности одного из операторов, занимавшегося калибровкой клапанов топливной системы и записавшего в какую-то из ячеек расчетной таблицы нулевое значение. Ну а далее пошла операция деления на этот самый нуль. С подобной ерундой справляется даже самый дешевый калькулятор, однако здесь в терминале оператора система дала ошибку переполнения памяти. Причем ошибка быстро перекинулась на другие компьютеры локальной сети корабля, началась цепная реакция, и по известному принципу домино рухнула вся бортовая система. Которую удалось восстановить и перезагрузить лишь через 2 часа 45 минут, в течение которых здоровенный боевой корабль оставался по сути дела беспомощен и неуправляем. (с)


via [info]u-96@lj путём "Ctrl-C/Ctrl-V"

Да, бывает. Я вот вспоминаю, как ракета с "распознаванием образов" сбила летящий самолёт Ан-26 с людьми вместо стоящего на земле вертолёта-мишени (Ахтубинск, 24 июня 1985 года). На следущий день я летел в Ахтубинск на таком же самолёте, надеясь, что испытания по данному типу (Ан-26) завершены. Обстановка в салоне была шутливо-нервозной:).

{+}


(Читать комментарии) - (Добавить комментарий)

Re: А про наших чтож молчите?
[info]hydrargentum@lj
2007-02-27 08:43 (ссылка)
Я вам тут отвечу как программист,

>>Большинство программистов не удосуживаются свои поделки проводить сквозь комплексные тесты.

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

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

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

Вы простите сами, на все руки мастер - одинаково хорошо можете посчитать уравнения аэродинамики, и дипольные моменты для молекулы например бензопиррола? Я думаю врядли.

И чтож если вы не сможете вычислить значение дипольного момента мне вас записать в лохи ливерные?

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: А про наших чтож молчите?
[info]ex_chistyak@lj
2007-02-27 10:26 (ссылка)
Я вот как-то без программистов обхожусь. Одни несчастья от них. Лучше уж самому.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: А про наших чтож молчите?
[info]hydrargentum@lj
2007-02-27 12:00 (ссылка)
Вы вообще Титан, обнаружив ваш журнал удивился невероятно.

А скажите, есть ли на постсоветском пространстве ктонить кто занимается созданием подводных беспилотников? Есть ли ресурсы в сети профильные?

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: А про наших чтож молчите?
[info]ex_chistyak@lj
2007-02-27 13:40 (ссылка)
Такие люди, что занимаются подводными беспилотниками, есть, по крайней мере, были в СССР в Краснодаре. Но я их не встречал с 1991 года, увы.
Надо узнать, кто делал подводную станцию "Мир", с которой снимали подводные кадры в "Титанике". Искать надо, наверное, в Калининграде или в Ленинграде.

(Ответить) (Уровень выше)

Re: А про наших чтож молчите?
[info]a_50@lj
2007-02-27 21:37 (ссылка)
> мне вас записать в лохи ливерные?
В лохи да еще и ливерные, лучше не надо:).
Рецепт простой: пусть аэродинамику считают аэродинамики,
а молекулы, соответственно,
химики.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: А про наших чтож молчите?
[info]ex_chistyak@lj
2007-02-28 03:47 (ссылка)
ВО! О необходимости чего всё время и говорят большевики!

(Ответить) (Уровень выше)

О, пальцегнутик пургена объелся...
[info]ex_project_d682@lj
2007-03-01 00:33 (ссылка)
"Это целиком и полностью вина не программиста, а организатора производственного процесса"

1. Отнюдь. Может быть, ещё менеджер по кадрам во всяких фирмах будет строить техничек на предмет правильного мытия полов? В тестировании программист _должен_ понимать больше любого другого.

2. _Модульные_ тесты - это даже не половина дела, это только самое начало. Впрочем, похоже, Вам про это неизвестно.

"а про научное доказательство корректности, так это простите значит что те программеры которые работают на вас просто крайне далеки от предметной области"

Ну-ну. Про доказательство корректности Вы, похоже, не слышали ничего. Подсказка: оно не имеет НИКАКОГО отношения к предметной области.

"но и вас в первую очередь что вы поставили некомпетентных людей"

Тормози на поворотах! Я кадровой политикой не уполномочен заниматься, архитектор - не зав и не зам. И потом, найдите нам _хороших_ программистов. Их почти нет, а кто есть, либо за границу свалили, либо на хлебные места, а вот образованием и наукой заниматься некому, непрестижно и деньги очень маленькие.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: О, пальцегнутик пургена объелся...
[info]hydrargentum@lj
2007-03-01 03:22 (ссылка)
Нуну....

Я то думал - кто это.... А это аказывается Архитектор, Архитектор это наверняка ПриМат за плечами, и в частном случае даже круче чем "Программист" :))) Вы сами то програмируете что либо практически, или вашу архитектуру воплощать в живой код вы тоже не уполномочены?

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

2. Я знаю как обстоит дело с тестированием, и в теории и на практике, так как мне помимо совдеп стиль компаний, давелось поработать и на буржуйские корпорации - вы читать умеете? Даже модульные тесты компании оказались не нужны - а это как вы сами заметили не половина даже дела, в теории. На практике теперь - ничего кроме модульных тестов и GIGO программист делать НЕ ДОЛЖЕН. В случае если програмист сам себя тестирует - это нетолько не полезно, это крайне вредно - приемные ТЕСТЫ И ПРОГРАММЫ должны писать РАЗНЫЕ люди - это результат личной практики.

Доказательство корректности - каюсь ваша правда, я не примат не разу - мне ближе всюдорогу органолептический метод и статистика :)

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

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

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

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

И за резкость, как водится извините.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: О, пальцегнутик пургена объелся...
[info]ex_project_d682@lj
2007-03-01 03:37 (ссылка)
0. У нас тут специалистов мало, аспиранты в основном, поэтому, кроме построения архитектуры, и кодировать приходиться (да даже фреймворки писать), и проектировать, и анализ предметной области... И при этом огромная часть времени и сил тратится на исправление той пурги, что понаписали другие.

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

2. Сам делать не должен, но он должен свой модуль сделать таким, чтоб его можно было протестировать, а не отрефакторить (трудоёмкий и долгий процесс) перед этим грёбаным тестированием. Сколько раз приходилось втыкать в код, логика работы которого непостижима без стакана, а отловить без дебаггера ошибки почти нереально (да за такое пальцы отрубать мало!)... Да и вообще, кодерам, которые процедуру не могут уместить в один экран, убивать надо. Так что всё же тестирование в первую очередь зависит от кодера, при этом первичное тестирование модуля - исключительно его задача, как на корректность работы, так и на реакцию в экстремальных ситуациях. А кто сейчас это делает? Да никто почти. "Работает? Ну и ладно, на остальное - плевать". Сами потом локти кусают, когда код приходится менять (сопровождение и развитие), но продолжают делать дерьмо.

Насчёт резкости: да просто задрало говорить об одном и том же, особенно когда ещё и обидки какие-то появляются. Некоторым хоть кол на голове теши. Правильно товарищ Чистяков говорит: в нормальном обществе программисту нельзя доверять НИЧЕГО.

(Ответить) (Уровень выше)


(Читать комментарии) -