Записуйте свої обгрунтування

Тімоті Хай

У спільноті розробників ІСНУЄ ЧИМАЛО РОЗБІЖНОСТЕЙ З ПРИВОДУ ЦВН-НОСТИ документації, особливо в тому, що стосується архітектури програмного продукту Розбіжності ці зазвичай повязані з субєктивними поглядами на цінність «ретельного попереднього проектування» і тими труднощами, які виникають при постійному оновленні проектної документації відповідно до змін в базі коду

Один з різновидів документації, яка майже не застаріває, не вимагає особливих зусиль з підготовки і майже завжди окупається, – запис обгрунтувань, що стоять за тими чи іншими архітектурними рішеннями Як пояснює Марк Річардс в етюді «Архітектурні компроміси», створення архітектури програмного продукту по суті зводиться до пошуку розумних компромісів між різними характеристиками якості, витратами, часом і іншими факторами Вам, керівництву, розробникам та іншим зацікавленим у проекті сторонам має бути абсолютно ясно, чому одному рішенню віддано перевагу перед іншим і до яких компромісів це призвело (Ви пожертвували горизонтальній масштабованість заради скорочення витрат на обладнання та ліцензії Проблеми безпеки настільки серйозні, що виправдовують збільшення часу відгуку заради шифрування даних)

Формат такої документації залежить від специфіки проекту і може варіюватися від коротких нотаток в текстовому документі, вікі або блозі до формальних шаблонів, що відображають всі аспекти кожного архітектурного рішення Незалежно від виду та формату цей документ повинен відповідати на такі основні питання: «У чому суть прийнятого рішення» І «Чому ми прийняли таке рішення» Ще один частий питання, відповідь на який слід там відобразити: «Які альтернативні рішення розглядалися і чому вони були відкинуті» (насправді частіше запитують: «Чому не зробили так, як пропонував я”) Документація повинна передбачати можливість пошуку, щоб при необхідності можна було легко знайти необхідну інформацію

Така документація може бути корисна в багатьох ситуаціях:

• Щоб проінформувати розробників про важливі архітектурних принципах, які повинні дотримуватися в роботі

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

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

• Щоб передати проект нового архітектору (скільки разів, отримуючи в спадок програмний продукт, ви намагалися зрозуміти, чому архітектори вчинили саме ТАК)

Однак найважливіші переваги цієї практики полягають у наступному:

• Вона змушує вас явним чином формулювати свої доводи, перевіряючи їх надійність (див наступний етюд «Сумнівайтеся в допущених – особливо у власних»)

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

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

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

*

*