Не захоплюйтеся архітектурними метафорами

Девід Інг

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

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

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

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

Приклад: «Ми будуємо транспортну систему за принципом переміщення корабля між кількома причалами»

Ви уявляєте собі контейнеровоз, борознить простори Тихого океану, – я ж мав на увазі веслову човен в басейні, притому з одним веслом

• Команда розробників починає вважати метафору більш вагомою в порівнянні з реальною бізнес-завданням А ви з любові до своєї метафорі починаєте виправдовувати дивні рішення

Приклад: «Ми сказали, що система буде схожа на картотечна шафа, тому нам доведеться виводити дані в алфавітному порядку Я знаю, що ця шафа має шість вимірювань, нескінченну довжину і вбудовані годинник, але ми вже зробили іконку – а картотека повинна вести себе як картотека .. »

• В системі трапляються назви зі старих, давно забутих метафор – археологічні релікти концепцій, давно відправлених в утиль

Приклад: «А чому обєкт Billing Factory1 створює Port Channel для системи Rowing boat . І він справді повинен повертати для Hub Bus уявлення Pomegranate . Ну так, я дійсно працюю тут недавно, а що »

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

Девід Інг (David Ing) – архітектор програмного забезпечення, який живе і працює у Ванкувері Народився у Великобританії, але переїхав подаль * ше від дощів (хоча зараз вважає, що був обманутий брехливою літературою для туристів)

Підкоряючись вимогам моди, зараз Девід працює в компанії Taglo-city, що спеціалізується на Web 20 тут він намагається привести системи електронної пошти «до цивілізованого вигляду», а заодно зрозуміти, що ж таке Web 20

Billing Factory – фабрика рахунків («Фабрика» – один з шаблонів проектування) port channel – агрегування каналів (технологія, що дозволяє обєднати кілька фізичних каналів в один логічний, в даному випадку – відповідальний за це програмний обєкт) rowing boat – гребний човен hub bus – концентратор шини pomegranate – гранат (Оскільки програмні обєкти зазвичай мають англійські назви, то в російській компанії подібний розмова відбувалася б саме так – на суміші російської та англійської Тому ми вважали правильним привести переклади і дати пояснення у виносці, а не безпосередньо в тексті) – Примеч ред

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

*

*