Какой же уровень качества софта достигнут сегодня хотя бы в критически важных системах, от которых напрямую зависит наша жизнь? Насколько массово применяются рекомендации программной инженерии хотя бы 40-летней давности? Вот только за осень 2019-го. Проблемы с софтом коснулись миллионов автомобилей! В частности, ПО управления двигателем для 260,000 машин Mercedes-Benz Sprinter.
Mercedes-Benz customers will be notified in writing over further actions if their vehicle is subject to the recall and a software update can be installed...
https://www.bloomberg.com/news/articles/2019-10-06/da..
Lamborghini, Карл! 441 автомобиль, модели Aventador S и Aventador S Roadsters могут внезапно начать тормозить без предупреждения из-за бага в софте.
https://robbreport.com/motors/cars/lamborghini-aventa..
В ряде автомобилей производства BMW, включая Роллс-Ройсы(!) и машинки совместного производства Toyota Supra (модели 2018-2020 годов), можно задать такие кривые настройки, что камера заднего вида будет выключена при движении задним ходом, причём эта настройка автоматически сохранится. Отзыв автомобилей начнётся в ноябре.
https://www.consumerreports.org/car-recalls-defects/b..
На память приходит ошибка дизайнеров военных интерфейсов, когда в 1988-м американский USS Vincennes сбил мирный иранский самолёт с 290 пассажирами. Система Aegis работала нормально, и правильно опознала самолёт как безопасный, однако информация эта была так неуклюже и невнятно разбросана по нескольким экранам, что моряки для подстраховки решили пульнуть...
Другая известная история про умный боевой корабль Yorktown, вся бортовая система которого работала под Windows NT (хорошая кстати система была, идеологически не хуже Линукса). Оператор ввёл ошибочные данные, и вся(!) система полностью рухнула из-за классического деления на ноль (в плюсах, как известно, подобные исключения не ловятся). На три часа корабль превратился просто в металл, и потом два дня его кое-как буксировали в порт. После чего матросы прошли дополнительный курс "какие значение ни в коем случае в систему нельзя вводить" )))
Фактически идентичный с BMW баг внезапно нашёлся и аж в 1,2 миллионе машин Nissan и Infiniti, причём самых разных (легковушки, грузовики, кроссоверы, внедорожники...).
https://www.autoblog.com/2019/09/24/nissan-backup-cam..
Это что, повторное использование кода? ))) Не знаю, эти компании партнёры? или у них просто один и тот же подрядчик-разработчик софта, откуда-нибудь из Южной Азии?
Ну и Илон Маск порадовал: Tesla отзывает 2000 электромобилей из за логической программной ошибки, которая приводила к возгоранию аккумуляторов. Пока же, похоже, пофиксили на глазок, просто сократили на 40 км дальность езды на одной зарядке.
https://www.autoblog.com/2019/10/05/tesla-software-ba..
===
Причина, по которой даже критически важные системы выпускаются в продакшен забагованными, прозаична — "нет такого преступления, на которое капитал бы не пошёл ради 300% прибыли" (с) Томас Даннинг.
На сегодня самый качественный софт из крупных известных проектов был разработан для американского Space Shuttle. Уровень ошибок составил один баг на 400 тысяч строк кода! Но и сам код обошёлся в тысячу долларов за каждый оператор.
А софт для современных автомобилей — это уже под сотню миллионов строк, и конечно никому не хватит никаких денег на достижение хорошего качества. Хотя, трудно сказать, что в итоге обходится дороже — инвестиции в качество или отзывы тысяч, а то и миллионов, автомобилей.
===
Я абсолютно точно знаю, что качество можно реально быстро поднять с типичного для мэйстрима очень плохого уровня до удовлетворительного совсем простыми инженерными приёмами, никаких формальных методов и верификаций не нужно, много заметок об этом написал.
Например, самый эффективный способ минимизации багов:
https://vk.com/wall-152484379_1758
Но, всё же самый первый критерий — это организационные политики; в компании обязательно должна быть некоторая дисциплина, некоторый формальный процесс производства софта. Измученные кодировщики могут в каких-то разумных пределах выдавать нормальное качество, но когда размер проекта ощутимо растёт, никакая героическая деятельность уже не спасает.
Более того, скажу крамольную вещь, что в крупных проектах наличие крутых программистов (которые обычно в десятки раз сильнее/производительнее других) только вредит. Потому что тот уровень качества, который другие достигают, следуя правильным инженерным best practices, они выдают интуитивно, забивая на организационный процесс — но при этом во-первых нету никаких гарантий, что интуиция в решающий момент их не подведёт, а во-вторых, они своей неформальщиной разлагающе влияют на коллектив.
Вообще, наверное сперва надо признать тот факт, что фактически все известные методологии создания крупных систем потерпели крах. Как минимум, они не будут работать, если компании не будут вкладываться в весьма дорогое и долгое обучение им.
Самые крутые системы тестирования находят 50% багов; самые лучшие белковые код-ревьюеры вылавливают 70% оставшихся. Формальная верификация? Ожидания очень большие, но прогресс пока микроскопический. У Microsoft есть отличный язык Dafny с поддержкой формальных спецификаций, так вот верификация Dafny-компилятора в 5,000 строк потребовала всего лишь 3,7 человеко-года. 4 строчки в сутки...
Я сторонник такого подхода, что прежде всего надо отрабатывать самодисциплину разработки и рефлексию над своими багами, в стиле PSP CMU. В дисциплину входят абсолютно необходимые тесты и что-то в духе простейшей test driven development для начала. Далее, внедряем (в свой мозг:) базовый набор инженерных практик обеспечения качества, и наконец постепенно движемся к формальным методам.
Здесь всего три стратегических направления:
-- пруверы кода вроде HOL4+;
-- логика Хоара/Design by Contract, как в Dafny;
-- программирование в зависимых типах, Agda/Coq...
Так как в мэйнстриме ничего такого пока нету, то начинать надо с моделирования доказательства правильности своего кода в голове, к чему ещё Дейкстра призывал: "think really hard about why it’s true". Идеальное code review сводится именно к этому, хотя на практике ограничиваются в лучшем случае вылавливанием интуитивно подозрительных мест в коде.
Дальше всё же немного подробнее посмотрим, что из этого можно использовать в практике уже сейчас. Ну и вопрос надёжного проектирования это отдельная темка, но тоже обязательная к параллельному изучению.
