Хмарочоси що не масштабується

Майкл Найгард

Розробку програмних продуктів часто порівнюють з будівництвом хмарочосів, дамб і доріг У деяких важливих аспектах це доречне порівняння

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

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

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

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

З іншого боку, в ряді важливих аспектів аналогія з будівництвом не працює Зокрема, матеріальність реального світу посилює роль попереднього планування, змушуючи нас використовувати метод «Водоспаду» Зрештою, ніхто не починає будувати хмарочос, не знаючи заздалегідь, скільки місця він займе і скільки поверхів у ньому буде Додавати поверхи до існуючої будівлі занадто дорого і ризиковано, тому ми намагаємося уникати таких крайностей Місцезнаходження або висота одного разу спроектованого хмарочоса вже не повинні змінюватися

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

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

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

Біографія автора наведена на стор 31

Джерело: Форд Н, Найгард М, де Ора Б, 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>

*

*