vit_r (vit_r) wrote,
vit_r
vit_r

Categories:

Про ёжика в тумане, зазнайство, языки программирования и вериги

Software Engineering
В гости к juan_gandhi пришли perdakot, thedeemon, nponeccop и другие высоколобые товарищи, пообсуждать, почему это в области надёжного автомобильно-самолётно-спутникового софтостроения дремучие менеджеры нагораживают ООП с процессами и запрещают применять всякую красоту вроде
fun evenSqares {n:nat | n % 2 == 0 && n >= 4 %% n != 10}(x : int n) : int(n*n) = x*x

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

Я их вечно путаю, так что объясняю просто: Та, которая «ве», - она про «Кто виноват?», а которая «ва», она про «Что делать?» (Кто не застал уроков литературы советских времён, пусть придумает что-то посовременнее.)

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

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

Качество верификации определяется метриками надёжности типа наработки на отказ. И стоимость растёт экспоненциально при приписывании сзади очередного нуля.

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

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

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

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

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

Теперь вернёмся ко второму слову.

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

Потому что это то, где наши модели сталкиваются с реальным миром.

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

Колебания топлива в нетривиальных условиях в нетривиальном сосуде, граничные параметры эмуляции которого заданы таблицей производителя с кучей дырок. Вращательное движение неравномерных несимметричных объектов. Торможение атмосферой. Закручивание магнитным полем Земли. Притяжение Луны. Не соответствующая параметрам изготовителя точность звёздных датчиков...

Всё это складывается в дикую систему. Одна матрица учитываемых параметров занимает на распечатке стол целиком.

И всё это должно работать в реалтайме. Причём, в любое время может прилететь какая-нибудь вредная частица и выбить в памяти пару битов.

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

И рабоатют там крутые люди. Которые могут и ФП, и ООП, но предпочитают писать на голом C, чтобы быть уверенными в том, что софт делает на самом деле то, что должен.

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

Таким не то, чтобы строчку сверху показывать нельзя. Им от слова «монада» страшно станет.

Так, для примера: когда в одном проекте (не космос, а попроще, но mission critical) я предложил для одного эмулятора многопоточное решение (достаточно банальное), понять, о чём я вообще говорю, мог только один человек. Причём, это был совсем не Главный Аналитик. Который вообще такими вещами не интересовался. «Потому что операционная система реалтайм обеспечивает, значит ничего неприятного произойти не может.»

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

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

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

Впрочем, Тойота, подарившая вебовским кудесникам волшебные слова типа «lean» и «kanban», наглядно показала, что бывает, если экономить на «устаревших методологиях».
Tags: it, management, qa, quality, ru, se, space
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 26 comments