Простота або складність

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

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

Перший урок, який я виніс з доброго десятка провалених проектів баз даних, наступний: головною причиною невдач є зовсім не малокомпетентні програмісти, а зайво складний проект А все тому, що проектувальники бази даних не змогли (або просто не захотіли) придумати більш просте, елегантне рішення задачі Також кілька уроків я виніс з власного досвіду, коли мені доводилося платити за своїми векселями.

Так званий антівексельний принцип проектування я можу сформулювати наступним чином

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

Складність

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

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

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

До речі, в тезаурус синонімом слова складний є слово важкий.

Простота

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

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

Розробка простого рішення в якій би то не було області – дуже складне завдання, яка вимагає таких складових:

■ повне розуміння вимог завдання

■ широкий вибір моделей і рішень

■ повне розуміння технічних правил і нюансів предметної області

■ творчий підхід і професіоналізм

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

■ достатній рівень довіри в команді розробників, дозволяє ідеям розвиватися і видозмінюватися тільки на основі їх цінності, а не на основі особистих амбіцій і заслуг їхніх творців

■ угода про те, що розробка буде продовжуватися, поки не буде знайдено саме елегантне рішення

■ розумна боязнь складності

При розробці проекту за кілька годин або днів нарад можна виробити ідею, яка дозволить уникнути маси проблем, раніше здавалися нездоланними Будь-яке виправдане зменшення складності значно скоротить зусилля на реалізацію проекту і підвищить шанси отримати дійсно працездатний продукт Кожен зайвий рубль, вкладений в процес проектування, окупиться сторицею в процесі реалізації і, тим більше, експлуатації продукту

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

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*