Я працюю в ІТ вже 25 років. Ось що я можу сказати про зміну технологій за цей час

💡 Усі статті, обговорення, новини про .NET — в одному місці. Приєднуйтесь до .NET спільноти!

Майже чверть століття у сфері комерційної розробки ПЗ — досить суттєвий проміжок часу, щоб спостерігати зміни технологічних трендів. Мене звати Олександр Єременко, я співпрацюю з ЕРАМ Україна як провідний .NET-інженер. Мій професійний шлях стартував на початку нульових і за цей час я працював з різними технологіями, на різних платформах, в різних доменах і пройшов загалом близько 20 проєктів.

Це дозволяє мені проаналізувати зміни в технологіях і підходах до розробки софта за 25 років. Зауважу, що в матеріалі відображено мій суб’єктивний погляд, який базується суто на особистому досвіді.

Від зірки оптимізації до жертви продуктивності

Кажуть, що якось Стів Джобс під час розробки однієї з моделей Apple Macintosh звернувся до інженера Ларрі Кенйона з проханням скоротити час завантаження системи. Джобс переконував Кенйона, що якщо той зможе зробити завантаження на 10 секунд швидше, це в сукупності зекономить багато часу користувачів. Основний аргумент був такий: мільйони людей щодня витрачатимуть на 10 секунд менше часу на очікування, що в кінцевому підсумку додасть багато зекономлених років життя.

Пам’ятаю, як колись в старших класах я програмував на ZX Spectrum. Це такий популярний на той час персональний комп’ютер з процесором на 3.5 МГц і 48 Кб пам’яті (зараз, напевно, в кавоварці встановлено більш потужне залізо). Щоб зробити плавні рухи на екрані, треба було враховувати кожен такт процесора. Тому я мав саморобну табличку з усіма командами асемблера і числом тактів на виконання кожної команди.

Часом доводилось посидіти над кодом, оптимізувати його, адже 30 років тому неефективність могла коштувати десятки або сотні зайвих операцій і це одразу було помітно. Зараз же навіть мільйони зайвих операцій або виділені декілька сотень МБ зайвої пам’яті в більшості випадків не впадуть в око.

Заради експерименту я прокрутив цикл на 10 мільйонів ітерацій на робочому ноуті з 11th Gen Intel^® Core™ i7-1185G7 @ 3.00GHz кодом C# .NET 8:

Це зайняло ~8мс! Через потужність сучасної техніки й великі обсяги пам’яті навіть погано оптимізований код може працювати швидко. Ось одна зі змін за останні 25 років: немає сенсу сильно перейматися ефективністю, адже залізо витягне. Але якщо раніше було доречним витрачати ресурс на оптимізацію сотень команд, то, можливо, зараз варто робити це для сотень мільйонів? Адже зручність і швидкість, яку дарують нові технології, мають зворотний бік. Погано оптимізований код може працювати швидко, але при збільшенні навантаження проблеми стануть очевидними.

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

Питання продуктивності не обмежуються лише процесорами. Швидкий інтернет і об’ємні накопичувачі дозволяють передавати та зберігати величезну кількість даних, часто непотрібних. Зайві логи, метрики й трейси часто залишаються після розробки та потрапляють на продакшн. Це може створювати додаткове навантаження і викликати проблеми продуктивності навіть непомітно для інженерів.

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

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

Гугл у поміч

За 25 років дуже помітною стала зміна підходу до програмування. Раніше кількість доступної інформації, готових програм або прикладів була дуже обмеженою. Доводилось багато експериментувати, досліджувати, вигадувати, винаходити та вчитися на інших програмах, дезасемблювати (умовно кажучи, розбирати на деталі), якщо не було вихідного коду, дебажити в рантайм тощо. Різноманітних шаблонів проєктування, архітектурних стилів ще не знали або не придумали, тому кодування було дуже творчим і непередбачуваним процесом.

16-17 травня, Київ. Квитки тут!👇

Я пам’ятаю, як на початку 2000-х невеличкою командою ми писали тренажерну систему для авіадиспетчерів, намагаючись імітувати одну з існуючих реальних систем. Треба було відписати клієнт-сервер по TCP/IP, зробити кастомний юзер інтерфейс, який би водночас підтримував швидкий растровий і векторний вивід і мав віконні компоненти, які виглядали й поводились зовсім не так, як у Windows. Плюс картографічна компонента, база даних тощо.

Це все при відсутності інтернету, книжок і прикладів! Ми проводили багато експериментів, відкидали неробоче, поки не знаходили робочий варіант. Це все займало дуже багато часу, зараз те саме можна вже зробити в рази швидше.

Згодом з розвитком інтернету і збільшенням ком’юніті почали вимальовуватися шаблони, зросла кількість готових бібліотек, які перемістилися в інтернет у вигляді пакетів, деякі системи стали опенсорсними, з’явилися професійні сайти на кшталт Stack Overflow... Все це поступово привело до «гугл-кодінгу», коли вже не треба нічого винаходити, досить просто знайти готовий шматок коду або бібліотеку, що розв’язує задачу. Весь процес тепер більше нагадує збір пазлу, коли інженер добирає сумісні між собою частини та поєднує в одне ціле. Ну а з приходом штучного інтелекту це вже переростає в ШІ-кодінг...

З іншого боку дуже сильно зросла кількість інфраструктурної, нефункціональної роботи. Якщо раніше програму розробляли, збирали та тестували вручну локально, а потім віддавали на носії замовнику, то зараз треба налагодити репозиторії, CI, хмарні ресурси, CD, написати та налагодити запуск автотестів, код для моніторінгу/аналітики тощо. Тобто деякі моменти з часом спростилися, а у чомусь задачі стали більш комплексними.

Замість вертикального зростання — горизонтальне

За моїми спостереженнями знання інженерів стають скоріше широкими, ніж глибокими. Одиниці фокусуються і спеціалізуються на чомусь одному, бо це вже немає сенсу. Адже технології змінюються, вимоги ринку нестримно ростуть. Раніше, знаючи одну мову і фреймворк, можна було працювати 5-10 років без суттєвих змін і перенавчання, але зараз цей термін скорочується до двох років і менше. Після 2000-х світ ІТ прискорився, кількість мов і фреймворків значно зросла, а проміжки часу між виходами нових версій стали скорочуватись.

Наприклад, у .NET між великими оновленнями раніше проходило десь 4 роки, потім цей термін скоротився до 2 років, а тепер вони відбуваються щороку. Платформи розвинулись і виросли в кількості: інтернет-застосунки від простого гіпертексту доросли у функціональності до десктопних рішень. Також наприкінці «нульових» з’явились смартфони, планшети, смарт ТБ, різноманітні пристрої, розумні годинники, приставки тощо. Через це попит на кросплатформенні мови виріс, а деякі з них (як от .NET і JavaScript) почали експансію на інші платформи. Деякі мови почали стагнувати (наприклад, зараз вже мало хто згадує про Pascal, Delphi, VBA), але з’явились нові: Go, Rust, Dart, TypeScript тощо. Завдяки ШІ стає дуже популярним Python, а завдяки автоматизаціям мають попит мови для скриптів (як от PowerShell і Bash).

Через таке розмаїття технологій і швидкості прогресу програмісту вже невигідно мати вузьку спеціалізацію, а компаніям, вочевидь, невигідно наймати таких фахівців. Якщо раніше спеціалізації FrontEnd, Backend, DB існували здебільшого окремо, то зараз багато вакансій відкриті саме для FullStack-інженерів і за замовчуванням мають DevOps-складову. Дивлячись на деякі пропозиції й кількість несумісних технологій, перерахованих в них, просто дивуєшся: а чи справді є такі люди на світі?! Насправді, на мою думку, це шкодить професії: інженер має фрагментовані, неглибокі знання по багатьом технологіям, що своєю чергою...

• Не дає можливості глибоко розвиватися і мати сильну експертизу по одній-двом технологіям.

• Призводить до зниження якості коду і рішень порівняно з експертами.

• Перенавантажує фахівця.
• Провокує стрес і невпевненість в собі.

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

Time2Market по-новому

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

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

Конкуренція була невелика, а часу багато. Проте поступово ситуація змінювалась. Конкуренція росла і Time To Market ставав все критичнішим. Waterfall перестав працювати, бо в такій ситуації (зокрема, якщо мова йде про стартапи) не так важливо довгострокове і досконале проєктування, як перевірка того, чи працює сама ідея, а точніше — який з варіантів таки буде працювати. Для цього підходять короткотермінові ітерації — і так у фокусі з’являються Agile і Scrum. Я б навіть сказав, Scrum-манія. Scrum почали використовувати всюди, включно з проєктами з повністю фіксованим ТЗ та сапорт-проєктами, що в принципі не мало особливого сенсу.

Через велику конкурентність і критичність Time To Market з часом відбувся демпінг цін. Деяким компаніям доводиться обіцяти все більше, щоб взяти привабливий проєкт, а терміни й ціни стають меншими. У таких умовах часу на детальне проєктування та оцінювання просто не вистачає. Все це збільшує ризики для якості й витримування термінів.

З одного боку завдяки автоматизації, збільшенню можливостей мов, бібліотек, інфраструктури спеціалісти реалізують набагато складніші рішення, аніж раніше. Але менше працювати ІТ-фахівці не стали, часом навіть навпаки. Вочевидь, вимоги ростуть одночасно з можливостями. Цікаво було б підрахувати, наскільки більший обсяг інформації, порівняно з минулим, зараз обробляє спеціаліст, наскільки більше факторів треба врахувати під час ухвалення рішення, наскільки збільшилась швидкість усіх процесів...

Здавалося б, сьогодні можна вести мову про 6-годинний робочий день або 4-денний робочий тиждень, про розвантаження для підняття ефективності й запобігання вигоранню, але чомусь все навпаки: у вакансіях ми бачимо, що все більше відповідальності хочуть покласти на одну людину, а овертайми, на жаль, не рідкість в індустрії.

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

Якщо підсумувати...

Загалом спочатку в українському IT було небагато грошей. Продати програмний продукт було досить складно, а працювали й захоплювалися цією сферою здебільшого ентузіасти. З початку 2000-х тут з’являються гроші, які стрімко ростуть, і з часом IT стає дуже привабливою галуззю. Сьогодні серед колег можна зустріти і колишніх медиків, і будівельників, і фінансистів. Індустрія стала дорослішати, розміри компаній суттєво збільшились, разом з цим дещо виросла бюрократія, стало більше різних ролей... За свою кар’єру на декількох проєктах я спостерігав ситуацію, коли кількість менеджменту перевищувала кількість інженерів.

Що маємо в сухому залишку сьогодні? Бум цифрових технологій. IT з гаражів гіків переїхав в офіси білих комірців і став масмаркетом, де можна як і добряче заробити, так і добре вигоріти. Глибока нішева спеціалізація переростає в широку і фрагментовану. І важливіше не стільки те, що ти знаєш зараз, а те, наскільки швидко зможеш розібратися в новому. У висококонкурентне людське середовище втручається штучний інтелект і ставить під питання майбутнє професії, принаймні в попередньому її вигляді та обсязі.

Що ви думаєте з приводу трансформації галузі? Які спостереження зробили для себе останнім часом? Буду радий поспілкуватися у коментарях.