- PVSM.RU - https://www.pvsm.ru -
Когда я был маленьким и ходил еще в младшую школу, со мной приключилась такая история. На перемене я с несколькими друзьями находился в классе, когда с полки сам собой упал цветок. На нашу беду тут же вошла наша учительница и безо всяких разбирательств обвинила нас в хулиганстве. Красной ручкой были сделаны записи о плохом поведении в дневник, вызваны родители. Это было так обидно и не понятно, что навсегда врезалось мне в память. С тех пор я часто размышлял, что же заставило цветок упасть?
А ведь самое логичное объяснение — он сам упал. Просто он рос, выбрасывал новые побеги, развивал и наращивал массу. Тянулся к солнцу. Однажды проекция центра тяжести цветка вышла за пределы опоры и он опрокинулся.
Не знаю, зачем я это все пишу. Возможно меланхолия пришла вместе с осенью и желтыми листьями. Иногда мне кажется, что наука программирования так стремительно развивается, так идет вперед семимильными шагами, так быстро создает новые технологии, что однажды человек не сможет все это обуздать.
Я довольно хорошо помню свою первую программу за которую мне заплатили деньги. Было это очень давно. В те стародревние времена компьютеров как таковых у нас в стране еще не было. По крайней мере они были очень большой редкостью. Некая коммерческая организация, а тогда такие организации назывались «кооператив», затеяла собственное производство компьютеров.
Это был улучшенный клон компьютера «Специалист» на базе 580-го процессора. Предполагалось создать полностью свое ПО для этого компьютера. Первый этап — написание БИОС. Ну а я делал для БИОСа самую первую процедуру: тест ОЗУ. Пикантность ситуации была в том, что производимый компьютер был настолько не надежен, что для процедуры теста ОЗУ нельзя было использовать временные переменные в памяти, нельзя ничего хранить в этом самом ОЗУ пока оно не протестировано. Ну это в общем логично, конечно. Однако, как можно было написать тест памяти имея всего навсего восьми битный аккумулятор A и еще шесть восьми битных регистров общего назначения B, C, D, E, H и L? При этом тест должен на графическом экране в правом верхнем углу писать сколько памяти протестировано: 8 Кб, 16 Кб, 24 Кб… Делал я эту программу долго, наверное два или три дня. Написал, получилось кажется до сотни строк ассемблерного кода, проверил и, гордый своей работой, сохранил программу на магнитную ленту. Пришел сдавать-показывать работу, а магнитная лента не читается на магнитофоне. Ну что делать: тут же в офисе на рабочем «Специалисте» по памяти (!) весь код заново набрал, запустили, проверили — ура! работает! Получил кажется рублей 30 за работу. Большие деньги.
В те очень далекие времена я в своей программе понимал АБСОЛЮТНО ВСЕ.
С тех пор, так получилось, я писал программы на ассемблере процессоров 6502, Z80, x86. Потом заболел языком Forth. Кое что получалось на FoxPro. Потом настала пора C/C++. Говорили, кто поймет MFC, тот вообще специалист высшего класса. Выучил-освоил MFC. Писал драйвера для Windows 2000/XP/w7 и для Linux. Нужно было делать сайт для компании — участвовал: html, css, js, php. Еще немного микроконтроллеров: Atmel, STM32, еще x86: MMX/SSE. Еще немного C/C++: нужен boost? нужен QT? ну ладно берем boost, берем QT. Ага… попутно где-то кому-то делаю программу для планшета Android (Java+JNI+cpp) в Eclipse, и еще собираю систему на кристалле в ПЛИС Altera — тут уже язык Verilog, тестбенчи и прочие хардверные радости.
И знаете что? Я уже не уверен, что полностью понимаю как работают все эти системы, программы, алгоритмы. От былой уверенности уже нет и следа. По моим подсчетам в год приходилось и приходится изучать, знакомиться и использовать до 2-3 новых технологий, сред программирования, библиотек и языков. При этом, конечно, нет никакой уверенности, что все знаешь и все понимаешь. На самом деле понимаешь только базовые принципы…
Более того, если когда-то, лет пять назад, я думал, что я знаю, люблю и понимаю c++, то теперь, уже с приходом новых стандартов типа c++11, с++14/17, мне приходится действительно тяжко. Мои коллеги исправляют мой код заменяя мои типизированные переменные на тип auto… И что? Неужели после этого код становится действительно более читаемым? Или вот еще не очень свежая новость: нежелательно использовать наследование, но предпочтительно использовать темплейты. И мне грустно. Я не люблю темплейты.
Я бы вероятно совсем впал в уныние, однако, в частных разговорах с другими программистами за чашечкой коньяка вдруг выясняется, что не только у меня такие проблемы, не один я такой отсталый (хотя не все в этом сразу признаются, зависит от размера чашки). Многие так же, как и я, не до конца понимают чужой код, не до конца понимают как работает вся наша система целиком, не знают, какие сторонние библиотеки мы уже подключили и используем, не понимают откуда в нашей не очень сложной программе 67 потоков и почему она занимает в памяти 350 мегабайт.
Более всего в этой истории с высокоуровневым программированием меня тревожит «эффект магической строки». Этот термин я сам недавно придумал. Речь не о багах, которые конечно были, есть и будут. Речь об одной строке кода, которая принципиально меняет свойства программы.
Например, пишем программу с использованием библиотек QT. У нас есть наш собственный класс, унаследованный от QGraphicsView. Мы используем наш класс, размещаем на нем QGraphicsScene, добавляем всякие QGraphicsItem и живем долго и счастливо, но медленно. Потом вставляем в код одну магическую строку:
QGLWidget* gl = new QGLWidget(); this->setViewport(gl);
И вот уже наше приложение зашевелилось и вообще стало довольно шустрым, ведь теперь оно использует для отрисовки графики аппаратное ускорение OpenGL.
— Эй! Коллега программист! Ты знаешь, что такое OpenGL?
— Слышал, но никогда не использовал.
— Я то же. Но теперь мы используем его и это работает! Смотри как хорошо стало!
— Ура! А ведь всего лишь одна строка кода… ну и две-три дополнительных DLL в инсталляторе.
Проходит неделя или две. Слушайте, чего-то как-то не очень. Какие-то проблемы с медиа плеером и QGraphicsVideoItem… Надо что-то с этим сделать… Еще неделя и появляется еще одна магическая строчка:
QCoreApplication::setAttribute(Qt::AA_UseOpenGLES);
— Эй! Коллега программист! Это что еще за хрень?
— Ну… я не знаю точно, но вроде бы после этого используется режим трансляции запросов OpenGL в DirectX (Angle) и якобы теперь стало гораздо лучше: и CPU не так загружен и видео кажется стало без ошибок крутить…
— ???????????..
— Ладно, посмотрим, что скажет QA..
Беда N1: программисты до конца не понимают как работает их программа! А есть ли способ понять? Сколько на это потребуется времени? А как же time-to-market? Не наступила ли уже «технологическая сингулярность», когда новые технологии рождаются быстрее, чем мы можем их переварить и освоить?
Года три назад посчастливилось нашей компании ввязаться в очень перспективный проект. Мы так думали, что проект очень перспективный. Российская компания по производству оборудования решила снабжать свои агрегаты платой электронного управления. Нам предстояло в сжатые сроки разработать и изготовить плату и плюс программное обеспечение микроконтроллера.
Сказать по правде, я был очень рад этому проекту. Во-первых, компания российская, некий эффект патриотизма. Во-вторых, казалось, что проект весьма долговременный, поскольку ассортимент агрегатов широкий, а заказчик имел намерение идти в ногу со временем и выпускать конкурентное современное оборудование.
Однако были и нюансы:
Мы почему-то сразу подумали, что возьмем денег по минимуму, все равно по проекту еще долго взаимодействовать и сопровождать его. Заказчик в лице директора с этим устно согласился.
Далее начались некоторые странности. Как оказалось, со стороны заказчика был только один инженер, который реально вникал в алгоритм, сам его описывал, часто звонил и интересовался ходом работ. При этом, мне постоянно казалось, что мы делаем что-то не то, в наших алгоритмах явно не хватало математики, здесь явно не хватает всех этих ТАУ, ПИД и прочих премудростей систем автоматического управления. Мы пытались развернуть разработку в сторону реального ТАУ, но получили ответ, что получится слишком сложно и им такое не надо. Самое странное, что кроме одного инженера, с которым мы взаимодействовали со стороны заказчика никого более никакие алгоритмы вообще не интересовали. Уже в момент сдачи работ, при демонстрации готовых плат мне наконец-то пришло понимание происходящего. Главный инженер проекта воспринимает плату микроконтроллера, как любую другую деталь агрегата, только что выточенную на токарном станке или согнутую на трубогибе.
То есть: должен быть чертеж с указанием типа материала, размеры, допуски — все. Есть деталь — устанавливаем ее на посадочное место и весь разговор.
Ну что сказать. Я пытался разговаривать и объяснять, что программное обеспечение — это не деталь, что требуется долгое и тщательное тестирование алгоритмов на реальном оборудовании. Что может оказаться, что реализованные алгоритмы могут потребовать корректировки или изменения постоянных времени, скорости реакции и т.д. Моя фраза, что в программном обеспечении возможны баги, которые нужно отлавливать и устранять наткнулась на стену непонимания. Оказалось, что наши баги — это наши проблемы. ВСЕ баги, все 100%, должны быть устранены до момента сдачи работ. Потом инженер заказчика проводит свое тестирование и приемку работ. И все. Проект сдан, никаких более изменений в ПО не предвидится и изделие после установочной партии передается в серию.
Стоит ли говорить, что сторона заказчика провела испытание плат одним инженером за один (!) день и уже через неделю после подписания акта приемки сдачи он же звонил и просил подправить два временных параметра в алгоритме.
Душа болит и сердце плачет. Мы реально вкладывались в этот проект, жили им, но мы так и не поняли, сделали ли мы всю работу так как надо. Мы так и не увидели своими глазами агрегат в сборе под управлением нашей платы.
Закончилось все так же внезапно, как и началось. По прошествии некоторого времени заказчик рассчитал, что производство печатных плат в РФ экономически не выгодно. Проект закрыт. Может оно и к лучшему, кто знает…
Отвлекусь от конкретного этого описанного выше случая. Хочу отметить важное: каждый программист в принципе знает, что в его программе есть или возможны ошибки. Да, мы пишем тесты, ведем continuous integration, но у многих из нас в баг трекере висит список незакрытых задач даже по продукту который давно уже выпущен. Иногда программа доходит до этапа «смертельная петля тестирования». Это когда свежие исправления в программе порождают новые, ранее не известные баги. QA возвращает на доработку ПО, разработчики исправляют и отдают в QA, но те, работая не покладая рук возвращают на доработку снова и снова. Если заказчик этого ПО адекватный, то он просто готов смириться с некоторыми ошибками, которые иногда объявляются фичами (feature), с целью снизить напряженность отношений.
С другой стороны, сторонний заказчик, особенно если ранее не сталкивался с процессом разработки ПО, понимает процесс совсем по другому. Для очень многих программа — это то, что можно увидеть и пощупать, то есть как правило — это только часть GUI, то что можно увидеть глазами: кнопочки, формы, диалоги. Если есть плата, то важно, как она выглядит и как ее можно подержать в руках. Что и как за этим скрыто, какая там есть логика и какие алгоритмы — неведомо. Отсюда барьер не понимания.
Беда N2: Заказчик почти никогда не в состоянии проверить качество разработанного программного обеспечения, даже если ему отдать исходные тексты.
Если теперь рассмотреть эти две описанные мною беды как единое целое: программисты не до конца понимают как работают их программы, плюс заказчик не может проверить результат, то что это вообще будет? Какое будущее нас ждет? Сколько недо-продуктов будет нас окружать? Опасно ли входить в высотные здания, проезжать по мостам, рассчитанным в инженерных CAD? Будем ли мы бояться летать на самолетах и ездить в беспилотных автомобилях? Можно ли верить медицинским приборам? Не побоимся ли мы входить в систему онлайн-банка? Программные продукты окружают нас повсюду. Возможно, не будь я программистом, мне не было бы так страшно…
Автор: nckma
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/187521
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/310026/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.