Концепція життя програми

Як можна визначити поняття життя програми? Життя програми можна описати повторюваної послідовності кінцевих процесів у комп'ютері виконаних в контексті обраної предметної області. Обов'язково кінцевих, в якомусь розумному часовому відрізку.
design
Коли з'являється програма? Швидше за все, програма з'являється в голові у проектувальника/розробника, можна назвати це design-time. Але так як цей момент не піддається контролю комп'ютера (поки що), то припустимо, що моментом появи програми є момент створення мінімального запускається (про докладному сенсі цього терміна варто поговорити окремо) вихідного коду.
В контексті модульних мов або мов з ООП — програма народжується, коли з'являється мінімальний модуль/клас. Подальший розгляд будемо проводити для модульних систем, так як в немодульних/скриптових системах ті чи інші етапи зазвичай зредуковані/зліплені в єдиний етап.
Можна обґрунтовано виділити design-time в окрему категорію, але не як процес в голові розробника, а чисто утилітарно, спираючись на процес кодування. Тут можна описати автокомплит, автоподсветку (як вже реалізовані програми), програмування макросів ide, генерацію схем БД і ДРАКОН-схем, і так далі.
compile
Потім, після етапу написання деякого програмного коду, програма передається компілятору. Компілятор забезпечує т. н. compile-timeчас компіляції. В результаті виконання процесу компіляції ми отримуємо компилят (тобто безпосередній результат обробки нашого вихідного коду).
Під час компіляції наш вихідний код впливає на роботу компілятора за певними законами, які виражені в коді компілятора.
У той же час, ніхто не заважає вже на етапі компіляції керувати діями компілятора (точніше, виконавця в цілому) не опосередковано, через написання тексту програми, а безпосередньо, через написання коду загального призначення, який буде виконаний компілятором.
тобто такого коду, який хоч і відноситься до задуманої програмі, але не перекладається компілятором в компилят безпосередньо. Так званий CTFE, але в більш загальному сенсі. Зрозуміло, що перебування в контексті процесу роботи компілятора може накладати певні обмеження на код часу компіляції, однак може і не накладати.
Тут ми можемо помітити, що виконання будь-якого процесу життєвого циклу передбачає наявність результату, в явному або неявному вигляді.
load
Після отримання компіляту, над ним, відразу або * ліниво * повинен бути виконаний процес зв'язування або лінкування. Так як компилят зазвичай зберігається у файлі, то виникає час завантаження load-time.
В цей час над компилятом можуть бути проведені додаткові перетворення в код цільової платформи, і в цей час може бути виконаний код часу завантаження, наприклад, обробка компіляту оптимізуючих компілятором.
На даний момент відома тільки одна технологія, WebAssembly (slim-binaries), пізня кодогенерация на цільовій платформі, яка хоч якось описує час завантаження.
link
Звичайно, лінкування необхідна, так як компілятор завжди справляє компилят для одного модуля для безпосереднього виконання на цільовій машині. Однак у реальному модульною системою на машині одночасно будуть виконані кілька модулів.
Ця ситуація в багатомодульним системі призводить до необхідності зв'язування. У старих системах зв'язування могло проводитися безпосередньо після компіляції, але цей вироджений випадок ми не розглядаємо. Отже, виникає час зв'язування, або link-time.
Мало що відомо про виконання коду під час зв'язування, однак зрозуміло, що в момент зв'язування можливе виконання коду, наприклад, Dependency Injection та динамічного спадкування/проксі серверів, як це може бути реалізовано в рамках роботи всередині jvm.
Такий контроль над ще не запущено в дію, але вже готовим до виконання кодом програми дозволяє реалізовувати автоматизовану налаштування і так далі. Після зв'язування та налаштування код безпосередньо готовий до запуску.
init, run, close
Запуск і подальша робота. Найбільш відомі широкій публіці етапи. Представлені часом ініціалізації init-time і часом виконання run-time). По суті, результат роботи цього етапу життєвого циклу і є зазвичай безпосередньою метою написання програми.
Можна додатково виділити завершення роботи програмиclose-time). Проте зараз всі три часу роботи зазвичай прийнято називати run-time, а логічне поділ на три етапи реалізовувати вже в рамках клієнтського програмного коду.
Такий підхід знижує вимоги до середовища виконання (run-time environment) але не дає гарантій виконання того чи іншого етапу в потрібній послідовності з-за можливих помилок виконання (run-time error) після виконання яких, зазвичай, має завершитися аварійно.
death
Окремим важливим часом життя програми є посмертне час death-time), яке, всупереч поширеним уявленням теж є частиною життєвого циклу програми. Пояснення тут просте, так як метою роботи програми зазвичай є якийсь результат, зазвичай залежить від вхідних даних, яких може бути дуже багато, програми будуються із застосуванням методів, що дозволяють ітеративне обробляти вхідні дані і робити вихідні дані, які можуть бути подані на вхід наступної ітерації.
Зазвичай такі дані структуровані (БД), версионны (результат взаємодії зі стороннім API) і їх вміст і інтерпретація залежить від реалізації працюючої програми. Тобто, програма це алгоритми і дані, у тому числі зовнішні і ступінь пов'язаності цих зовнішніх даних з програмою ніяк не впливає на сам факт наявності такої пов'язаності на будь-якому етапі життєвого циклу.
Простіше кажучи, програма запущена знов буде працювати по-різному, в залежності від результату, який був нею ж отриманий на минулому етапі життєвого циклу. І якщо внести в ці дані зміни в час, що програма не запущена, програма теж буде працювати інакше, тобто, вносячи зміни в дані ми програмуємо програму працювати інакше. Що є етап життєвого циклу програми.
Підсумки
Отже, розглянуті етапи життя програми: design-time -> compile-time -> load-time -> link-time -> init-time -> run-time -> close-time -> death-time. Як можна помітити, всі етапи присутня у циклі розробки та використання будь-якої програми, а отже в будь-який з цих етапів може бути виконаний користувальницький код, який дозволить отримати результат, найбільш відповідний цілям розробника. На сьогоднішній день немає такої мови, фреймворку або екосистеми, в якому ці етапи були б реалізовані у всій повноті. Науки, бізнесу та суспільству в цілому є куди прагнути.

Джерело: Хабрахабр

0 коментарів

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