Одного разу програмісти загублять цей світ



1. Історія перша: спогад
Коли я був маленьким і ходив ще в молодшу школу, зі мною трапилася така історія. На перерві я з кількома друзями перебував у класі, коли з полиці сам собою впав квітка. На нашу біду тут же увійшла наша вчителька і без будь-яких розглядів звинуватила нас у хуліганстві. Червоною ручкою були зроблені записи про погану поведінку в щоденник, викликані батьки. Це було так прикро і не зрозуміло, що назавжди врізалося мені в пам'ять. З тих пір я часто розмірковував, що ж змусило квітка впасти?

А адже саме логічне пояснення — він сам впав. Просто він ріс, викидав нові пагони, розвивав і нарощував масу. Тягнувся до сонця. Одного разу проекція центру ваги квітки вийшла за межі опори і він перекинувся.

Не знаю, навіщо я це все пишу. Можливо меланхолія прийшла разом з осінню і жовтим листям. Іноді мені здається, що наука програмування так стрімко розвивається, так йде вперед семимильними кроками, так швидко створює нові технології, що одного разу людина не зможе все це приборкати.

2. Історія друга: програмісти не знають точно, як працюють їхні програми
Я досить добре пам'ятаю свою першу програму за яку мені заплатили гроші. Було це дуже давно. В ті стародревние часи комп'ютерів як таких у нас в країні ще не було. Принаймні вони були дуже великою рідкістю. Якась комерційна організація, а тоді такі організації називалися «кооператив», розпочала власне виробництво комп'ютерів.



Це був покращений клон комп'ютера «Спеціаліст» на базі 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? Чи ми будемо боятися літати на літаках і їздити в безпілотних автомобілях? Чи можна вірити медичних приладів? Не побоїмося ми входити у систему онлайн-банку? Програмні продукти оточують нас всюди. Можливо, не будь я програмістом, мені не було б так страшно…
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.