Page 61 - 4787

Відомі три підходи до написання швидких програм. Найбільш важкий з

них пов'язаний з ресурсами часу і часто застосовується в системах з

жорсткими вимогами до виконання в режимі реального часу.

У цій ситуації при декомпозиції проекту кожному компоненту виділяється

бюджет ресурсів - за часом і пам'ятю. Компонент не повинен вийти за рамки

свого бюджету, хоча дозволений механізм обміну тимчасовими ресурсами.

Такий механізм жорстко зосереджений на дотриманні часу виконання. Це

важливо в таких системах як, наприклад, кардіостимулятори, в яких дані,

отримані із запізненням, завжди помилкові.

Другий підхід передбачає постійну увагу. У цьому випадку кожен

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

підтримувати високу продуктивність програми. Це найпоширеніший і

інтуїтивно привабливий підхід, проте він не такий гарний насправді.

Модифікація, що підвищує продуктивність, зазвичай ускладнює роботу з

програмою. Це уповільнює створення програми. На це можна було б піти, якби

в результаті виходило більш швидке програмне забезпечення, але зазвичай

цього не відбувається.

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

з них стосується тільки вузької функції, виконуваної програмою. З

продуктивністю пов'язана та цікава обставина, що при аналізі більшості

програм виявляється, що значна частина часу витрачається невеликою

частиною коду. Якщо в рівній мірі оптимізувати весь код, то виявиться, що 90%

оптимізації вироблено даремно, тому що оптимізувався код, який виконується

не надто часто. Час, що пішов на прискорення програми, і час, втрачений через

її незрозумілості - все це витрачено марно.

Питання для самоконтролю

1. Яка різниця між рефакторингом і оптимізацією продуктивності?

2. Завдяки чому рефакторинг сприяє прискоренню розробки коду?

3. Завдяки чому рефакторинг підвищує якість коду ?

60