ИТ — единственная отрасль на планете, которой сходит с рук продажа заведомо дефектных продуктов потому, что компании хитрят и формально не продают софт, а сдают в аренду (ПО лицензируется). Условия аренды, как вы хорошо знаете из лицензионных соглашений, снимают с разработчиков ответственность практически за всё, и это юридически корректно, потому что на договора аренды не распространяются стандарты качества продукта. С другой стороны, если у автомобиля отказали тормоза, то суду всё равно, виновато в этом программное обеспечение или заклинивший поршень. Если проданный вам продукт не работает (при известных характеристиках "работы"), производитель несёт ответственность в любом случае, тем более, если это привело к фатальным физическим последствиям. Это тот самый переход от условий лицензирования продукта к ответственности производителя за последствия неисправностей в проданном продукте.
=
Но так происходит и потому, что сами производители софта (безусловно, виноватые в плохом качестве минимум на 51%), тоже в большой степени заложники того тупика, куда в итоге забрели ИТ. К сожалению, даже при создании критически важных систем мы по-прежнему используем языки программирования, которые позволяют крайне легко "реализовать" ошибочный код. Многими десятилетиями 80% серьезных ошибок стабильно приходятся на классическое переполнение буфера или некорректное приведение типов. Напомню, например, что язык Ada, разработанный Пентагоном в конце 1970-х, и по сей день демонстрирует непревзойдённый уровень по качеству и надёжности программ и активно используется и военными, и во многих гражданских проектах. Никакие джавы шарпы питоны и близко к нему не стоят по этим характеристикам.
Почему? Да потому что он настолько строг, что значительно усложняет или делает почти невозможным написание дерьмокода. Однако этот подход так и остаётся уделом немногих проектов, потому что разработка на Аде существенно дороже Java-кодинга аналогичной функциональности, и объяснить эффективным менеджерам нужду в этом практически нереально. Более того, сегодня с подачи Илона Маска вообще становится популярным совершенно безумный подход с дикими дедлайнами.
Даже самые лучшие в мире программисты время от времени забывают проконтролировать выход индекса за границы массива или указать явное приведение типов (что впрочем само по себе тоже плохо — значит, система типов в проекте совсем слабая), создавая крайне вредную конструкцию, как только один из типов немного меняется. И в ситуации "скорей-скорей" вероятность явления таких ошибок растёт многократно. Так почему же мы до сих пор массово используем все эти "популярные" языки?
=
Так вроде бы исторически сложилась система подготовки программистов, хотя на самом деле, как уже пояснял, современная разработка зашла в тупик ровно потому, что крупнейшие американские корпорации уничтожили коммерческий рынок инструментов программирования, подсадив весь мир на крюк своих бесплатных IDE через идеологию опенсорса. Сегодня довольно легко найти программистов, знакомых с Java или Python и ещё двумя-тремя популярными языками, а вот другие языки программирования гораздо менее известны, да и вакансий по ним почти нету. А жёсткие графики проектов обычно не подразумевают изучение новых языков и фреймворков. В результате многие профессиональные программисты хорошо знают только один язык, ну и немного какой-нибудь второй, не понимая преимуществ других подходов применительно к их ИТ-области. Они уверены, что недостатки используемого ими языка "естественны", и так должно быть.
Ситуация ещё больше ухудшается чрезмерным самомнением :) когда ребята считают, что программирование буквально "должно быть" сложным и низкоуровневым, и только их гениальный ум способен понять тот запутанный код, который они пишут, и это вроде как нормально.
Да и начальники часто имеют о других языках программирования крайне смутное представление, считая переход на другой язык слишком опасным. Вас не уволят за то, что вы используете Python, но если вы решаете писать на F#, а проект проваливается, вам будет крайне трудно пояснить причины такого перехода.
=
Напомню мои старые заметки по этой теме:
Язык, на котором можно программировать без ошибок
https://vk.com/wall-152484379_1699
Промышленные технологии создания программ, в которых практически отсутствуют ошибки
https://vk.com/wall-152484379_1721
Конечно, совершенно не питаю иллюзий, что прочитав это всё, хотя бы один человек начнёт использовать Аду. Но теперь это уже не моя ответственность, а ваша :)
В заметках выше есть очень полезные прикладные ссылочки. Есть GNAT (GNU Ada), есть его версии для трансляции в JVM и .NET. С помощью gnat/gcc код на Ada можно компоновать с кодом на других языках, так что есть возможность плавного перехода на другой язык программирования шаг за шагом, без "замены всей кодовой базы и всего стека целиком" (с) Илон Маск. А главное, что доступны мощные технологии вроде SPARK для создания формально верифицированного софта.
Наконец, распространенным аргументом против подобных языков называют объём памяти и время выполнения. На самом деле, код на том языке, на котором вы пишете сейчас (пусть даже на Си), если он будет содержать такое же количество всевозможных проверок безопасности, как и в аналогичной программе на Аде, займёт примерно такой же объём памяти и будет примерно так же быстро выполняться, проверено не раз практикой самых серьёзных проектов.
=
В прошлом посте говорил про 216 проектов, которые были отобраны в рамках технологического суверенитета, и на поддержку которых, если не ошибаюсь, у нас выделено полмиллиарда долларов. Затея, безусловно, крайне важная, однако получается так, что пользователи ПО, которое покупалось в недружественных странах и которое теперь подлежит срочной замене (и у которого наверняка имелись аналоги на мировом рынке), теперь по сути принуждаются к безальтернативному использованию суверенных импортозамещённых продуктов. У исполнителей в результате не будет никакой мотивации "делать качественно", так как никакой конкуренции нету по определению, а в ситуации, когда ещё и сроки очень сжатые и надо выпустить продукт "ещё вчера", вероятность выпуска сильно забагованного софта возрастает многократно.
Как надо было делать правильно, я пишу не один год :) Но сейчас уже гром грянул, и поздняк метаться. Напомню однако, что стратегический путь остаётся единственный: абсолютно необходима национальная межведомственная независимая экспертная ИТ-служба (но ни в коем случае не общественная!), занимающаяся
а) контролем за качеством рабочих процессов производства софта (как в ISO или модели Capability Maturity Model Карнеги-Меллона, когда к госконтрактам допускаются компании с сертификатом CMM минимум 3-го уровня — в организации хотя бы немножечко осознанно и упорядоченно начинают относиться к этому всему),
б) сертификацией технических заданий к важным проектам,
в) контролем за качеством самого софта.
Практически всё это решается достаточно легко на самом деле, ну совсем минимальными затратами: делаются типовые чек-листы, с которыми эксперты ходят по компании и проверяют. Я и сам ровно так делаю, когда консультирую, и был свидетелем лет 20 назад, как в одной очень крупной российской конторе американский эксперт именно таким образом и проводил сертификацию по CMM. А сегодня и AI вполне подобным вещам можно обучить.
И ведь схожая практика, между прочим, у нас ведётся: в 2019-м был запущен нацпроект по повышению производительности труда на 5% в год. Вот так он и работает — в компанию приходят эксперты, проводят обследование, и дают рекомендации (обязательные к выполнению :), как улучшить надои и покосы. Надо сперва хотя бы немножечко распространить эту практику и на ИТ, сперва на КИИ.
Вот увидите, рано или поздно нечто подобное обязательно появится, гарантирую. Но лучше бы, конечно, рано.
Причём в ИТ не 5% а 50% ну вообще легко достигается, самыми элементарными телодвижениями (нормальное ТЗ, покрытие кода тестами, линтеры, ассерты...), а по взрослому, в 10-100 раз потенциально можно повысить качество/надёжность/продуктивность 98% проектов. Вот мы смеёмся над Илоном Маском по поводу его "а нафига в твиттере тысяча RPC чтобы просто показать хоумпейдж?" и "что ты сделал, чтобы исправить это?", но ведь в целом он прав. Отмазка инженера кстати была классическая: дескать это легаси-код 10-летней давности, и мы потихонечку это улучшаем :) Ну, да, за зарплату миллион долларов в год можно особо и не напрягаться.
Вот такой сегодня весь современный мэйнстрим — зашедший, как мы видим, в полный тупик. Ну так давайте не следовать этим жутким анти-паттернам, а сразу делать норм, тем более что в программной инженерии "как правильно" известно многие десятилетия. А лучше конечно — делать топчики мирового уровня, SotA, это совершенно реально.
