Чи не контролюйте – спостерігайте

Грегор Хоп

Сучасні системи є розподіленими і слабо звязаними (loosely coupled) Побудова слабко повязаних систем створює чимало клопоту, так чому ж ми йдемо на це Тому що хочемо, щоб наші системи були гнучкими і не розвалювалися при найменших змінах Це критичне властивість в сучасних середовищах, де ми контролюємо лише невелику частину свого додатку, а все інше існує у вигляді розподілених служб або пакетів, що перебувають під контролем інших відділів або зовнішніх виробників

Отже, прагнення створити систему гнучку і здатну розвиватися з часом – справа хороша Але це означає також, що наша система буде поступово змінюватися Іншими словами, «сьогодні система вже не та, якою була вчора » На жаль, це помітно ускладнює документування системи Всі знають, що документація застаріває в момент друку, але в постійно мінливих системі справи можуть складуться ще гірше Більше того, побудова гнучкої системи зазвичай ускладнює архітектуру, і отримати горезвісну «загальну картину» стає ще важче Наприклад, якщо всі компоненти системи обмінюються інформацією по логічним, налаштованим каналах, то, щоб отримати уявлення про події, необхідно поглянути на конфігурацію каналів Відправлення повідомлень в логічне піди-туди-ні-знаю-куди навряд чи приведе до помилки компіляції, але напевно засмутить користувача, дія якого була запаковано в це повідомлення

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

У багатьох випадках модель можна легко візуалізувати, побудувавши дійсно «загальну картину» Однак боріться з спокусою заповнити квадратиками і лініями полотно 3×5 метрів в прагненні зобразити всі класи вашої системи Така картина зійде за витвір сучасного мистецтва, але її не назвеш корисної програмної моделлю Замість цього краще використовувати «вид з висоти 300 метрів», як рекомендує Ерік Дорна-бург, – той рівень абстракції, який містить дійсно корисну інформацію Вдобавок ви зможете простежити за тим, щоб у моделі не було порушень найпростіших правил коректності – циклічних посилань в графі залежностей або відправки повідомлень по непрослушіваемим логічним каналах

Послаблення контролю лякає, особливо коли мова йде про архітектуру системи Але в поєднанні з ретельним наглядом, побудовою моделей і перевіркою коректності воно, ймовірно, є єдиним розумним підходом до побудови архітектури програмного забезпечення в XXI столітті

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

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

*

*