Артем Смирнов в статье База, знай свое место! выразил свое мнение по поводу места базы данных при разработке ПО. Даже назвал ее "простой утилитой". Заявления довольно резкие и стоят прояснения.
С чего начинать разработку ПО? С детальной разработки логики приложения или с проектирования базы данных для нашей системы? Это неправильный выбор из двух крайностей. В реальности решение лежит где-то посередине, отклоняясь к тому или иному полюсу в зависимости от обстоятельств.
Чем будет обусловлен выбор? Главное здесь это то, что в последнее время произошло смещение акцентов при разработке ПО. Разработчики и менеджеры стараются больше внимания уделять сопровождению приложения, его развитию в долгосрочной перспективе. Именно поэтому основное внимание (опять же не всегда) уделяется развитию и поддержанию гибкого и понятного дизайна в коде. С таким кодом проще работать, он содержит меньше ошибок, искать ошибки проще, новые программисты могут быстрее разобраться в исходном коде и приступить к работе в команде.
Но надо ясно осознавать, что при этом меньше внимания уделяется производительности системы. Технологии идут вперед: серверы становятся мощнее, интернет быстрее, поэтому программисты могут себе позволить делать запросы к базе данные прямо в коде на Linq и это отлично. Но, когда база разрастается, приходится жертвовать гибкостью системы и решать проблемы с оптимизацией. И это вполне нормальный процесс. И не надо говорить, что с самого начала можно было понять, что этот запрос будет долгий, что надо было это предусмотреть и создать View для ускорения. Лучше избегать преждевременной оптимизации.
В своих проектах мы придерживаемся следующей последовательности. Сначала мы делаем игру в планирование, чтобы понять, что нужно заказчику. Потом несколько программистов пишут тесты и создают "верхушку" архитектуры, прикидывают примерную метафору всей системы. После этого уже создается база данных, и разработка базы идет параллельно с разработкой кода.
В итоге, главное выбрать способ ведения проекта наиболее эффективный в вашем случае. Какой последовательности и в каких типах проектов придерживаетесь вы?
читал обе статьи, правда есть в обеих.
ОтветитьУдалитьпоправка адекватная.
P.S. с приходом весны обострилась тенденция возникновений священных воин по поводу терминологии и акцентов, сам тоже грешен в рамках ресурса xnadev.ru
В одно-двухдневном цикле, один человек делает тесты, сущности, БД и паблишет на стейджинг. Никто в начале не пишет "аржитектуры" следую принциму ягни. Когда понядобиться тогда и сделам.
ОтветитьУдалитьСегодня послушаю Артёма, но я пока я придерживаюсь следующей точки зрения: на первом месте должна быть домен (модель), сохраняемости не стоит уделять столько внимания при проектировании, ведь не всегда нужно пользоваться базой данных, вдруг этот слой будет гибридным?
ОтветитьУдалить@Mike Chaliy
ОтветитьУдалитьТ.е в самом начале проекта вы доверяете самую ответственную работу одному человеку?
>Какой последовательности и в каких типах проектов придерживаетесь вы?
ОтветитьУдалитьЗависит от стиля ведения конретного проекта.
Если используется 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, но в большее количество этапов и с большей формализацией.
@Artem V. Ozornin
ОтветитьУдалитьА если бы у тебя был выбор, какой путь и какой стиль (agile/waterfall) ты бы предпочел?
Больщая часть наших проектов - agile.
ОтветитьУдалитьЯ никогда не участвовал в проектах с использованием waterfall, и как то не очень хочется начинать.
Под использованием формализованных методологий я имел в виду RUP style, т.е так же итеративную модель разработки.
Отвечая непосредственно на вопрос - я предпочитаю agile, потому что большая (или правильнее - наиболее типичная) часть проектов над которыми мы работаем - наиболее удачно укладываются в эту модель процесса
@Artem V. Ozornin
ОтветитьУдалитьСпасибо, что поделился информацией ;)
>> @Mike Chaliy
ОтветитьУдалить>> Т.е в самом начале проекта вы доверяете самую ответственную работу одному человеку?
Всем доверяем. Все с самого начала пишут паралельно. За цикл очень больших рассогласований не происходит.
@Mike Chaliy
ОтветитьУдалитьЯсно. Мы на последнем проекте первые два дня вообще программировали вчетвером (на проекте 4 программиста) за одним компьютером. Было интересно в плане обмена опытом. К тому же с получившейся структурой сразу были согласны все разработчики этого проекта =)
Я наверное не смогу сформулировать способ ведения проекта =)
ОтветитьУдалитьНе может быть одинаковых способов для двух независимых частей проекта с разным опытом по каждой из них. Что-то делается с закрытыми глазами не думая, для чего-то приходится собирать консилиум, писать тексты и тесты (и/или прототипы) и так далее. А что-то приходится переделывать один-два раза =)
В целом связи должны быть предельно мягкими, тогда пофигу, что за подход используете -- следом за вами можно будет что-то исправить.
Но принцип всегда один -- всё должно быть предельно просто и единообразно. Например, описанной в комментах к той заметке ситуации быть не должно -- адрес это поля сущности, а не ссылка на отдельную сущность Адрес. Потому что это просто бестолковое раздувание количества сущностей, безотносительно подхода.
Да, главное, чтобы используемый подход давал результат =)
ОтветитьУдалитьА на счет сущности адреса можно не согласиться. Т.е. это не всегда "бестолковое раздувание количества сущностей". Например, у нас в базе есть таблица с адресами и это действительно оправдано, т.к. проект оперирует объектами недвижимости и несколько полей для адреса не достаточно.
мышление в ключе проектирования базы данных дает мне дополнительный ракурс и помогает в формализации задачи, наряду со взглядом на архитектуру и онтологией предметной области, но это такой эмпирический подход, формализация сама по себе для меня не формализована
ОтветитьУдалить