Сумнівайтеся в допущених – особливо у власних

Тімоті Хай

Закон відкладених рішень Уезерна говорить: «Допущення – корінь всіх провалів» Звичайно, формулювання не дуже серйозна, але коли припущення обходяться вам в кілька тисяч (а то й мільйонів) доларів, стає не до сміху

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

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

Інформація або публікація, негідна довіри, або подія сумнівною істинності, повсюдно приймається за правду Термін введений американським письменником Н Мейлером в 1973 році – Прямуючи перев

цих припущень лежать «історичні причини», субєктивні думки, упередження розробників, побоювання і сумніви[16] і навіть чутки:

• «Продукти з відкритим вихідним кодом ненадійні»

• «Від індексів на основі бітових карт більше клопоту, ніж користі»

• «Замовник ніколи не прийме сторінку, яка вантажиться за пять секунд»

• «IT-директор погодиться купувати продукти тільки у великих вендорів»

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

Зверніть увагу на слово «актуальний» Те, що було справедливо для старої версії вашої програми, може стати недійсним сьогодні Продуктивність індексів на основі бітових карт може відрізнятися в різних версіях Oracle Дірки в безпеці старої версії бібліотеки можуть бути вже виправлені в новій версії Старий надійний виробник або постачальник може бути на останньому подиху у фінансовому відношенні Технологічний ландшафт змінюється кожен день, змінюються і люди Хто знає, може, ваш IT-директор став таємним шанувальником Linux

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

Біографія автора наведена на стор 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>

*

*