Простота краще універсальності

Кевлін Хенні

Типова проблема багатьох компонентних інфраструктур (framework), бібліотек класів, базових сервісів та іншого інфраструктурного коду полягає в тому, що вони проектуються з розрахунком на універсальне застосування, без привязки до конкретних додатків У результаті ми отримуємо приголомшливий набір можливостей і налаштувань, які часто не використовуються взагалі або використовуються не за призначенням, а то й просто виявляються марними Більшість розробників працює над конкретними системами, і прагнення до необмеженої універсальності рідко здатне послужити їм хорошу службу Кращий шлях до універсальності пролягає через глибоке розуміння відомих конкретних прикладів та аналіз їх суті з метою пошуку фундаментального спільного рішення: простота як результат практичного досвіду, а не універсальність, яка спирається на умоглядні припущення

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

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

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

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

Кевлін Хенні (Kevlin Неппеу) – незалежний консультант і викладач Він спеціалізується на шаблонах та архітектури, методах і мовах програмування, процесах і практиці розробки Є співавтором книг «А Pattern Language for Distributed Computing» (Мова шаблонів для розподілених компютерних систем) і «On Patterns and Pattern Languages» (Про шаблони і мовах шаблонів) – обидві книги опубліковані видавництвом Wiley

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

*

*