Думати про продуктивність ніколи не рано

Ребекка Парсонс

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

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

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

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

Чому це так важливо Насамперед, ви як мінімум будете знати про те, які саме зміни призвели до різкого падіння продуктивності Якщо в системі виникнуть проблеми з продуктивністю, вам не доведеться аналізувати всю архітектуру цілком – досить буде зосередитися на тих моментах, які змінювалися недавно Рано приступивши до тестування продуктивності і часто його виконуючи, ви звузите коло змін, які слід піддавати аналізу

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

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

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

Доктор Ребекка Парсонс (Rebecca Parsons) – технічний директор ThoughtWorks Вона володіє більш ніж 20-річним досвідом розробки додатків в різних галузях, від телекомунікацій до нових інтернет-сервісів Ребекка має друковані публікації з мов програмування і штучному інтелекту, працювала в ряді комітетів в області програмування і написала безліч журнальних статей У неї є обширний досвід у галузі створення великомасштабних розподілених обєктних додатків і інтеграції різнорідних систем

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*