Коли бачите єдине рішення, запитаєте інших

Тімоті Хай

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

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

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

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

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

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

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

Начальник запитав його:

– Що ми можемо зробити для поліпшення продуктивності

У мого друга вже була готова відповідь:

– Купити потужнішу машину

– А що ще

– М-м-м .. Наскільки я знаю, нічого

Мого друга негайно звільнили Зрозуміло, начальник був правий Біографія автора наведена на стор 117

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

*

*