Просте має бути простим

Чед Лавінь

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

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

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

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

Часто виникає сильне бажання виправдати рішення передбачуваної вигодою або прогнозованими вимогами Запамятайте: коли ви намагаєтеся вгадати майбутні вимоги, в 50% випадків ви помиляєтеся, а в 49% – Дуже-дуже сильно помиляєтеся Вирішуйте проблеми по мірі їх надходження Здайте додаток вчасно і дочекайтеся зворотного звязку, щоб сформулювати реальні вимоги Створена вами проста архітектура набагато спростить реалізацію нових вимог у разі їх надходження А якщо ви все ж вгадаєте і спрогнозовані вами вимоги стануть реальними до наступної версії, то у вас вже буде в голові готове рішення Відмінність в тому, що тепер ви зможете виділити для нього належне час, тому що воно дійсно необхідно І ви з вашою командою отямитися не встигнете, як завоюєте репутацію професіоналів, здатних добре оцінити завдання і впоратися зі своєю роботою в строк

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

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

*

*