Моє розчарування в софті

Суть розробки програмного забезпечення
— Потрібно виконати 500 отворів в стіні, так що я сконструював автоматичну дриль. В ній використовуються елегантні точні шестерні для безперервного регулювання швидкості і крутного моменту по мірі необхідності.
— Відмінно, у неї ідеальний вагу. Завантажимо 500 таких дрилів в пушку, які ми зробили, і вистрілимо в стіну.

Я займаюся програмуванням вже 15 років. Але останнім часом при розробці не прийнято думати про ефективності, простоті і досконало: аж до того, що мені стає сумно за свою кар’єру і за IT-галузь в цілому.

Для прикладу, сучасні автомобілі працюють, скажімо, на 98% від того, що фізично дозволяє нинішня конструкція двигуна. Сучасна архітектура використовує точно розраховану кількість матеріалу, щоб виконувати свою функцію і залишатися в безпеці в даних умовах. Всі літаки зійшлися до оптимального розміру/формі/навантаженні і в основному виглядають однаково.

Тільки в програмному забезпеченні вважається нормальним, якщо програма працює на рівні 1% або навіть 0,01% від можливої продуктивності. Ні в кого начебто немає заперечень. Люди навіть пишаються, наскільки неефективно працює програма, типу «навіщо турбуватися, комп’ютери досить швидкі»:

@tveastman: Я кожен день запускаю програму на Python, вона виконується за 1,5 секунди. Я витратив шість годин і переписав її на Rust, тепер вона виконується за 0,06 секунди. Це прискорення означає, що мій час окупиться через 41 рік, 24 дня 🙂
Напевно, ви чули таку мантру: «Час програміста дорожче часу комп’ютера». Це означає, що ми витрачаємо комп’ютерне час в безпрецедентних масштабах. Ви б купили машину з витратою 100 літрів на 100 кілометрів? Як щодо 1000 літрів? З комп’ютерами таке відбувається постійно.

Всі нестерпно повільно
Озирніться навколо: портативні комп’ютери в тисячі раз могутніше тих, що привели людину на Місяць. Тим не менше, кожен другий сайт не може забезпечити плавну прокрутку сторінки на 60 FPS на останньому топовому MacBook Pro. Я можу комфортно грати в ігри, дивитися відео 4K, але не прокручувати веб-сторінки! Це нормально?

Поштовим додатком Google Inbox в браузері Chrome від тієї ж Google, потрібно 13 секунд, щоб відкрити лист середнього розміру:

This is, in real time, how long it takes for Google Inbox running in Google Browser to open an email. Not the shortest one, but still, it’s just text and pictures! Go Web Stack go! pic.twitter.com/CvqsFiIUuc

— Nikita (@nikitonsky) February 28, 2018

Він ще анімує порожні білі форми замість того, щоб показати їх вміст, тому що це єдиний спосіб анімувати що-то на веб-сторінці з великою продуктивністю. Ні, не 60 FPS, а швидше «настільки швидко, наскільки можливо на цій сторінці. З нетерпінням чекаю, що ж веб-спільнота запропонує, коли дисплеї 120 Гц стануть мейнстрімом. Вони ледь справляються з 60 Гц.

Оновлення Windows 10 займає 30 хвилин. Що можна робити так довго? Цього часу достатньо, щоб повністю відформатувати мій SSD-накопичувач, завантажити свіжий білд і встановити його приблизно 5 разів поспіль.

Павло Фатин: Набір тексту у редакторі — відносно простий процес, тому навіть 286 могли забезпечити досить плавний процес набору.
В сучасних текстових редакторах затримка при наборі більше, ніж у 42-річному Emacs. Текстові редактори! Що може бути простіше? На кожне натискання клавіші, потрібно всього лише оновити крихітну прямокутну область на екрані, а сучасні текстові редактори не можуть зробити це за 16 мс. А це багато часу. БАГАТО. 3D-гра заповнює екран сотнями тисяч (!!!) полігонів за ті ж 16 мс, а також обробляє enter, перераховує світ і динамічно завантажує/вивантажує ресурси. Як так?

Тенденція така, що софт зовсім не стає швидше і функціональніша. Ми отримуємо більш швидке обладнання, на якому софт з тими ж функціями крутиться повільніше, ніж раніше. Все працює набагато повільніше максимальної швидкості. Ніколи не замислювалися, чому ваш телефон завантажується від 30 до 60 секунд? Чому він не може завантажитися, скажімо, за одну секунду? Тут немає ніяких фізичних обмежень. Особисто мені б таке сподобалося. Хочеться, щоб розробники досягли межі, використовуючи кожен біт для продуктивності.

Все ВЕЛИЧЕЗНЕ
І ще це роздуття. Веб-додатки можуть відкриватися в десять разів швидше, якщо просто заблокувати рекламу. Google благає всіх припинити гальма з допомогою ініціативи AMP — технічного рішення, для якого не потрібні якісь технології, просто трохи здорового глузду. Якщо видалити роздування, інтернет стане працювати на божевільній швидкості. Невже це важко зрозуміти?

Система Android без додатків займає майже 6 ГБ. Просто задумайтеся на мить, наскільки непристойно величезне це число. Що там, фільми в HD-якості? Думаю, в основному код: ядро, драйвери. Ще якісь ресурси, звичайно, але вони не можуть бути такими великими. Скільки ж драйверів вам потрібно для телефону?

Windows 95 займала 30 МБ. Сьогодні у нас є веб-сторінки важче, ніж ця ОС! Windows 10 4 ГБ, тобто в 133 рази більше. Але хіба вона в 133 рази краще? Я маю на увазі, функціонально вони практично однакові. Так, у нас з’явилася Кортана, але я сумніваюся, що вона важить 3970 МБ. Але це Windows 10, невже Android повинен бути ще в півтора рази більше?

Додаток клавіатури Google як ні в чому не бувало з’їдає 150 МБ. Ця програма малює 30 клавіш на екрані — вона правда в п’ять разів складніше, ніж вся Windows 95? Додаток Google app, в основному, просто пакет для Google Web Search, займає 350 МБ! Сервіси Google Play, якими я не користуюся (я не купую там книги, музику або відео) — 300 МБ, які просто сидять тут і які не можна видалити.

Після встановлення всіх необхідних додатків (соціальні мережі, чати, карти, таксі, банки і т. д.) на телефоні залишився всього 1 гігабайт для фотографій. І це взагалі без ігор та музики! Пам’ятаєте часи, коли ОС, додатки і всі ваші дані містилися на дискету?

Ваша програма для нотаток напевно написана в Electron і, таким чином, поставляється з драйвером для контролера Xbox 360, вміє показувати 3D-графіку, відтворювати аудіо і фотографувати з допомогою веб-камери.

Простий текстовий чат завжди славився швидкістю і малим споживанням пам’яті. Так що Slack — це приклад дуже ресурсномісткого додатка. Я маю на увазі, що чат і текстовий редактор — це базові речі, вони повинні споживати менше всього ресурсів. Ласкаво просимо до 2018 рік.

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

Все гниє
Android-телефон на 16 ГБ був прекрасний три роки тому. Сьогодні під Android 8.1 він ледве працює, тому що кожен додаток збільшилася мінімум вдвічі без видимих причин. Додаткових функцій немає. Вони не стали швидше і зовнішній вигляд не змінився. Вони просто… роздулися?

iPhone 4s вийшов з iOS 5, але навряд може працювати під управлінням iOS 9. І це не тому, що iOS 9 набагато краще — в основному, система не змінилася. Але нове обладнання швидше, тому вони зробили програмне забезпечення повільніше. Не хвилюйтеся — ви отримали захоплюючі нові можливості, наприклад… робота тих же програм з тією ж швидкістю! Не знаю.

iOS 11 припинила підтримку 32-розрядних додатків. Це означає, що якщо розробник не готовий повернутися і оновити додаток, швидше за все, ви не побачите знову цю чудову програму.

@jckarter: Програму DOS можна змусити працювати без змін практично на будь-якому комп’ютері, зробленому після 80-х років. Додаток JavaScript може припинити роботу через завтрашнього оновлення Chrome.
Сьогоднішні веб-сторінки не будуть працювати в будь-якому браузері за 10 років (а може і раніше).

«Треба бігти з усіх ніг, щоб тільки залишитися на тому ж місці». Але сенс? Я можу постійно купувати нові телефони і ноутбуки, як всі, але робити це лише заради того, щоб мати можливість запускати ті самі програми, які стали тільки повільніше?

Думаю, що ми можемо і повинні виправити ситуацію. Зараз всі розробляють програми для сьогоднішнього дня, зрідка для завтрашнього. Але буде непогано робити речі, які працюють трохи довше.

Гірше — значить краще
Зараз ніхто нічого не розуміє. І не хоче розуміти. Ми просто випускаємо полусырую дурницю, сподіваємося на краще і називаємо це «здоровим глуздом для стартапу».

Веб-сторінки просять оновитися, якщо щось пішло не так. У кого є час, щоб знайти причину неполадки?

Будь-веб-додаток видає постійний потік «випадкових» помилок JS, навіть на сумісних браузерах.

Вся архітектура баз даних веб/SQL побудована на припущенні (навіть надії), що ніхто не змінить дані, поки ви дивитеся на відкриту веб-сторінку.

Більшість програм для спільної роботи зробили «як змогли», там маса типових сценаріїв, коли вони втрачають дані. Бачили діалог «Яку версію зберегти?» Сьогодні планка так низька, що користувачі ради навіть цього питання.

Та ні, в моєму світі не є нормальним додаток, яке говорить: «Я знищу частина твоєї роботи, тільки вибери яку».

Linux навмисно вбиває випадкові процеси. І все ж це найпопулярніша серверна ОС.

У мене кожен пристрій регулярно виходить з ладу так чи інакше. Час від часу монітор Dell потрібно апаратно перезавантажувати, тому що в ньому є софт. AirDrop? Вам пощастить, якщо він виявить пристрій, інакше що робити? Bluetooth? Специфікації настільки складні, що пристрої не будуть встановлювати зв’язок один з одним, а періодичні перезавантаження — оптимальний варіант.

І я навіть не згадую про Інтернеті речей. Це настільки за межею розумного, що навіть нічого додати.

Я хочу пишатися своєю роботою. Я хочу робити робітники, стабільні речі. Для цього потрібно зрозуміти, що конкретно ми розробляємо, всередині і зовні, а це неможливо зробити в роздутих, надмірно ускладнених системах.

У програмуванні такий же хаос
Здається, що ніхто більше не зацікавлений в якісних, швидких, ефективних, довговічних, ґрунтовних рішеннях. Навіть якщо давно відомі ефективні рішення, ми як і раніше боремося з тими ж проблемами: управління пакетами, системи збирання, компілятори, конструкція мови, IDE.

Системи складання по своїй суті ненадійні і періодично вимагають повної очистки, хоча у них є вся інформація для инвалидации. Ніщо не заважає зробити процес складання надійним, передбачуваним і на 100% відтворюваним. Просто ніхто не думає, що це важливо. NPM вже багато років перебуває в стані «іноді працює».

@przemyslawdabek: Здається, що rm-rf node_modules є невід’ємною частиною робочого процесу в проектах Node.php/JavaScript.
А час складання? Ніхто не вважає проблемою, що компілятор працює хвилини або навіть години. А як же «час програміста дорожче»? Майже всі компілятори, пре – і постпроцессоры значно, іноді катастрофічно збільшують час збірки, не забезпечуючи пропорційно істотних переваг.

Ви очікуєте, що програмісти будуть брати в основному раціональні рішення, але іноді вони роблять прямо протилежне. Наприклад, вибираючи Hadoop навіть якщо він повільніше, ніж виконання тієї ж задачі на одному десктопному комп’ютері.

Машинне навчання і ІІ відкинули програмне забезпечення до гадання на кавовій гущі у часи, коли більшість комп’ютерів навіть не були достатньо надійними.

@rakhim: Коли програма або сервіс говорить «під управлінням ШІ» або «на основі машинного навчання», я читаю це як «ненадійне, непередбачувана поведінка, яка не піддається поясненню». Я тримаюся подалі від «ШІ», тому що хочу від комп’ютерів протилежного: надійності, передбачуваності та логіки.
Ми засунули віртуальні машини в Linux, а потім засунули Docker у віртуальні машини, просто тому що ніхто не зміг розібратися з бардаком, який виробляють більшість програм, мов та їх середовищ. Ми накриваємо лайно ковдрами, щоб не прибирати його. Наприклад, «єдиний бінарники» залишається ВЕЛИЧЕЗНОЮ перевагою Go. Ні бардаку == успіх.

Навколишнє середовище Python настільки забруднилася, що мій ноутбук оголосили зоною екологічної катастрофи.
Примітка. Агентство по захисті навколишнього середовища Python хотіло залити його цементом і поховати з картинкою на вході — попередженням для майбутніх цивілізацій про небезпеку використовувати sudo для установки випадкових пакетів

А залежності? Люди бездумно ставлять переусложненные «повні пакети» для найпростіших проблем, не думаючи про наслідки. З цих залежностей ростуть нові. В кінцевому підсумку ви отримуєте дерево, яке є чимось середнім між фільмом жахів (величезна і повне конфліктів) і комедією (немає причин, за якими ми додали сюди ці пакети, але ось вони):

Програми не можуть працювати кілька років без перезавантаження. Іноді навіть кілька днів — це занадто. Відбуваються випадкові глюки, і ніхто не знає чому.

Що ще гірше, ні у кого немає часу зупинитися і з’ясувати, що сталося. Навіщо турбуватися, якщо завжди є інший вихід. Підняти новий інстанси AWS. Перезапустити процес. Видалити і відновити базу даних. Написати скрипт, який буде перезапускати ваше зламане додаток кожні 20 хвилин. Включити одні і ті ж ресурси кілька разів: тяп-ляп — і продакшн. Рухайся швидко, не витрачай час на виправлення помилок.

Це не інженерна робота. Це просто лінива програмування. Інженерна робота передбачає глибоке розуміння продуктивності, структури і обмежень того, що ви створюєте. Ліпити халтуру з неякісного матеріалу — зовсім протилежне заняття. Щоб розвиватися, ми повинні розуміти, що і навіщо ми робимо.

Ми застрягли
Таким чином, все це просто купа ледве працюючого коду, доданого поверх раніше написаного ледве працюючого коду. Він продовжує рости в розмірах і складності, зменшуючи шанси на зміни.

Щоб мати здорову екосистему, необхідно повернутися. Необхідно іноді викидати непотріб і замінювати його кращими альтернативами.

Але у кого є на це час? Нові ядра ОС не виходили скільки, 25 років? Це зараз стало надто складним, щоб просто взяти і переписати. В браузерах накопичилося стільки прикордонних ситуацій та історичних прецедентів, що ніхто не наважиться писати движок з нуля.

Сьогоднішнє визначення прогресу — або підкинути палива:

@sahrizv: 2014 — потрібно впровадити микросервисы для вирішення проблем з монолітами.
2016 — потрібно впровадити Docker, щоб вирішити проблеми з микросервисами.
2018 — потрібно впровадити Kubernetes, щоб вирішити проблеми з Docker.
або винаходити велосипед:

@dr_c0d3: 2000: напишіть 100 рядків XML, щоб «декларативно» налаштувати сервлети і EJB.
2018: напишіть 100 рядків YAML, щоб «декларативно» налаштувати микросервисы.
У XML були хоча б схеми…
Ми застрягли, і ніхто нас не врятує.

Бізнесу все одно
Користувачам теж. Вони навчилися приймати те, що ми робимо. Ми (інженери) говоримо, що кожен додаток для Android займає 350 МБ? Добре, вони будуть з цим жити. Ми говоримо, що не можемо забезпечити плавну прокрутку? Окей, вони звикнуть з телефоном, який пригальмовує. Ми говоримо: «Якщо не працює, перезавантажитеся»? Вони перезавантажаться. Адже у них немає вибору.

Конкуренції теж немає. Всі будують одні і ті ж повільні, роздуті, ненадійні продукти. Випадковий стрибок вперед за якістю дає конкурентну перевагу (iPhone/iOS проти інших смартфонів, Chrome проти інших браузерів) і змушує всіх перегрупуватися, але ненадовго.

Наша місія як інженерів — показати світу приголомшливі можливості сучасних комп’ютерів з точки зору продуктивності, надійності, якості і зручності використання. Якщо нам не все одно, люди потягнуться. І ніхто крім нас не покаже їм, що таке можливо. Якщо тільки нам не наплювати.

Не все так погано
Іноді на пасмурном небосхилі просвічують промінчики надії.

Робота Мартіна Томпсона (LMAX Disruptor, SBE, Aeron) вражає, вона освежающе проста і ефективна.

Редактор Xi Рафа Левиена, здається, побудований на правильних принципах.

Джонатан Блоу для своєї гри розробив мову компілювання, який компілює 500 000 рядків в секунду на ноутбуці. Це холодна компіляція, ніякого проміжного кешування, ніяких інкрементальних білдів.

Не потрібно бути генієм, щоб писати швидкі програми. Тут немає якоїсь магії. Єдине, що потрібно, — це не будувати софт на базі величезної купи лайна, яку постачають сучасні інструменти.

Маніфест кращого світу
Я хочу бачити прогрес. Я хочу змін. Щоб сучасне програмне забезпечення удосконалювалося, а не стояло на місці. Я не бажаю заново винаходити одне і те ж, щоразу випускаючи все більш повільний і роздутий продукт. Я хочу в щось вірити — гідну мету, в майбутнє, яке краще, ніж те, що ми маємо сьогодні, і щоб з’явилося співтовариство інженерів, які поділяють це бачення.

Що ми маємо сьогодні — це не прогрес. Ми ледь досягаємо бізнес-цілей з цими поганими інструментами. Ми застрягли в локальному оптимумі, і ніхто не хоче рухатися. Це навіть не гарне місце, воно роздуте і неефективне. Ми просто звикли до нього.

Тому я хочу заявити: нинішня ситуація — повне лайно. Як інженери, ми можемо і повинні, і зробимо краще. У нас можуть бути кращі інструменти, ми можемо створювати кращі програми, більш швидкі, передбачувані, більш надійні, використовують менше ресурсів (на порядки менше!). Ми повинні глибоко зрозуміти, що ми робимо і чому. Ми повинні випускати продукти надійно, передбачувано, з найвищою якістю. Ми можемо і повинні пишатися нашою роботою. Не просто «враховуючи те, що у нас було…» — жодних застережень!

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