Смещение акцентов: проектирование базы уходит на второй план

6 мая 2009 г.

Артем Смирнов в статье База, знай свое место! выразил свое мнение по поводу места базы данных при разработке ПО. Даже назвал ее "простой утилитой". Заявления довольно резкие и стоят прояснения.

С чего начинать разработку ПО? С детальной разработки логики приложения или с проектирования базы данных для нашей системы? Это неправильный выбор из двух крайностей. В реальности решение лежит где-то посередине, отклоняясь к тому или иному полюсу в зависимости от обстоятельств.

Чем будет обусловлен выбор? Главное здесь это то, что в последнее время произошло смещение акцентов при разработке ПО. Разработчики и менеджеры стараются больше внимания уделять сопровождению приложения, его развитию в долгосрочной перспективе. Именно поэтому основное внимание (опять же не всегда) уделяется развитию и поддержанию гибкого и понятного дизайна в коде. С таким кодом проще работать, он содержит меньше ошибок, искать ошибки проще, новые программисты могут быстрее разобраться в исходном коде и приступить к работе в команде.

Но надо ясно осознавать, что при этом меньше внимания уделяется производительности системы. Технологии идут вперед: серверы становятся мощнее, интернет быстрее, поэтому программисты могут себе позволить делать запросы к базе данные прямо в коде на Linq и это отлично. Но, когда база разрастается, приходится жертвовать гибкостью системы и решать проблемы с оптимизацией. И это вполне нормальный процесс. И не надо говорить, что с самого начала можно было понять, что этот запрос будет долгий, что надо было это предусмотреть и создать View для ускорения. Лучше избегать преждевременной оптимизации.

В своих проектах мы придерживаемся следующей последовательности. Сначала мы делаем игру в планирование, чтобы понять, что нужно заказчику. Потом несколько программистов пишут тесты и создают "верхушку" архитектуры, прикидывают примерную метафору всей системы. После этого уже создается база данных, и разработка базы идет параллельно с разработкой кода.

В итоге, главное выбрать способ ведения проекта наиболее эффективный в вашем случае. Какой последовательности и в каких типах проектов придерживаетесь вы?

13 комментариев:

  1. читал обе статьи, правда есть в обеих.
    поправка адекватная.

    P.S. с приходом весны обострилась тенденция возникновений священных воин по поводу терминологии и акцентов, сам тоже грешен в рамках ресурса xnadev.ru

    ОтветитьУдалить
  2. В одно-двухдневном цикле, один человек делает тесты, сущности, БД и паблишет на стейджинг. Никто в начале не пишет "аржитектуры" следую принциму ягни. Когда понядобиться тогда и сделам.

    ОтветитьУдалить
  3. Сегодня послушаю Артёма, но я пока я придерживаюсь следующей точки зрения: на первом месте должна быть домен (модель), сохраняемости не стоит уделять столько внимания при проектировании, ведь не всегда нужно пользоваться базой данных, вдруг этот слой будет гибридным?

    ОтветитьУдалить
  4. @Mike Chaliy
    Т.е в самом начале проекта вы доверяете самую ответственную работу одному человеку?

    ОтветитьУдалить
  5. >Какой последовательности и в каких типах проектов придерживаетесь вы?

    Зависит от стиля ведения конретного проекта.
    Если используется agile процесс, а в этом виде процессов мы активно использует configuration driven design + test driven development, то продукт растёт кусочками (user story, use case, scenario - выберите наиболее понравившееся название :)), путей реализации каждого конкретного кусочка всего два:
    1. UI => Service layer / Business layer => Data access layer
    2. UI <= Business layer => Data acces layer

    Если используется формализованная методология,
    то сначала идёт анализ предметной области, выделение основных обязанностей системы и формирование сущностей, с последующеей проекцией результатов на UI и Persistance
    Т.е. опять таки
    UI <= Business layer => Data acces layer, но в большее количество этапов и с большей формализацией.

    ОтветитьУдалить
  6. @Artem V. Ozornin
    А если бы у тебя был выбор, какой путь и какой стиль (agile/waterfall) ты бы предпочел?

    ОтветитьУдалить
  7. Больщая часть наших проектов - agile.
    Я никогда не участвовал в проектах с использованием waterfall, и как то не очень хочется начинать.
    Под использованием формализованных методологий я имел в виду RUP style, т.е так же итеративную модель разработки.

    Отвечая непосредственно на вопрос - я предпочитаю agile, потому что большая (или правильнее - наиболее типичная) часть проектов над которыми мы работаем - наиболее удачно укладываются в эту модель процесса

    ОтветитьУдалить
  8. @Artem V. Ozornin
    Спасибо, что поделился информацией ;)

    ОтветитьУдалить
  9. >> @Mike Chaliy
    >> Т.е в самом начале проекта вы доверяете самую ответственную работу одному человеку?

    Всем доверяем. Все с самого начала пишут паралельно. За цикл очень больших рассогласований не происходит.

    ОтветитьУдалить
  10. @Mike Chaliy
    Ясно. Мы на последнем проекте первые два дня вообще программировали вчетвером (на проекте 4 программиста) за одним компьютером. Было интересно в плане обмена опытом. К тому же с получившейся структурой сразу были согласны все разработчики этого проекта =)

    ОтветитьУдалить
  11. Я наверное не смогу сформулировать способ ведения проекта =)

    Не может быть одинаковых способов для двух независимых частей проекта с разным опытом по каждой из них. Что-то делается с закрытыми глазами не думая, для чего-то приходится собирать консилиум, писать тексты и тесты (и/или прототипы) и так далее. А что-то приходится переделывать один-два раза =)
    В целом связи должны быть предельно мягкими, тогда пофигу, что за подход используете -- следом за вами можно будет что-то исправить.

    Но принцип всегда один -- всё должно быть предельно просто и единообразно. Например, описанной в комментах к той заметке ситуации быть не должно -- адрес это поля сущности, а не ссылка на отдельную сущность Адрес. Потому что это просто бестолковое раздувание количества сущностей, безотносительно подхода.

    ОтветитьУдалить
  12. Да, главное, чтобы используемый подход давал результат =)

    А на счет сущности адреса можно не согласиться. Т.е. это не всегда "бестолковое раздувание количества сущностей". Например, у нас в базе есть таблица с адресами и это действительно оправдано, т.к. проект оперирует объектами недвижимости и несколько полей для адреса не достаточно.

    ОтветитьУдалить
  13. мышление в ключе проектирования базы данных дает мне дополнительный ракурс и помогает в формализации задачи, наряду со взглядом на архитектуру и онтологией предметной области, но это такой эмпирический подход, формализация сама по себе для меня не формализована

    ОтветитьУдалить

Моя книга «Антихрупкость в IT»

Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...