Не поспішайте вирішувати завдання

Ебен Хьюїт

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

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

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

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

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

Замість того щоб негайно приступати до вирішення завдання в тому вигляді, в якому ви її отримали, подумайте, чи не можна змінити саму задачу Запитайте себе: як би виглядала архітектура, якби цього завдання просто не було Такий підхід може дати в результаті більш елегантне і збалансоване рішення Бізнес-завдання все одно доведеться вирішувати, але, можливо, не так, як здавалося спочатку

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

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

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

*

*