Про програмування на ЕОМ в 1970-х, курсові на перфокартах і роботу в «лихі 90-ті». Історія розробника, який уже 40 років в IT

62-річний Михайло Стрелков уже 40 років в IT. Нині працює керівником проєктів групи розробки ETL УРВІС AT UKRSIBBANK BNP Paribas Group. До цього був програмістом в інших банках, у науковому інституті та на військовому об’єкті. Михайло почав програмувати у 1970-х, кодував ще на Algol 60 і Fortran 4. Щоб працювати з ЕОМ, у студентські роки доводилося використовувати знайомства, а потім на робочому місці чекати своєї черги за розкладом.

Ми попросили розробника поділитися спогадами про IT у 1970–90 роки: де і як вчили програмістів, які були мови програмування, комп’ютери, як вдалося залишитися у професії в «лихі 90-ті»? У статті Михайло розповів і про те, якою роботою найбільше пишається за всі 40 років в індустрії.

З дружиною біля фонтана Треві

Навчання в університеті: «ЕОМ була в спецприміщенні з обмеженим доступом, і ніхто зі студентів її жодного разу не бачив»

Яке було ІТ в 1970–90-ті? Ну, по-перше, самої абревіатури «ІТ» тоді ще й не було. Принаймні я не чув. Там, де я починав, у 1982 році були «програмісти» й «електронщики», які відповідали за «залізо» й ОС, тобто адміни. Де і як навчали цих професій? Електронників — не знаю, мабуть, у політехах, на програмістів ніде не вчили.

Я закінчив мехмат ХНУ, спеціальність — прикладна математика. І йшов туди саме для того, щоб вчити програмування. У школі моїми улюбленими предметами були математика та фізика, хоча більше я розумівся саме на фізиці. В той час був журнал «Квант», який видавав для школярів Московський фізико-технічний інститут. У ньому друкувалися матеріали для поглибленого вивчення математики, підготовки до вступних іспитів на серйозному рівні тощо. І там я натрапив на статтю про програмування, де було написано, що його нині викладають тільки на мехматах, на відділеннях прикладної математики. Я подумав, що це цікаво, і вирішив вступати на мехмат до харківського університету. До того ж цей факультет був дуже потужним, з науковою традицією, яка тягнеться з XIX століття. До речі, моя дружина теж закінчила прикладну математику, тільки в ХАІ, працювала програмісткою деякий час, але потім перейшла у бухгалтерію. Двоє дітей з трьох теж в IT, а тепер і внучка збирається вчитися програмування.

Отже, у 1977 році на першому курсі в ХНУ ми трохи вивчали алгол 60 — це, мабуть, одна з перших високорівневих мов програмування. Там були глобальні та локальні змінні, блоки begin/end. Напевно, алгол 60 найбільше схожий на Pascal, але той просунутіший, там уже з’явилися нові різні фічі. На алголі ми майже не програмували, вивчали його на дошці та папері, писали на листочках програмки, але в комп’ютер не заводили. Чому так? Для студентів це була саме навчальна програма, бо алгол суворий, типізований. А десь ним точно користувались. Пізніше Pascal став стандартною та найкращою мовою програмування для навчання студентів. Цю мову обрали насамперед для того, щоб навчити правильно мислити. Нині у цьому ключі я б віддав перевагу Python.

На другому курсі ми вивчали Fortran 4 (Fortran — скорочення від The IBM Mathematical Formula Translating System). Ця мова програмування була створена спеціально для науковців і добре підходила для їхніх цілей. Там не було типів даних на кшталт рядкових, нічого зайвого — тільки числові дані, але підтримувалися навіть комплексні числа.

Отож ми вивчали Algol 60 на першому курсі та Fortran 4 на другому. І це все. Далі були обчислювальні методи, за якими треба було реалізовувати курсові на Fortran.

До речі, програми писали на папері та віддавали в перфораторну, де вони перетворювалися на пачки перфокарт, які потоком потрапляли у зчитувальний пристрій ЕОМ

ЕОМ була в спецприміщенні з обмеженим доступом, і ніхто зі студентів жодного разу її не бачив. Студенти отримували через кілька днів свої колоди перфокарт і стрічки роздруківок.

Ну, самі розумієте, будь-яка помилка в коді — метри паперу з помилками й іноді дампами пам’яті. Хочеш щось виправити — починай спочатку. Тому швидко всі навчились за допомогою леза та лузги від дірочок у перфокартах виправляти помилки прямо в них. А що тут складного? У перфокарті 8 рядків — це біти, стовпець — байт. Стовпців-байтів на перфокарті, здається, 80. Дірочка є — це 1, немає — 0. Там, де треба з 0 зробити 1, акуратно прорізаєш дірочку, а де навпаки, береш зі сміття вибитий шматочок з перфокарти та втискуєш у непотрібну дірочку. Вони там міцно тримались, бо то був високоякісний картон, хоч і тонкий (його потім ще років 10–15 використовували як закладки до книжок).

Такий вигляд мали перфокарти. Джерело

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

Це був кайф. А всього там було приблизно 32К оперативної пам’яті. Ця одна ніч поруч з комп’ютером дала більше, ніж всі ці прорізування та забивання дірочок у перфокартах протягом року. Бо, чесно кажучи, до 3–4 курсу це вже добряче набридло. Свої курсові ми успішно здали.

Ще трохи про мови програмування: «На адаптацію до алгоритмічного мислення у мене пішло, мабуть, тижня два чи три»

Пізніше, уже наприкінці 1980-х, я зіткнувся з PL/I. Це була потужна мова, таке собі поєднання Fortran з Algol. Там уже були всі блокові конструкції, розвинуті цикли. У Fortran 4 були тільки найпростіші цикли, коли задавалося перше значення, кінцеве значення та крок. А у PL/I — уже нормальні do-while цикли, різні типи даних. Можливо, це була остання мова перед об’єктноорієнтованими.

Взагалі, першою об’єктноорієнтованою мовою вважають Ada. Вона названа на честь Ади Лавлейс, дочки лорда Байрона, яку визнають першою програмісткою у світі. Вона писала код за допомогою всіляких стрічок у XIX столітті. Мова Ada була створена на замовлення військових у США. Не знаю, як її використовували на практиці, я про неї тільки читав. Нині я працюю з Oracle, в якій є вбудована мова PL/SQL. Кажуть, що вона була зроблена на основі Ada. Вже на початку 1990-х я трошки програмував на C. C++ тоді ще не було, мова C# ще пізніше виникла у США.

Цікаве спостереження щодо вивчення мов програмування. Важко було ламати «математичний спосіб мислення», коли є формули або твердження (теореми, тощо), які пов’язані між собою логічно, але не має значення порядок їх використання, і переходити на «алгоритмічний спосіб мислення», де саме порядок виконання і є найголовнішим. І вираз на зразок «X=X+1» є цілком нормальною конструкцією, бо «=» — це не «дорівнює», як у математиці, а означає «призначити». Але спочатку це викликало шок. На адаптацію до такого алгоритмічного мислення у мене пішло, мабуть, тижня два чи три. А найцікавіше, що коли через 20 років я почав вивчати SQL, що є декларативною мовою, то на зворотну адаптацію з алгоритмічного мислення, зі всіма цими if-then-else, do-while тощо, на мислення декларативне: що взяти (select), звідкіля (from), за яких умов (where) тощо, часу знадобилося значно більше. Мабуть, місяці два чи три. Увесь час тягло на цей if-then-else. Знаю деяких колег-програмістів, які так і не змогли перемкнути свій спосіб мислення з алгоритмічного на декларативний. Слава богу, тепер у мене є PL/SQL, мова, яка поєднує і те, і інше.

Перша робота: «Нам дали величезний окремий магнітний диск на 100 Мб — нечуваний обсяг!»

Я випустився з ХНУ 1983 року. Звісно, тоді професія програміста була зовсім не масова. Так, наше відділення прикладної математики випускало за рік три групи, всього людей 60. Приблизно 60–70 % йшли працювати програмістами. Тобто дуже мало. Але у більшій кількості фахівців і не було потреби. На той час, крім науковців і військових, майже ніхто не використовував комп’ютери, хіба ще були бухгалтерські програми. Я потрапив на військовий об’єкт: там справді було класне «залізо», було все, щоб розвиватися.

Ще на останньому курсі університету я вже працював на підприємстві «Електроприлад» (сьогодні «Хартрон»), де розробляли програмне забезпечення та «залізо» для космосу, військових тощо. У народі це підприємство прозвали «67-й ящик». Чому так? Військові підприємства в СРСР не мали військових назв, тільки цивільні для маскування (КБ «Електроприлад») і секретні військові номери — поштові скриньки, яких ніхто не повинен був знати. Але весь Харків знав :)

Похід на байдарках. Друзі майже всі з «Електроприладу». І майже всі теж айтішники. 1982–1985 рр.

Спочатку я там проходив переддипломну практику, а потім уже захистив диплом і перейшов у штат. Щодо зарплати, то складно порівнювати. У нашому відділі всі вважалися інженерами, незалежно від спеціалізації. Тож не знаю, яку платню отримували інші програмісти, але саме «Електроприлад» давав ставку для молодих фахівців вищу, ніж у середньому в галузі у Харкові. Так, скажімо, інженер (необов’язково програміст, будь-який інженер) після закінчення вишу зазвичай отримував 110–120 рублів на місяць, нам же відразу дали 150. Це була суттєва різниця.

Отже, на першій роботі я вже міг щодня насолоджуватись майже власною (вона була одна на відділ) супер-ЕОМ — ЄС-1060 — точною копією IBM System 360/370. А що ви хотіли :) У СРСР навіть моторолер «В’ятка» був близнюком чогось італійського. Була, щоправда, така собі «БЭСМ-6», казали, що це чисто єреванська розробка, але не дуже віриться. За розміром ця ЄС («Єдина система» — загальна назва родини великих ЕОМ в СРСР) була як шафа, завширшки метр, заввишки два метри та завдовжки метрів 5–6. Ну й, звичайно, з лампочками та кнопочками. До речі, щоб її ввімкнути та завантажити, треба було на консолі виконати 15–20 різних команд, які задавали певні параметри ОС. А перезавантажувати доводилось часто, бо нерідко вона зависала.

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

Як ми працювали? Був один монітор, під’єднаний до цієї великої ЕОМ, на трьох-чотирьох програмістів

Тому була черга, розклад, і сідали за нього з чітко розпланованою роботою на призначені півтори чи дві години. А в інший час готуйся, є папір — пиши код або розбирайся за лістингами з помилками. Звичайно, іноді була «дідівщина», коли старший і поважний колега міг зігнати молодого в його час, бо «у мене серйозні речі, а ти тут граєшся».

Ще зупинюся на обсягах даних. На наш проєкт, в якому брали участь 5–7 фахівців, дали окремий величезний магнітний диск, здається, на 100 Мб. Нечуваний обсяг! Там було все. Всі наші програми з усіма версіями, а їх було сотні, і всі файли даних до них. Це був такий круглячок у діаметрі приблизно 50 сантиметрів, набраний з окремих дисків, завтовшки 25–30 сантиметрів. Він вставлявся зверху в спеціальний «дисковод». Це була така собі тумбочка заввишки 60–70 сантиметрів, інші сторони теж 60 на 60. Але на той час це було дуже круто, бо деякі колеги, які працювали на інших проєктах, використовували вже згадану раніше «БЭСМ-6», і в них все було суто на магнітних стрічках. І якщо порівнювати з перфокартами, які були в універі, це теж було потужно.

Що я там робив? Спочатку то були переддипломна практика і дипломна робота. І саме тоді я нарешті відчув себе справжнім програмістом. Бо завдання для диплома я мав непросте: треба було, аналізуючи код багатьох модулів на Fortran, автоматично сформувати та надрукувати інформаційні схеми обміну даними між ними (те, що тоді називалося HIPO-діаграмами). Для цього треба було парсити код, знаходити там глобальні змінні, визначати, як вони там використовуються тощо. Тобто за складністю це був майже компілятор, точніше його значна частина. Звичайно, на Fortran 4 такого не втнеш, там навіть не було текстових типів даних.

Тому використовував асемблер і Fortran для друку. Це було круто! Щоправда, старші колеги тільки хмикали, бо вони колись писали ще в машинних кодах. А асемблер, якщо порівнювати з машинними кодами, — цукерка! Там же команди та фрагменти пам’яті (те, що в мовах високого рівня називають змінними, константами тощо) мають справжні імена, а не просто набори бітів з 1 та 0. Асемблер мені потім ніколи не знадобився, але це допомогло добре розібратися, як працює комп’ютер зсередини.

Після закінчення універу та переходу в штат отримав перше серйозне завдання: побудувати модель руху автоматично керованого літального апарата. Там були моделі руху центра мас, руху навкруги центра мас, двигунів, закрилок тощо. Але... Як випускнику мехмату мені довірили тільки кодування. Тобто інші колеги, які були розробниками (алгоритмістами, до речі, забув про них згадати на початку як про частину ІТ разом з програмістами, електронниками й адмінами, даруйте), малювали алгоритми у вигляді блок-схем, а мені треба було тупо все це кодувати на Fortran. Але такого я витримати не міг, тому весь час намагався розібратися в цих блок-схемах. І передусім старався контролювати, щоб десь не вилізла якась непроініційована (тобто без значення) змінна. А там такого було хоч греблю гати, і я набігав не одну марафонську дистанцію до кімнати з розробниками, коли намагався щодо кожного випадку з’ясовувати, що це таке.

Це побачив один старший колега, який уже декілька разів безрезультатно намагався пояснити керівництву, що ці алгоритми в принципі неробочі й вони ніколи не будуть працювати. Він спитав мене, чи я справді закінчив мехмат, і запропонував попрацювати трохи «по-партизанськи». За тиждень видав мені алгоритм з 10 сторінок (те, що я намагався закодувати перед цим, були три чи чотири книги формату А4 завтовшки 10 сантиметрів). На першій сторінці великими блоками був сформований так званий диспетчер (основний цикл з викликами відповідних моделей і блоком автоматичного вибору кроку інтегрування). А на інших — системи диференціальних та інтегральних рівнянь, які й були відповідними моделями. І я реалізував усе це на Fortran, але вже не як кодер, а як розробник і математик. Здебільшого займався цим увечері, щоб не бачило керівництво. Коли ми представили результат керівнику, він спочатку трохи потупав ногами за самодіяльність, але потім визнав, що мій колега мав рацію і що у нас вийшла класна програма. Вона лягла в основу одного з елементів системи, яку ми розробляли.

nn-річчя нашої лабораторії 343 з «Електроприладу», початок 2000-х

Друга робота: «Кайфово розуміти: я створив таке, що проіснувало багато років»

На «Електроприладі» я затримався років на 5, а потім перейшов у Харківський фізико-технічний інститут. Тут я працював 6–7 років, хоч за останні 2–3 роки вже почався розвал через відсутність фінансування науки у 1990-ті. Але у 1985–89 роках у мене була дуже цікава робота. Я фактично став архітектором і головним програмістом на проєкті розробки системи моделювання та проєктування так званого накопичувача-розтягувача електронів (НР), це такий різновид циклічних прискорювачів. Там був потужний колектив фізиків, які виконували числове моделювання на тому ж Fortran. Вони створили безліч різних моделей різних елементів цього прискорювача, але самі в них заплутались, тож інтегрувати все це в одну модель НР було складно, процес займав багато часу. А треба було побудувати сотні таких інтегрованих моделей, щоб вийти на потрібні параметри пучка електронів. От мені й доручили зробити для цього систему.

Те, що в нас вийшло, — це найкраще з моїх досягнень за все життя в ІТ. Я насправді вважаю так. Я розробив чітку систему стандартів кодування (шаблонів) для фізиків, скриптову систему команд управління і таку ж скриптову мову вибору та конфігурації елементів прискорювача в інтегровану модель. Створення нової моделі стало займати кілька хвилин без будь-якого програмування. Всі нові моделі окремих елементів, розроблені фізиками за нашими шаблонами, інтегрувались у систему дуже легко.

У процесі розробки, коли було реалізовано вже 70–80 %, шеф приніс доку на аналогічну американську систему, яка коштувала 500 тис. доларів

Ми подивились і побачили, що системи схожі за ідеологією. Щось було краще в американців, а щось у нас, від чого керівник був у захваті. Ця програма і результати, отримані за її допомогою, були представлені на багатьох міжнародних конференціях і сприяли захисту декількох кандидатських дисертацій. Але я, як дуже ледача людина (якою і повинен бути програміст), цим не займався, бо занадто це клопітлива та бюрократична справа — написання і захист дисертації. Тим паче, що «недовго грала музика» — почалися 1990-ті.

Але коли вже років за 20 я випадково зустрів деяких колишніх колег, то з подивом дізнався, що наша програма і досі працює. Вони перевели її з Fortran 77 на С++, з ЄС — на персоналку, але вся архітектура залишилася. І це справді кайфово розуміти, що ти створив щось таке, що проіснувало вже стільки років, живе та розвивається без твоєї участі. Не знаю, може, і нині ця програма діє.

1990-ті: «Можливо, було простіше піти на ринок торгувати, але для мене завжди було цікавим програмування»

Але все ж таки почались 1990-ті. СРСР розпався, Україна отримала незалежність — це плюс. Але завершилось фінансування науки — це мінус. Долар полетів у космос, рубль (чи що там тоді було) — навпаки. Затримки зарплати, яка стала дорівнювати 5–7 доларам, досягали кількох місяців. Деякі провідні фахівці отримали гранти від Сороса та вижили як вчені. Велика подяка йому за це.

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

Загалом у 1990-ті бувало все що завгодно — як на Дикому Заході у XIX столітті. Особливо було важко перші роки, потім стало простіше. Цікава історія трапилася у 1991–92 роках у Харківському фізико-технічному інституті. Тоді якраз з’являлись усі ці кооперативчики, які шили одяг. Бо у часи СРСР у Харкові була одна-єдина швейна фабрика імені Тінякова. Але ніхто не хотів носити те, що там виробляли. У 1990-ті ж вибір став більшим, можна було купити одяг на ринку. Особливо популярними стали різноманітні сукні, кофтинки з вишивкою. У нас в інституті був хлопець, дуже талановитий фізик, який гарно розумівся на електроніці, міг спаяти будь-що. І він задумав зробити автоматичний прилад для того, щоб вишивати візерунки на тканині. Японських швейних машинок з програмуванням, звичайно, ще не було. Ідея була така: на рамку натягується тканина, вона встановлюється під машинку, яка управляється програмою, а за допомогою неї можна задавати якийсь візерунок або надпис.

Цей фізик задумав таку штуку як електронник, мене взяв програмістом й іншого хлопця інженером, щоб сконструювати сам прилад. Свою частину фізик зробив швидко. Я ж не досить добре знав ситуацію та почав проєктувати щось глобальне — нову мову програмування спеціально для управління цим станком, продумував усі команди тощо, а треба було робити простіше й оперативніше. Я показав фізику, що виходить. Він глянув і сказав: «Гарно, але якщо це треба доробляти ще пів року, то виходить дуже довго». Другий хлопець-інженер теж не зовсім збагнув замисел. Мабуть, там, де він працював, були великі верстати, бо деталі, які в нього вийшли, більше підходили для автомобіля. Механізм вийшов могутнім, дуже важким, інерційним.

Через пів року я зайшов у гості до цього фізика. А він, виявляється, не здався, сам на колінках усе довів до кінця. Показав мені, як його жінка працює за цим приладом. Так, там доводилося два чи три дні кодувати візерунок, але потім машинка вишивала картинку за 15–20 хвилин.

Взагалі, народ займався чим завгодно — хто що вмів. Держсектор розвалювався, тривала приватизація, створювались маленькі приватні магазинчики, фірмочки, змінювались закони та правила бухгалтерського обліку. Всім потрібні були бухгалтери, а бухгалтерам якесь ПЗ, якого раніше не було. Найбільш популярними тоді стали Clipper, FoxPro, частково Clarion. Вони були схожими на Access: своя маленька БД з кількох DBF-файлів (крім Clarion, там був власний формат БД) і можливість швидко створювати притомний псевдографічний інтерфейс для користувачів (хто заглядав у кодову сторінку ASCII CP866, той бачив там багато різних стрічок, кутків, хрестиків тощо — от з них і складались таблички та кнопочки в інтерфейсах). Я, звичайно, теж цим займався.

Тоді сталася одна невдача, яка все ж пішла на користь, бо дуже просунула мене в розумінні перспективності справжніх реляційних БД

Була одна шабашка: ми робили бухгалтерську систему для вишу на Clipper. Складна логіка, безліч різних умов, коефіцієнтів, жахливо складні алгоритми нарахування зарплат, лікарняних тощо. Але ми зробили її за кілька місяців. Усе працювало, поки нас не попросили доробити її так, щоб з нею могли працювати одночасно кілька бухгалтерів. А в Clipper було якесь блокування на рівні таблиць і рядків, здається. І все. Наш код збільшився за обсягом у 3–4 рази. Програма стала працювати дуже погано, постійно або хтось комусь заважав, або взагалі псував чужі дані. Замовник був незадоволений.

Після кількамісячних страждань ми були змушені здатися і відмовитись від продовження розробки. А коли у 2001–2002 роках мені довелось вперше написати програму в БД Oracle на PL/SQL, якою повинні були послуговуватися декілька десятків користувачів одночасно, я взагалі нічого не робив, щоб забезпечити їхню роботу. Все зробила Oracle сама. До речі, у дискусії, яка почалась на початку 2000-х, де краще реалізовувати бізнес-логіку: в БД її засобами чи в «аплікухах» (Application server), я завжди наводжу цей приклад. Панове програмісти, в сучасних БД на зразок Oracle закладено стільки інтелекту та ресурсів, щоб забезпечити цю багатокористувацьку роботу, можливість відкатів, найвищу надійність тощо, що, коли хтось каже, що може все це зробити у своїй «аплікусі на колінках», я тільки регочу.

Ще кілька слів про «залізо» в 1990-ті. Була серія міні-ЕОМ СМ, був VAX. Ну й PC уже з’явились. Але це на фірмах. А вдома королем був славетний ZX Spectrum фірми Sinclair Research на базі процесора Z80. Це була бомба! Всього від 32 до 64К ОЗУ, без диска та монітора. Замість них — касетний магнітофон і телевізор. До ZX Spectrum купа іграшок на цих касетах. Але головне, що це клондайк для любителів програмування. Була ціла книжка з усіма вихідними кодами на асемблері ядра ОС та інтерпретатора BASIC. Усе відкрито та доступно. Я вже був тоді завеликий і надто зайнятий, щоб дуже гратися ZX Spectrum, але знаю крутих програмістів, яким зараз плюс-мінус 40, котрі починали саме з нього у дитячому віці.

Перехід до банку: «Охочих було набагато більше, ніж вакансій»

Банки — це наше все! Саме про роботу в банку мріяли програмісти у 1990-ті, бо там платили пристойні гроші, причому «по-білому» й узагалі були людські умови роботи та серйозний рівень розробки. Банки з’являлись як гриби, але спробуй туди потрапити, бо охочих було набагато більше, ніж вакансій. Приблизно у 1992–93 році влаштувався в одну контору типу «Роги та копита» (працювала на ринку цінних паперів, цінність яких була така собі), але там ознайомився з Clarion. І ці знання допомогли мені потрапити в банк, бо там була АБС (автоматизована банківська система) саме на ньому, а Clarion був не такий популярний і масовий, як той же Clipper чи FoxPro (останній і потім ще довго тримався).

З того часу почалась моя робота в банках з перервою в рік, коли мій перший банк розвалився (чи його розвалили) і довелося знову шабашити. Щоправда, вже на іншому рівні, бо я знався на банківських системах та Clarion. А він був, можливо, першою системою, яка дозволяла дуже швидко без написання коду розробляти продукт з власною БД і доволі приємним інтерфейсом. Приблизно за тим же принципом, що й Delphi, яка пізніше й зайняла цю нішу. І я, розробивши дві програми на Clarion на дуже популярні тоді теми «Банківська платіжка» та «Товарний склад», почав сам активно шукати клієнтів серед власників приватних магазинів і продавати свої програми з подальшим сапортом. Все було майже ок: прилаштував десь одну «Платіжку», а в іншому місці один «Склад». Перша програма вийшла дуже клієнтоорієнтованою. Мені вдалося зробити так, що бухгалтер набирав щоразу не більше як одне слово, бо те, що він писав раніше, запам’ятовувалось і потім підтягувалось; також там був швидкий пошук. А ось «Склад» був не таким універсальним, його довелося суттєво переробити.

Але згодом з’ясувалося, що «сапорт» це дуже широке поняття: від заправки принтера до встановлення та налаштування ОС на домашньому PC дитинки власника магазина. Чисто за харчі

Тому знову почав шукати банк, знайшов найближчий до дому, потім перейшов в інший, в якому з 2001 року й працюю.

Ну а далі 2000-ні. Саме тоді я почав у банку працювати з БД Oracle, що роблю й досі та не жалкую. Саме про неї і буде повчальна історія. У нас уже було своє сховище даних на Oracle, але самописне, а керівництво завжди хоче чогось покупного. Тому запросили хлопців з київської компанії RStyle, щоб вони продемонстрували своє промислове сховище. Нам треба було наповнити його даними з нашого сховища. Але не один в один, а з суттєвими трансформаціями. Тобто треба було з кількох наших таблиць зробити кілька їхніх, але з іншою структурою. Інакше кажучи, дані повинні були бути ідентичними за змістом, але у сховищах вони розміщувалися в таблицях, які відрізнялися за складом і структурою. Це звичне явище для БД, бо варіантів організації структур є безліч.

Тому нам треба було не просто перенести наші дані до їхнього сховища «як є», а при цьому змінити їхні структури. Наприклад, одну нашу таблицю поділити на дві, як у них, або з п’яти наших зробити одну їхню за допомогою з’єднань та інших модифікацій (щось агрегувати, щось порахувати тощо). Особливо важкою в них була одна дуже широка та довга таблиця, що формувалася з кількох наших, серед яких траплялися теж немаленькі (приблизно по кілька сотень мільйонів записів).

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

Працює ця програма добу, другу, третю... Тобто у середу все ще працює. Дивимось в їхню БД, а там тільки відсотків 10 даних заїхало. Отакої! Ми шоковані. Розуміємо, що не встигнемо, і зриваємо презентацію. І тут хлопчина з тієї компанії, оракліст (їхня БД теж на Oracle) каже: «Гаразд». Зупиняє ту програму, залінковує бази, сідає за комп — і за пів години пише скрипт на SQL. На зразок INSERT INTO, таблиця SELECT... І той SELECT на 2–3 екрани, в якому безліч дужок і різних цікавих слів: from, where, group by, order by, having тощо (join у тій версії Oracle ще не було, замість нього — where) і всі наші вхідні таблиці. Запускає скрипт на виконання. Чекаємо. Минає 15–20 хвилин. Закінчився. Дивимось у БД — усі дані перенеслися на потрібні місця. 10 % за три доби на Java, 100 % за 20 хвилин на Oracle. Що б ви зробили? Я взяв свою товстенну книгу з Java (здається, вони завжди такими були) і засунув якомога далі на книжкову полицю. А цей скрипт роздрукував, повісив на стіну над своїм столом і за ним почав вивчати SQL. Амінь. Хай хтось спробує переконати мене, що для роботи з великими обсягами структурованих табличних даних є щось краще за якісну реляційну БД, ще раз порегочу.

Історія ІТ від 1980-х до початку 2000-х у книгах

Михайло поділився фотографіями зі своєї колекції книжок з програмування та загалом ІТ. Він почав збирати їх ще в університеті, відтоді поповнював колекцію, лише останні років 5 перестав — інтернету вистачає. Скільки їх — не рахував: каже, таких полиць, як на першому фото, 4–5. Михайло розповідає, що у 1980-х книжок було набагато менше, ніж сьогодні, хоча теж достатньо. Були вони доволі дешеві, особливо тоненькі в м’яких обкладинках, тому купував майже все, що траплялося і видавалося цікавим (а цікавим тоді було майже все). В 1990-х було складніше в усіх сенсах, тому купував тільки те, що вкрай необхідно, а з появою інтернету перейшов здебільшого на «самвидав». Більшу частину колекції прочитав, як кажуть, «по діагоналі», тобто зупинявся на окремих фрагментах. Але деякі книги ставали на певний період настільними.

Висновки за довгі роки роботи в IT: «Треба бути готовими до постійного самонавчання»

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

Тепер щодо актуальних дискусій на тему «що краще?»: умовно «код-картинка» — хороший код — чи, перепрошую, «говнокод» (але саме такий термін використовують в IT сьогодні). На жаль, правда в тому, що перший ніхто не оцінить, бо він завжди виходить коротенький, хоча довго пишеться і добре працює. А з другим усе навпаки, тому за нього платять більше. І сапортити його вигідніше, бо постійно щось ламається, і клієнт вас любить, і гроші платить (хоч, може, і кляне при цьому). І не так, як у першого варіанта, коли «поставив і забув», як і клієнт про вас. Так, доводиться і «говнокодити», таке життя. Але намагайтеся хоч іноді писати «код-картинку», бо інакше ніколи не станете професіоналом, а будете чистим «говнокодером», а вони довго в ІТ не живуть.

Ще кілька слів про відносини із замовниками (клієнтами). Як відомо, «клієнт завжди має рацію». Але тут така сама ситуація, що і з «говнокодом». Якщо повсякчас будете тупо виконувати всі забаганки клієнта, навіть коли вони безглузді, замість того, щоб спробувати пояснити йому, в чому він помиляється і переконати зробити по-іншому, то професіоналом вам теж не бути. Вибачте за, можливо, занадто менторський тон. І за те, що, може, хтось зі мною не згоден із деяких питань і що, може, не про все важливе сказав. Але це мої думки й мій досвід, і вони, звичайно, суб’єктивні.

До речі, маю деякий досвід у навчанні БД та SQL з 0 до непоганого рівня, тож якщо комусь треба, звертайтесь.

Всім удачі та довгих років життя в ІТ.