Пробуйте, перш ніж зробити вибір

ЕрікДорненбург

У ПРОЦЕСІ СТВОРЕННЯ ПРОГРАМИ ДОВОДИТЬСЯ ПРИЙМАТИ БАГАТО РІШЕНЬ

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

У своїй праці, присвяченому ощадливої ​​розробки (lean development), Мері і Том Поппендік (Магу і Tom Poppendieck) описують методику прийняття рішень Вони вважають, що прийняття остаточного рішення слід відкладати до самого відповідального моменту – тієї точки, коли відсутність у команди рішення призведе до того, що рішення буде прийнято за неї, а бездіяльність спричинить незворотні (або труднообратімим) последст І це розумно: адже чим пізніше приймається рішення, тим більше інформації для його прийняття Однак у багатьох випадках «більше інформації не рівносильно «достатньо інформації», а кращі рішення, як усім добре відомо, приймаються «заднім числом» Що це означає для хорошого архітектора

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

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

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

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

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

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

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

*

*